Er der stadig brug for QA-ingeniører?

Der er ingen tvivl om, at verden er i konstant forandring. Takket være internettet, automatisering og moderne computeres databehandlingsevne er grænsen mellem mennesker og maskiner blevet uklar. Hvordan påvirker det især IT og QA-testning? Og endelig, hvilke QA-færdigheder gør gode QA-testere gode, ja, gode?
Det ideelle sæt af QA-færdigheder
I takt med at vi bliver mere afhængige af AI og automatisering, har QA-testernes rolle også ændret sig. Findes der overhovedet en ideel QA-tester? Sandsynligvis ikke. Men her er de QA-færdigheder, som gode QA-testere ofte har til fælles:
- Databasefærdigheder - evnen til at kontrollere eller udtrække data fra databaser uden hjælp fra andre
- Kodningsevner - forståelse af kildekode og mere effektiv søgning efter edge cases
- Evnen til at skrive automatiseringstest ved hjælp af Geb eller RestAssured, som giver testeren mulighed for at vurdere brugergrænsefladen såvel som API'et
- Muligheden for at kigge gennem logfiler eller endda bruge SSH til at logge ind på en server, analysere ændringer i kode og finde årsagen til, at fejlen opstår. Det betyder ikke, at testere skal kunne analysere problemer med transaktioner eller race-condition-problemer. Alligevel er det helt klart en fordel at kunne finde et manglende udråbstegn i if-erklæringen
- Evnen til at foretage en forretningsanalyse af krav eller måske endda tage ansvar for dem
Har aber kvalifikationssikkerhedsfærdigheder?
Jeg har hørt blandede meninger om manuelle testeres rolle. Nogle mener, at rollen nemt kan udfyldes af trænede aber. Andre mener, at jobbet kræver et særligt sæt af færdigheder.
Hvor ligger sandheden?
Som sædvanlig, som med alle it-relaterede ting, i midten.
Nogle mennesker tror, at testning kan udføres af almindelige app-brugere. De mener, at det er lige så godt at ansætte 20 junior-testere som at bruge Amazon Mechanical Turk. Spørgsmålet er, om det kan være effektivt at klikke sig "tilfældigt" gennem en app for at finde problemer? Det tvivler jeg virkelig på. Selv om det kan dække positive stier (da det er sådan, de fleste mennesker bruger apps), vil nogle alvorlige fejl sandsynligvis forblive uopdagede. Det kunne vi jo meget vel bede vores børn om at gøre, ikke?
QA-færdigheder i praksis
En god QA-tester har gode, meget specifikke analytiske evner. Gode testere er nysgerrige og leder efter problemer, eller pønser på det hele, om du vil.
I øjeblikket bliver analytikere normalt ikke involveret i it-projekter. Derfor er nogle af deres ansvarsområder blevet overtaget af testere. Det skyldes, at QA-færdigheder indebærer, at man skal være nysgerrig på kravene og hele tiden stille spørgsmålstegn ved dem.
Lad mig forklare dette ved hjælp af en hypotetisk samtale mellem en QA-tester, en kunde og en softwareudvikler. Når softwareudvikleren ser på et simpelt krav, f.eks. "gratis levering ved bestilling af 5 bøger", ser han et simpelt "if"-udsagn. Hvis antallet af bøger er lig med 5 eller mere, sættes leveringsomkostningerne til 0. Slut på historien.
En god tester vil sandsynligvis sige: "Det er et meget kort krav. Det dækker ikke engang de fleste af scenarierne." Og så begynder de at stille ubehagelige spørgsmål.
TESTER: "Hvad hvis kun 2 af de bestilte bøger er på lager i øjeblikket? Og de resterende tre bliver sendt i en anden pakke? Er begge pakker berettiget til gratis levering?"
KUNDEN: "Øh, nej. Der skal leveres i alt fem bøger i én pakke."
SOFTWAREUDVIKLER: "Det er endnu et "hvis" lige der."
TESTER: "Hvad hvis jeg bestiller en opvaskemaskine og fem bøger? Er min ordre berettiget til gratis levering?"
KUNDEN: "Nej, selvfølgelig ikke. Tilbuddet gælder kun, hvis du bestiller bøger."
SOFTWAREUDVIKLER: "Undskyld mig, det er endnu et 'hvis'"
TESTER: "Hvad hvis jeg får 4 e-bøger og en bog?"
KUNDEN: "Tilbuddet gælder kun for trykte bøger."
SOFTWAREUDVIKLER: "Jeg tror, at vi måske skal lave et nyt overslag."
Som du kan se, har QA-testere og softwareudviklere forskellige tankesæt og forskellige færdigheder. Af den grund er det umuligt for udviklere at overtage QA i sin helhed.
Vil computere overtage QA-testning?
Det tager nu næsten ingen tid at gå fra at bygge en pakke til at tage den i produktion, kun 15 til 60 minutter. Dette udelukker praktisk talt en manuel kvalitetsvurdering. Tidligere tog det flere uger at teste store projekter. Der er ingen måde at komprimere det til et par timer, medmindre testningen er automatiseret.
Hvordan kan computere hjælpe med testning? Alle regressionstests er repetitive, og når det drejer sig om repetitive opgaver, har computere deres egne fordele. De er hurtige, pålidelige og konsekvente. De laver ikke fejl. At fejle er trods alt menneskeligt, ikke sandt?
Maskiner har ikke dårlige dage. Og de har aldrig tømmermænd. Det er også lettere at vurdere, hvor lang tid det vil tage dem at udføre en opgave.
Hvem skal bygge automatiserede tests?
Automatisering af test er virkelig vejen frem. Derfor er det rigtige spørgsmål at stille på dette tidspunkt, hvem der skal bygge automatiserede tests? Jeg mener, at de bør bygges af testere, der både har QA-færdigheder og i det mindste grundlæggende kodningsevner, med vægt på førstnævnte.
Faktisk følger dette ønskværdige sæt af færdigheder normalt en almindelig karrierevej:
Manuel tester -> Automatiseringstester -> Softwareudvikler
Skiftet til softwareudvikling skyldes ofte udbrændthed eller utilfredshed med lønnen (hvilket langsomt bliver et mindre problem, da arbejdsgiverne er begyndt at værdsætte gode testingeniører). Når det er sagt, mener jeg, at den første overgang fra manuel til automatiseret testning er obligatorisk.
Mange testere er i stand til at skrive forespørgsler til relationelle og ikke-relationelle databaser. Det næste skridt er at lære grundlæggende kodningsevner. Der findes en række ressourcer, som giver folk mulighed for at lære Python, Java eller Groovy. Der findes gratis og betalte kurser, vejledninger, konferencer, bøger, e-bøger ... Du kan finde det hele.
At skabe en komfortabel ramme for accepttestning til et projekt kræver mange flere færdigheder og meget mere erfaring, end du behøver for at skrive scenarier med den. Gode testere bliver ved med at lære at udvide deres perspektiv og er også naturligt nysgerrige. Det gør dem til de bedste personer til at opbygge rammerne. Det er denne unikke kombination af færdigheder og kvaliteter, som gør dem så værdifulde.
Automatisering vil uden tvivl overtage en del af QA-testernes arbejde. Det vigtige er dog, at den vil supplere mennesker og ikke erstatte dem. I det væsentlige vil den frigøre testerne, så de kan fokusere på den menneskelige (kreative) del af arbejdet. På denne måde kan de fokusere på den overordnede produktkvalitet i stedet for "bare" at fjerne fejl.
Testning af QA-færdigheder
Test til vurdering af QA-færdigheder er baseret på et enkelt princip - kandidaterne får et fuldt funktionelt system med et sæt forretningskrav. De skal skrive tests for at bevise, at systemet opfylder alle disse krav. Vi kontrollerer derefter, at disse tests er i stand til at fange alle potentielle fejl, der indføres i systemet.
Hvis du ønsker at begynde at teste QA-færdigheder, har jeg gode nyheder til dig. Vi har netop frigivet vores test til vurdering af QA-færdigheder. Du kan finde dem nedenfor og i vores katalog over kodningstest:
- Testede færdigheder
- Varighed
- 85 minutter max.
- Evaluering
- Automatisk
- Testoversigt
-
Spørgsmål efter valg
vurdering af viden om .NET, .NET Core, ML.NET, QA, Afprøvning, xUnit, NUnit
Huller i koden
vurdering af viden om NUnit, QA
Programmeringsopgave - Niveau: Medium
QA | .NET | NUnit | Tests til API til dokumenthåndteringssystem - Implementer en NUnit-test, der kontrollerer forretningskrav til et dokument-API til et dokumenthåndteringssystem
- Testede færdigheder
- Varighed
- 64 minutter max.
- Evaluering
- Automatisk
- Testoversigt
-
Spørgsmål efter valg
vurdering af viden om JUnit, QA
Huller i koden
vurdering af viden om JUnit, JUnit4, QA, JUnit 5, Java
Programmeringsopgave - Niveau: Medium
QA | JUnit | ATM Service | Autentifikation og validering af indskud - Skriv testcases til verifikation af softwaren til pengeautomater (ATM).
- Testede færdigheder
- Varighed
- 66 minutter max.
- Evaluering
- Automatisk
- Testoversigt
-
Spørgsmål efter valg
vurdering af viden om QA, Afprøvning, Test af enheder, Manuel testning
Huller i koden
vurdering af viden om JUnit 5, Java, QA
Programmeringsopgave - Niveau: Medium
QA | JUnit | ATM Service | Autentifikation og validering af indskud
- Testede færdigheder
- Varighed
- 36 minutter max.
- Evaluering
- Automatisk
- Testoversigt
-
Spørgsmål efter valg
vurdering af viden om .NET, NUnit, QA
Huller i koden
vurdering af viden om NUnit, QA
Programmeringsopgave - Niveau:
QA | .NET, NUnit | Kaffemaskinesoftwareenhedstests - Skriv testene i den
NUnitExercise.Tests/CandidateTests.cs
klasse til at kontrollere denCoffeeMachineMain
klasse.
- Testede færdigheder
- Varighed
- 51 minutter max.
- Evaluering
- Automatisk
- Testoversigt
-
Spørgsmål efter valg
vurdering af viden om .NET, NUnit, QA
Huller i koden
vurdering af viden om NUnit, QA
Programmeringsopgave - Niveau: svær
QA | .NET, NUnit | Enhedstests for e-mailtjenester - Skriv test i klassen NUnitExercise.Tests/CandidateTests.cs for at verificere klassen for e-mailtjenester
- Testede færdigheder
- Varighed
- 48 minutter max.
- Evaluering
- Automatisk
- Testoversigt
-
Spørgsmål efter valg
vurdering af viden om QA, Selen, .NET, C#
Huller i koden
vurdering af viden om Java, QA, Selen
Programmeringsopgave - Niveau: Medium
QA | .NET, Selenium | Dataudtræk - Implementer metoder i klassen SeleniumTask.SeleniumExecutor for at få alle test gennemført med succes.
- Testede færdigheder
- Varighed
- 52 minutter max.
- Evaluering
- Automatisk
- Testoversigt
-
Spørgsmål efter valg
vurdering af viden om .NET, QA, NUnit, Afprøvning, C#, Selen
Huller i koden
vurdering af viden om QA, .NET, NUnit
Programmeringsopgave - Niveau: svær
QA | .NET, NUnit | Business Data Generator Interface - Implementer NUnit-testene for
IDataProcessing
grænseflade i denNUnitDataProcessing.Tests.DataProcessingTest
projekt, der verificerer forretningskrav.
- Testede færdigheder
- Varighed
- 73 minutter max.
- Evaluering
- Automatisk
- Testoversigt
-
Spørgsmål efter valg
vurdering af viden om Java og QA
Huller i koden
vurdering af viden om Java og QA
Programmeringsopgave - Niveau: Medium
QA | Java, JUnit | Automat - Skriv enhedstests til verifikation af en automat.
- Testede færdigheder
- Varighed
- 46 minutter max.
- Evaluering
- Automatisk
- Testoversigt
-
Spørgsmål efter valg
vurdering af viden om Python
Huller i koden
vurdering af viden om Python
Programmeringsopgave - Niveau: Medium
Python | Bibliotek til valutaveksling
- Testede færdigheder
- Varighed
- 39 minutter max.
- Evaluering
- Automatisk
- Testoversigt
-
Spørgsmål efter valg
vurdering af viden om Java
Huller i koden
vurdering af viden om JUnit 5, Java, QA
Programmeringsopgave - Niveau: Medium
Java | JUnit | Flight Manager - Implementer de manglende funktioner i programmet, der er ansvarligt for at administrere flydata.
Når du har indsnævret antallet af kandidater, kan du gå dybere ned i deres kompetencer i en interview til vurdering af færdigheder.
TLDR
Er QA-testere ved at uddø? Absolut ikke.
Er de nødt til at ændre sig for at overleve? Det gør de helt sikkert.
Kan den gennemsnitlige softwareudvikler erstatte en QA-tester? Det tvivler jeg virkelig på.
Hvad er dine tanker?
Del indlæg