Menu

7-trins praktisk implementering af manuel test inden produktionsudgivelse

7 step practical implementation manual testing before production release

Prøv Vores Instrument Til At Fjerne Problemer

I det forrige indlæg i denne serie omkring manuel testning forsøgte jeg at kaste så meget lys som muligt på det grundlæggende ved manuel testning.

Hvis du gik glip af det, du kan læse det her .

Jeg håber, at det lykkedes at bringe dig så tæt som muligt på de svar, du ledte efter.

I så fald ville du ikke elske at vide mere om den praktiske implementering af manuel test, hvordan man bliver mere fortrolig med det, og hvordan man rent faktisk starter en karriere i det?

Denne artikel vil kaste lys over alle disse aspekter.

Implementering af manuel test

Lad os begynde.

Hvad du vil lære:

Manuel testcyklus

At forstå Manuel testcyklus eller Software Test Life Cycle (STLC), først og fremmest skal vi forstå Software Development Life Cycle (SDLC), som jeg er sikker på, at du allerede har forståelse for.

Folk henviser til dem separat, men er ikke sikre på, om de virkelig kan eksistere. De er så tæt integreret med hinanden. Nå, selv disse cyklusser har så mange versioner af dem oprettet og flyder i internetrummet, de varierer meget, hvilken udviklingsmodel der vælges.

Som de fleste af verden går smidig i disse dage vil jeg holde mine ting forenklet omkring Agile.

7 praktiske manuelle testtrin inden produktionsfrigivelse

Her går jeg.

Husk, at jeg taler om både SDLC og STLC.

# 1) Kravsamling

Kravsindsamlingsfase

Forretningsanalytiker (person / team ansvarlig for kravindsamling) dokumenterer kravene. De dokumenterer kravene, det er højdepunktet, du kan kun holde fokus på det. Hvor det er dokumenteret betyder mindre.

Folk bruger alt til at dokumentere disse, der passer dem, men ikke begrænset til traditionelle platforme som MS word doc, moderne platforme som Jira / Rally og new age-værktøjer som Trello.

# 2) Kravsdiskussion / deling

Kravs diskussionsfase

Forretningsanalytiker skal derefter dele dokumenterede krav med Development Team, Testing Team og UX-teamet (hvis nødvendigt). Dette sker normalt via et formelt møde, hvor SPOC'er (Single Point Of Contacts eller et helt team, det afhænger) fra alle tre funktioner opfylder og forstår hele kravet.

I en sund arbejdskultur diskuteres kravene fra alle vinkler, og hvert medlem af mødet kan stille spørgsmål og tvivl. Når alle spørgsmålene er besvaret og den nødvendige ændring i kravet er udført, kan denne fase betragtes som udført. Igen, hvad man kalder dette særlige møde / trin, og dets dokumentation adskiller sig fra virksomhed til virksomhed.

Yderligere læsning=> Sådan gennemgår du SRS-dokument

Når alle spørgsmålene er besvaret og nødvendige ændringer i kravet er udført, kan denne fase betragtes som Færdig .

Igen, hvad man kalder dette særlige møde / trin, og dets dokumentation adskiller sig fra virksomhed til virksomhed.

For eksempel, dokumentationen kaldes eller nedbrydes som SRS (System Requirement Specification), Requirement Document, Epic, User Story, Story point (muligvis, mindste krav unit) osv. På de samme linjer kaldes dette møde, hvor kravet deles som Krav Diskussionsmøde, pleje, hulemøde osv. Jeg håber, du får min pointe?

Ved at trykke på disse terminologier, så du altid husker hovedideen uanset de forskellige navne.

Efter dette møde udløses to trin på samme tid, i ingen særlig rækkefølge, se de næste to trin.

# 3) Design

Udviklingsteamet starter med deres tekniske design, så snart kravene diskuteres, og når der ikke er nogen større ventepunkter. Hvad der sker i denne fase, adskiller sig igen fra firma til virksomhed.

Denne fase kan omfatte, men ikke begrænset til, følgende opgaver:

  • Beslutning om udviklingsmetoden
  • Forbereder design dokument
  • Design af flowdiagrammer
  • Estimering af indsatsen
  • Find ud af virkningen af ​​dette nye krav på enhver eksisterende funktionalitet
  • Behov for at lappe eksisterende data osv.

UX-teamet kan også blive involveret i denne fase, når der er en UI-ændring, eller der skal udvikles en ny skærm. UX-teamet hjælper udviklingshold og testteam med UI-prototype til funktionalitet / funktion i diskussionen. Dette kan være et Photoshop-dokument, et enkelt billede, en PowerPoint-præsentation eller noget andet, der får udviklingsholdet til at forstå, hvordan skærmene skal udvikles.

Bemærk: Ideelt set vises disse skærme eller i det mindste deres kladdeversioner kun i diskussionssessionen Krav for at hjælpe holdet med at opbygge en bedre forståelse. Det bliver mærket til det oprindelige krav, så det kan henvises til til enhver tid.

# 4) Testscenarie / Design af testcase

Testscenarie Designfase

Parallelt med designfasen starter testteamet med at opbygge testscenarier og / eller testsager baseret på diskuterede krav. Om testscenarier altid altid skrives først og derefter bryder ind i testsager, er noget, der igen ikke er konstant.

Efter min mening, uanset om du dokumenterer testscenarierne eller ej, er de altid der før testsager. Testscenarie er dit punkt, du kan sige, de guider dig til at bore tingene ned yderligere. Når testcase-skrivningen er afsluttet, kan den deles med Development-teamet for at give dem en ide om testomfanget, og de kan også sikre, at den udvikling, der er sket eller sker, tilfredsstiller de skriftlige testsager.

Når testcase-skrivningen er afsluttet, kan den deles med Development-teamet for at give dem en ide om testomfanget, og de kan også sikre, at den udvikling, der er sket eller sker, tilfredsstiller de skriftlige testsager.

Testcases, når de er skrevet, bliver ideelt set gennemgået af en testleder eller peer fra mange vinkler som:

  • Krav dækning
  • Stave grammatik
  • Test sagsskrivningsstandarder (intet andet end en skabelon, som et team / firma følger)
  • Bagudkompatibilitet
  • Platformskompatibilitet
  • Testreferencer
  • Typer af målrettet test osv.

Yderligere læsning=> Skrivning af testsager fra SRS-dokument

Ideelt set sendes de først til gennemgang og nødvendig ændring til udviklingsteamet.

Da jeg sagde 'når testcase-skrivning er forbi', mente jeg en gang 'alle testcases blev skrevet baseret på fuldstændig viden om det givne krav og mulige testscenarier afsløret indtil det bestemte tidspunkt'. Det er næsten umuligt at have 100% testdækningsdækning første gang.

Der vil være fejl, som du finder i tilfældige (men tilsigtede) handlinger, i rent tilfældige handlinger (abetest) og i nogle sjældne scenarier. Der er chancer for, at du vil gå glip af få af disse. Og på et eller andet tidspunkt går du måske glip af selv meget grundlæggende, når alt kommer til alt er du menneske. Men her kan i det mindste en god test case gennemgang og en struktureret måde at skrive test case redde dig på.

Oftere end ikke fortsætter en tester eller et testteam med at tilføje flere og flere testsager til det eksisterende stykke, da de afdækker sandheden eller tænker mere på kravene.

Nå, nogle af jer må nu være i tvivl om min viden om softwaretest, da noget ord (som slags er blevet en norm i softwaretest) ikke er brugt af mig endnu. Testplan, ikke?

Lad mig sige noget om dette. Jeg tror stærkt på behovet for de fleste af de oplysninger, der er nævnt i testplanen, men at dokumentere dem alle på samme sted og gøre det absolut obligatorisk er noget, jeg finder diskutabelt.

Under alle omstændigheder er det helt et separat emne at diskutere. At dele en 'passer alle' information om dette er vanskelig, men lad mig prøve.

Enten dig, du med din testledning eller din testledning udarbejder testplan, eller du dokumenterer de krævede oplysninger forskellige steder.

Yderligere læsning=> Sådan skriver du testplandokument

Oplysninger, der burde fryses absolut på dette stadium:

  • Testens omfang: Krav, bagudkompatibilitet, platforme, enheder osv.
  • Person / team, der skal teste
  • Test indsats estimering
  • Begrænsninger: Eventuelle antagelser eller begrænsninger accepteret på forhånd.
  • Folk dokumenterer desuden adgangskriterier, exitkriterier, risiko osv., Som jeg ikke rigtig har brug for separat omtale, da det snarere skulle være en normal forståelse.
    • Indgangskriterier (Hvornår skal test startes): Få starter, når der er testbar del af funktionalitet til rådighed til test. Få vent på, at hele funktionaliteten kan testes. Når det er fundet, at det grundlæggende flow fungerer, starter testningen.
    • Udgangskriterier (Hvornår skal stoppes): Når der ikke er nogen blokering, kan kritiske og større (udsat for stød) defekter i test i åbent stadium stoppes. Eller midtvejs, når der er alt for mange defekter, der kan testes, kan test stoppes af passende interessenter.
    • Risiko : Forretningsrisiko eller funktionel risiko, hvis test ikke sker i henhold til den dokumenterede plan.

# 5) Udviklingsfase

Softwareudviklingsfase

Udviklingsteamet starter efter designfasen med faktisk udvikling og test af enheder, når og når de er færdige med udviklingen af ​​testbare kravstykker. De kan videregive funktionaliteten til test i bidder, når den implementeres, eller de kan videregive hele funktionaliteten på én gang.

I et ideelt scenarie sker formel kodegennemgang og test af hvidboks, inden den videreudviklede funktionalitet til test videreformidles. ideelt set bør udviklingsteamet også henvise til testtilfælde leveret af testteamet ud over krav og designdokumenter.

# 6) Testfase

Som nævnt tidligere er starten på denne fase forskellig fra virksomhed til virksomhed, team til team.

Testteamet begynder at teste enten når det kan testes (noget, som kan testes uafhængigt), en del af hele kravet er udviklet, eller når hele kravet er udviklet.

software til at downloade videoer fra ethvert websted

Lad mig gå nærmere ned i denne fase og tale om de vigtige opgaver:

  • Tester / Test Team starter med testrunde (sonderende test og udførelse af skriftlige testsager) og logføringsfejl
  • Udviklingsteam løser dem pr. Prioritet.
  • Ny build (kode) tages i det miljø, som testning sker på
  • Løste fejl bekræftes derefter af Tester / Test Team og markeres som Fixed
  • Denne cyklus fortsætter, indtil det tidspunkt, hvor exitkriterierne er nået.
  • Bemærk, at defekter efter behov også er markeret som ugyldig, duplikat og kan også kategoriseres som forbedringer.

En anden ting, der adskiller sig fra firma til firma, er, hvor mange testrunder der skal udføres. Som i nogle tilfælde sker den første testrunde på små funktionsdele, da de er klar, efterfulgt af en end-to-end testrunde i et andet miljø, når alle krav er udviklet. Men igen, jeg har også hørt om folk, der laver tre ordentlige fulde testrunder og fjerde som fornuft / røgrunde.

Den første dagsorden bag at udføre flere testrunder er at teste funktionaliteten i forskellige miljøer og den anden til at foretage end-to-end-test, når alle historiepunkter er udviklet. Sanity-runde sker normalt for at få hurtig selvtillid, når alle historier i en udgivelse er udviklet og testet uafhængigt.

Læs detaljerede trin=> Testudførelsesfase

# 7) Gennemgang af forretningsanalytiker (BA)

Forretningsanalytiker gennemgår den stillede funktionalitet enten ved at henvise til testresultatet eller ved at henvise til testresultatet plus at lege med applikationen for at få en faktisk fornemmelse. Dette trin igen udsættes for forskellige handlinger på tværs af virksomheder.

BA kan gennemgå omfanget af hele udgivelsen på én gang eller i bidder. Afhængigt af det samme kan dette trin komme inden den endelige sundhedsprøvning eller efter den sidste sundhedsprøvningsrunde af testteamet.

Over 7 trin sker for at alle brugerhistorier / krav skal opfyldes, især frigivelse (forsendelse). Når alle disse trin er gennemført for alle kravene, siges frigivelsen at være klar til forsendelse.

# 8) Forsendelse / frigivelse

Udgivelsen er mærket som klar til forsendelse efter en vellykket gennemgang af forretningsanalytikeren.

Anbefalet læsning=> Test frigivelsesproces

Typer af manuel test (læs menneskelig) test

Nå, hvis vi skal tale om overordnede typer af test i tal, så et sted jeg fandt over 100 typer test med forskellige navne . For at være ærlig er jeg ikke smart nok til at forstå sondringen mellem alle disse typer (ordspil beregnet).

Det er lige og simpelt: Test af applikationens funktionalitet mod det givne krav med menneskelig indsats og intelligens. Det bliver yderligere opdelt i få typer baseret på omfanget og dagsordenen for testning. Typer anført i næste afsnit.

Det bliver yderligere opdelt i få typer baseret på omfanget og dagsordenen for testning. Typer anført i næste afsnit.

Hvis jeg har tilladelse til det, så lad mig tale nogle få linjer af menneskelig testning (som jeg opfordrer hver tester til at foretage over manuel funktionel testning). Bliv ikke forvirret, manuel funktionel testning er efter min mening en delmængde af Human Testing. Fordi der er så mange ting, som kun menneskelige sind kan gøre.

Nedenfor er listen med nogle af de populære og vigtige testtyper, som kan kategoriseres i human test:

  • Manuel funktionstest : Test af applikationens funktionalitet mod det givne krav med menneskelig indsats og intelligens. Yderligere bliver opdelt i ganske mange typer baseret på testomfang og dagsorden, som systemtest, enhedstest, røgtest, sundhedstest, integrationstest, regressionstest, UI-test osv.
  • Test af ydeevne : Dette kategoriseres i ikke-funktionel test, ikke? Men igen er det mennesket, der implementerer det, skønt henrettelse bliver udført af enten menneske eller værktøj. Testeren skal i det mindste udføre denne test med hensyn til svartid (for at se om det er acceptabelt), hvis han ikke skal bruge noget værktøj til belastningstest og alt andet.
  • Browser / Platformkompatibilitetstest: Applikation, der testes, skal se ud og fungere som forventet (selvfølgelig kan der være en mindre forskel afhængigt af browsermotor) på tværs af browsere og platforme (eller enheder, hvis det er en mobilapplikation).
  • Usability Testing : Lad mig først og fremmest være enig i, at dette er et stort emne i sig selv og normalt ejes af specialister i brugervenlighedstest. Jeg mener stadig, at vi som tester i det mindste skal rapportere eller fremhæve, hvis vi finder noget som mindre anvendeligt, eller hvis vi deler vores synspunkt.
  • Sikkerhedstest : Igen meget stor testtype og kræver naturligvis meget praktisk viden. Testeren skal prøve at lære og udføre i det mindste grundlæggende tests som URL-manipulation, Scripting på tværs af websteder, SQL-injektion, Session-kapring osv. Afhængigt af tilgængelig viden og hvor det er relevant.
  • Test af flere lejemål: Hvis din applikation er multi-lejer, dvs. enkelt forekomst, der indeholder data fra flere klienter, er denne test et must. Uanset eksplicit omtale i kravene skal dette gøres. En klients data, der vises til en anden, er en slags udviklings- og testkriminalitet.

Bemærk: Ovenstående synspunkter er mine personlige synspunkter. Jeg anbefaler dig også at se på den omfattende liste over testtyper til din viden og følge / bruge dem, hvis du finder det nødvendigt. I årevis har jeg forstået, at uanset om du bruger noget eller ej, du tror på noget eller ej, skal du stadig have noget kendskab til meget anvendte begreber inden for dit felt.

Det er alt sammen for denne del. Tak fordi du læste. Del dine synspunkter / feedback i kommentarer.

I næste og sidste del af dette manuel test tutorials serie , Jeg vil prøve at hjælpe jer alle med hvilket forberedelse du skal gøre, hvis du ønsker at komme ind i testfeltet, og hvad der er mulige måder at komme ind der.

Anbefalet læsning

^