Menu

QA-softwaretestningslister (inkluderet eksempler på tjeklister)

qa software testing checklists

Prøv Vores Instrument Til At Fjerne Problemer

Software QA test tjeklister

I dag bringer vi dig et andet kvalitetsværktøj, der så ofte er underudnyttet, at vi troede, vi ville genvask detaljer om det i håb om, at det genvinder sin mistede herlighed. Det er 'Tjekliste'.

Definition: En tjekliste er et katalog over emner / opgaver, der registreres til sporing. Denne liste kan enten bestilles i en rækkefølge eller være tilfældig.

Tjeklister er en del af vores daglige liv. Vi bruger dem i forskellige situationer fra indkøb af dagligvarer til at have en opgaveliste til dagens aktiviteter.

QA-softwaretest-tjeklister

Hvad du lærer:

Oversigt over tjeklister til test af QA-software

Så snart vi kommer til kontoret, opretter vi altid en liste over ting, der skal gøres for den dag / uge, som nedenfor:

Når og når et element på listen er færdigt, slår du det fra, fjerner det fra listen eller markerer det med et flueben - for at markere dets afslutning. Er det ikke alt for kendt for os?

Men er det alt, hvad det kan bruges til?

datadrevet ramme i selen webdriver

Kan vi bruge tjeklister i vores it-projekter formelt (specifikt QA), og hvis ja, hvornår og hvordan? Dette er hvad der vil blive dækket nedenfor.

Jeg går personligt ind for brugen af ​​tjeklister af følgende grunde:

  • Det er alsidigt - kan bruges til alt
  • Let at skabe / bruge / vedligeholde
  • Det er super nemt at analysere resultater (status for status / afslutning)
  • Meget fleksibel - du kan tilføje eller fjerne emner efter behov

Som det er almindelig praksis, vil vi tale om 'hvorfor' og 'hvordan' aspekterne.

  • Hvorfor har vi brug for tjeklister? : Til sporing og vurdering af færdiggørelse (eller ikke-afslutning). At notere opgaver, så intet overses.
  • Hvordan opretter vi tjeklister? : Nå, dette kunne ikke være enklere. Skriv alt ned punkt for punkt.

Tjeklister Eksempel på QA-processer:

Som jeg nævnte ovenfor, er der nogle områder i QA-feltet, hvor vi effektivt kan sætte checkliste-konceptet i gang og få gode resultater. To af de områder, som vi vil se i dag, er:

  • Testparathed gennemgang
  • Hvornår skal man stoppe med at teste eller afslutte checkliste

# 1) Testberedskabsanmeldelse

Dette er en meget almindelig aktivitet, der udføres af hvert QA-team for at afgøre, om de har alt, hvad de har brug for til at gå videre i testudførelsesfasen. Dette er også en tilbagevendende aktivitet før hver testcyklus i projekter, der involverer flere cyklusser.

For ikke at løbe ind i problemer efter testfasen begynder og indse, at vi gik i eksekveringsfasen for tidligt, skal hvert QA-projekt foretage en gennemgang for at fastslå, at det har alle de input, der er nødvendige for en vellykket test.

En tjekliste letter denne aktivitet perfekt. Det giver dig mulighed for at lave en liste over 'ting, der er nødvendige' på forhånd og gennemgå hvert emne sekventielt. Du kan endda genbruge arket, når det er oprettet til efterfølgende testcyklusser.

Yderligere information: Testberedskabsanalyse oprettes generelt, og gennemgangen udføres af repræsentanten for QA-teamet. Resultaterne deles med PM'erne og de andre teammedlemmer for at angive, om testteamet er klar eller ikke til at gå ind i testudførelsesfasen.

Nedenfor er et eksempel på en prøve tjekliste til testberedskab:

Test Readiness Review (TRR) Kriterier

Status

Alle krav afsluttet og analyseret Færdig
Testplan oprettet og gennemgået Færdig
Test Cases forberedelse Færdig
Test sag gennemgang og log af
Testdata tilgængelighed
Røgtest
Er Sanity Test udført?
Hold opmærksom på roller og ansvar
Hold opmærksom på de forventede leverancer af dem
Holdet opmærksom på Kommunikationsprotokol
Teamets adgang til applikationen, versionskontrolværktøjer, Test Management
Holdet er trænet
Tekniske aspekter - Server1 opdateret eller ej?
Standarder for defektrapportering er defineret

Nu er alt, hvad du skal gøre med denne liste, markeret som færdig eller ikke færdig.

# 2) Tjekliste for udgangskriterier

Som navnet antyder, er dette en tjekliste, der hjælper med at træffe beslutning om, hvorvidt en testfase / cyklus skal stoppes eller fortsættes.

Da et defektfrit produkt ikke er muligt, og vi bliver nødt til at sikre os, at vi tester bedst muligt inden for den givne tid - der oprettes en tjekliste med nedenstående effekt for at spore de vigtigste kriterier, der skal opfyldes at betragte en testfase som tilfredsstillende.

Udgangskriterier

Status

100% testskripter udført Færdig
95% bestået rate af testskripter
Ingen åbne kritiske og høje sværhedsgrader
95% af defekter med medium sværhedsgrad er blevet lukket
Alle resterende mangler annulleres eller dokumenteres som ændringsanmodninger for en fremtidig frigivelse
Alle forventede og faktiske resultater registreres og dokumenteres med testscriptet Færdig
Alle testmålinger indsamles på baggrund af rapporter fra HP ALM
Alle fejl er logget på HP ALM Færdig
Testlukningsnotatet er afsluttet og underskrevet

Testcheckliste

Vil du starte et nyt projekt til test? Glem ikke at kontrollere denne testcheckliste i hvert eneste trin i din projektlivscyklus. Listen svarer for det meste til testplanen, den dækker alle kvalitetssikrings- og teststandarder.

Testcheckliste:

  1. Opret system- og accepttests ()
  2. Start oprettelse af accepttest ()
  3. Identificer testteam ()
  4. Opret arbejdsplan ()
  5. Opret testmetode ()
  6. Link acceptkriterier og krav for at danne grundlaget for accepttest ()
  7. Brug en delmængde af systemtesttilfælde til at danne kravsdel af Acceptance Test ()
  8. Opret scripts til brug for kunden for at demonstrere, at systemet opfylder kravene ()
  9. Opret en testplan. Inkluder mennesker og alle andre ressourcer. ()
  10. Test for accept af adfærd ()
  11. Start oprettelse af systemtest ()
  12. Identificer testteammedlemmer ()
  13. Opret arbejdsplan ()
  14. Bestem ressource krav ()
  15. Identificer produktivitetsværktøjer til test ()
  16. Bestem datakrav ()
  17. Opnå en aftale med Data Center ()
  18. Opret testmetode ()
  19. Identificer alle nødvendige faciliteter ()
  20. Få og gennemgå eksisterende testmateriale ()
  21. Opret en oversigt over testgenstande ()
  22. Identificer designtilstande, betingelser, processer og procedurer ()
  23. Bestem behovet for kodebaseret (hvid boks) test. Identificer forhold. ()
  24. Identificer alle funktionelle krav ()
  25. Afslut lageroprettelse ()
  26. Start oprettelse af testsag ()
  27. Opret testcases baseret på opgørelsen over testartikler ()
  28. Identificer logiske grupper af forretningsfunktioner for det nye system ()
  29. Opdel testcases i funktionelle grupper sporet til testvarelager ()
  30. Design datasæt, der svarer til testsager ()
  31. Afslut oprettelse af testsag ()
  32. Gennemgå forretningsfunktioner, testsager og datasæt med brugere ()
  33. Få afmelding af testdesign fra projektleder og QA ()
  34. Afslut testdesign ()
  35. Start testforberedelse ()
  36. Få ressourcer til testsupport ()
  37. Skitsere forventede resultater for hver testtilfælde ()
  38. Indhent testdata. Valider og spor dem til testsager ()
  39. Forbered detaljerede testskripter til hver testtilfælde ()
  40. Forbered og dokumenter miljøopstillingsprocedurer. Inkluder sikkerhedskopierings- og genopretningsplaner ()
  41. Afslut testforberedelsesfase ()
  42. Test af adfærdssystem ()
  43. Udfør testskripter ()
  44. Sammenlign det faktiske resultat med forventet ()
  45. Dokument afvigelser og opret problemrapport ()
  46. Forbered vedligeholdelsesfase input ()
  47. Udfør testgruppen igen efter reparationer af problemer ()
  48. Opret en endelig testrapport, medtag listen over kendte fejl ()
  49. Få formel afmelding ()

Automatiseringscheckliste

Hvis du svarer ja på et af disse spørgsmål, skal din test overvejes seriøst for automatisering.

Q # 1) Kan testsekvensen af ​​handlinger defineres?

Svar: Er det nyttigt at gentage rækkefølgen af ​​handlinger mange gange? Eksempler på dette ville være acceptstest, kompatibilitetstest, præstationstest og regressionstest.

Q # 2) Er det muligt at automatisere rækkefølgen af ​​handlinger?

Svar: Dette kan bestemme, at automatisering ikke er egnet til denne rækkefølge af handlinger.

Q # 3) Er det muligt at 'semi-automatisere' en test?

Svar: Automatisering af dele af en test kan fremskynde testudførelsestiden.

Spørgsmål nr. 4) Er opførelsen af ​​den testede software den samme med automatisering som uden?

Svar: Dette er en vigtig bekymring for Performance Testing.

Spørgsmål nr. 5) Tester du ikke-UI-aspekter af programmet? Svar: Næsten alle ikke-UI-funktioner kan og bør være automatiserede tests.

Q # 6) Har du brug for at køre de samme tests på flere hardwarekonfigurationer?

hvordan man tilføjer et element til en matrix

Svar: Kør ad-hoc-tests (Bemærk: Ideelt set skal enhver fejl have en tilknyttet testcase. Ad hoc-test udføres bedst manuelt. Du bør prøve at forestille dig dig selv i virkelige situationer og bruge din software som din kunde ville. under ad hoc-test bør nye testcases oprettes, så de let kan reproduceres, og så regressionstest kan udføres, når du kommer til Zero Bug Build-fasen.)

En Ad-hoc-test er en test, der udføres manuelt, hvor testeren forsøger at simulere den virkelige brug af softwareproduktet. Det er ved kørsel af ad hoc-test, at de fleste fejl findes. Det skal understreges, at automatisering aldrig kan erstatte manuel test.

Punkter at bemærke:

  • Ovenstående to er eksempler, der viser brugen af ​​tjeklister til QA processer , men brugen er ikke begrænset til disse to områder.
  • Emnerne på hver liste er også indikatorer, der giver læserne en idé om, hvilken slags emner der kan medtages og spores - dog kan listen udvides og / eller komprimeres efter behov.

Vi håber virkelig, at ovenstående eksempler har været en succes med at frembringe potentialet for tjeklister til kvalitets- og it-processer.

Så næste gang du har brug for et simpelt værktøj, der er semi-formelt, simpelt og effektivt, håber vi, at vi har orienteret dig mod at give tjeklister en chance. Nogle gange er den enkleste løsning den bedste.

Anbefalet læsning

^