Meny

7-trinns praktisk implementering av manuell testing før produksjonsutgivelse

7 step practical implementation manual testing before production release

Prøv Instrumentet Vårt For Å Eliminere Problemer

I forrige innlegg i denne serien rundt manuell testing prøvde jeg å kaste så mye lys som mulig på det grunnleggende om manuell testing.

Hvis du savnet det, du kan lese den her .

Jeg håper det var vellykket å ta deg så nær som mulig svarene du lette etter.

I så fall vil du ikke gjerne vite mer om den praktiske implementeringen av manuell testing, hvordan bli bedre kjent med den og hvordan du faktisk kan starte en karriere i den?

Denne artikkelen vil kaste lys over alle disse aspektene.

Implementering av manuell testing

La oss begynne.

Hva du vil lære:

Manuell testsyklus

Å forstå Manuell testsyklus eller Software Test Life Cycle (STLC), først og fremst må vi forstå Software Development Life Cycle (SDLC), som jeg er sikker på at du allerede har forståelse for.

Folk refererer til dem hver for seg, men er ikke sikre på om de virkelig kan eksistere. De er så tett integrert med hverandre. Vel, selv disse syklusene har så mange versjoner av dem opprettet og flytende i internettområdet, de varierer stort sett på hvilken utviklingsmodell som er valgt.

Som de fleste av verden går smidig i disse dager vil jeg holde tingene mine forenklet rundt Agile.

7 praktiske manuelle teststrinn før produksjonsutgivelsen

Her går jeg.

Husk at jeg snakker om både SDLC og STLC.

# 1) Kravsamling

Kravsamlingsfase

Forretningsanalytiker (person / team ansvarlig for kravsamling) dokumenterer kravene. De dokumenterer kravene, det er høydepunktet, du kan bare holde fokus på det. Hvor det er dokumentert, betyr mindre.

Folk bruker alt for å dokumentere disse som passer dem, men ikke begrenset til tradisjonelle plattformer som MS word doc, moderne plattformer som Jira / Rally og new age-verktøy som Trello.

# 2) Kravdiskusjon / deling

Kravdiskusjonsfase

Business Analyst skal da dele dokumenterte krav med Development Team, Testing Team og UX-teamet (om nødvendig). Dette skjer vanligvis via et formelt møte der SPOC-er (Single Point Of Contacts eller et helt team, det avhenger) fra alle tre funksjonene oppfyller og forstår hele kravet.

I en sunn arbeidskultur blir kravene diskutert fra alle vinkler, og hvert medlem av møtet kan stille spørsmål og tvil. Når alle spørsmålene er besvart og nødvendig endring i kravet er gjort, kan denne fasen betraktes som Ferdig. Igjen det man kaller dette møtet / trinnet og dokumentasjonen, er det forskjellig fra selskap til selskap.

Videre lesning=> Hvordan gjennomgå SRS-dokument

Når alle spørsmålene er besvart og nødvendige endringer i kravet er gjort, kan denne fasen betraktes som Ferdig .

Igjen det man kaller dette møtet / trinnet og dokumentasjonen, er det forskjellig fra selskap til selskap.

For eksempel, dokumentasjonen kalles eller brytes ned som SRS (System Requirement Specification), Requirement Document, Epic, User Story, Story point (muligens, minste kravsenhet) osv. På lignende linjer kalles dette møtet der kravet deles som Krav Diskusjonsmøte, stell, hullmøte osv. Jeg håper du får poenget mitt?

Å trykke på disse terminologiene slik at du alltid husker hovedideen uavhengig av de forskjellige navnene.

Legg ut dette møtet to trinn blir utløst samtidig, i ingen spesiell rekkefølge, se neste to trinn.

# 3) Design

Utviklingsteamet starter med sin tekniske design så snart kravene er diskutert og når det ikke er noen større ventende poeng. Det som gjøres i denne fasen, er forskjellig fra selskap til selskap.

Denne fasen kan involvere, men ikke begrenset til, følgende oppgaver:

  • Bestemme utviklingsmetoden
  • Forbereder design dokument
  • Designe flytdiagrammer
  • Anslå innsatsen
  • Å finne ut hvilken innvirkning dette nye kravet har på eksisterende funksjonalitet
  • Trenger å lappe eksisterende data osv.

UX-teamet kan også bli involvert i denne fasen når det er en UI-endring eller en ny skjerm skal utvikles. UX-teamet hjelper utviklingsteamet og testteamet med UI-prototype for funksjonaliteten / funksjonen i diskusjonen. Dette kan være et Photoshop-dokument, enkelt bilde, PowerPoint-presentasjon eller noe annet som får utviklingsgruppen til å forstå hvordan skjermene skal utvikles.

Merk: Ideelt sett vises disse skjermbildene eller i det minste utkastversjonene i diskusjonsøkten for krav bare for å hjelpe teamet til å bygge en bedre forståelse. Det blir merket til det opprinnelige kravet, slik at det kan refereres til det til enhver tid.

# 4) Test Scenario / Test Case design

Testscenario Designfase

Parallelt med designfasen, starter testteamet med å bygge testscenarier og / eller testsaker basert på diskuterte krav. Hvorvidt testscenarier alltid blir skrevet først og deretter bryter inn i testsaker, er noe som igjen ikke er konstant.

Enten du dokumenterer testscenariene eller ikke, er de etter min mening alltid der før testsaker. Testscenario er ditt punkt du kan si, de veileder deg til å bore ned ting videre. Når prøvesakeskrivingen er over, kan den deles med utviklingsteamet for å gi dem en ide om testingsomfanget, og de kan også sørge for at utvikling som har skjedd eller skjer tilfredsstiller de skriftlige prøvesakene.

Når prøvesakeskrivingen er over, kan den deles med utviklingsteamet for å gi dem en ide om testingsomfanget, og de kan også sørge for at utvikling som har skjedd eller skjer tilfredsstiller de skriftlige prøvesakene.

Test tilfeller en gang skrevet ideelt sett bli gjennomgått av en testleder eller fagfelle fra mange vinkler som:

  • Kravsdekning
  • Stavegrammatikk
  • Test saksskrivingsstandarder (ingenting annet enn en mal som et team / selskap følger)
  • Bakoverkompatibilitet
  • Plattformkompatibilitet
  • Test datareferanser
  • Typer test målrettet, etc.

Videre lesning=> Skrive prøvesaker fra SRS-dokument

Ideelt sett sendes de videre til utviklingsteamet etter gjennomgang og nødvendig modifisering.

Da jeg sa 'når testkortskriving er over', mente jeg en gang 'alle testkassene er skrevet basert på fullstendig kunnskap om gitt krav og mulige testscenarier avdekket til det bestemte tidspunktet'. Det er nesten umulig å ha 100% testdekning de første gangene.

Det vil være feil som du vil finne i tilfeldige (men tiltenkte) handlinger, i rent tilfeldige handlinger (monkey testing) og i noen sjeldne scenarier. Det er sjanser du vil savne på få av disse. Og på et eller annet tidspunkt kan du gå glipp av til og med veldig grunnleggende, når alt kommer til alt er du menneske. Men her kan i det minste en god prøvesakgjennomgang og en strukturert måte å skrive saksskriving redde deg på.

Oftere enn ikke fortsetter en tester eller et testteam å legge til flere og flere testtilfeller til den eksisterende delen når de avdekker sannheten eller tenker mer på kravene.

Vel, nå må noen av dere være i tvil om min kunnskap om programvaretesting, ettersom noe ord (som har blitt en norm i programvaretesting) ikke er brukt av meg ennå. Testplan ikke sant?

La meg si noe om dette. Jeg tror sterkt på behovet for det meste av informasjonen som er nevnt i testplanen, men å dokumentere dem alle på samme sted og gjøre det absolutt obligatorisk er noe jeg synes er diskutabelt.

Uansett, det er helt et eget tema å diskutere. Å dele en 'passer alle' informasjon om dette er vanskelig, men la meg prøve.

Enten du, du med testledningen eller testledelsen din utarbeider testplan, eller du dokumenterer nødvendig informasjon på forskjellige steder.

Videre lesning=> Hvordan skrive dokument for testplan

Informasjon som burde være absolutt frossen på dette stadiet:

  • Omfanget av testing: Krav, bakoverkompatibilitet, plattformer, enheter osv.
  • Person / Team som skal teste
  • Test innsatsestimering
  • Begrensninger: Eventuelle antagelser eller begrensninger akseptert på forhånd.
  • Mennesker dokumenterer i tillegg oppføringskriterier, utgangskriterier, risiko osv. Som jeg tror egentlig ikke trenger separat omtale, da det heller bør være en normal forståelse.
    • Oppføringskriterier (Når skal du begynne å teste): Få starter når det er en testbar del av funksjonaliteten som er tilgjengelig for testing. Få vent på at hele funksjonaliteten kan testes. Når grunnstrømmen er funnet å fungere, starter testingen.
    • Utgangskriterier (Når skal stoppes): Når det ikke er noen blokkerer, kan kritiske og store (utsatt for støt) defekter i test på åpent trinn stoppes. Eller midtveis, når det er altfor mange mangler som testes kan stoppes av aktuelle interessenter.
    • Fare : Forretningsrisiko eller funksjonell risiko hvis testing ikke skjer i henhold til dokumentert plan.

# 5) Utviklingsfase

Programvareutviklingsfase

Utviklingsteamet starter etter prosjekteringsfasen med faktisk utvikling og enhetstesting når og når de er ferdige med utviklingen av testbare kravbiter. De kan formidle funksjonaliteten for testing i biter når og når den implementeres, eller de kan gi hele funksjonaliteten på en gang.

I et ideelt scenario skjer formell kodegjennomgang og testing av hvit boks før den videreutviklede funksjonaliteten for testing videreføres. ideelt sett bør utviklingsteamet også henvise til testtilfeller levert av testteamet i tillegg til krav og designdokumenter.

# 6) Testfase

Som nevnt tidligere, er starten på denne fasen forskjellig fra selskap til selskap, team til team.

Testteamet starter tester enten når det kan testes (noe som kan testes uavhengig av hverandre) en del av hele kravet er utviklet, eller når hele kravet er utviklet.

qa testing intervju spørsmål for erfarne

La meg gå nærmere ned i denne fasen og snakke om viktige oppgaver:

  • Tester / Testing Team starter med testrunde (utforskende testing og gjennomføring av skriftlige testsaker) og loggfeil
  • Utviklingsteam løser dem i henhold til prioritet.
  • Nybygg (kode) blir tatt på miljøet som testingen skjer på
  • Løste feil blir deretter verifisert av Tester / Testing Team og merket som Fixed
  • Denne syklusen fortsetter til det tidspunktet utgangskriteriene er nådd.
  • Vær oppmerksom på at etter behov er mangler også merket som ugyldig, duplikat og kan også kategoriseres som forbedringer.

En annen ting som er forskjellig fra selskap til selskap er hvor mange testrunder som skal gjøres. Som i noen tilfeller skjer den første testrunden på små funksjonsdeler ettersom de er klare, etterfulgt av en end-to-end testrunde i et annet miljø når alle kravene er utviklet. Men igjen, jeg har også hørt om folk som gjør tre ordentlige fullstendige testrunder og fjerde som sunnhet / røykrunde.

Den første agendaen bak å gjøre flere testrunder er å teste funksjonaliteten i forskjellige miljøer, og den andre for å utføre end-to-end-testing når alle historiepoengene er utviklet. Sanity-runde får vanligvis rask selvtillit når alle historier i en utgivelse er utviklet og testet uavhengig.

Les detaljerte trinn=> Testutførelsesfase

# 7) Bedriftsanalytiker (BA) gjennomgang

Forretningsanalytiker vurderer den spurte funksjonaliteten enten ved å referere til testresultat eller ved å referere til testresultat pluss å leke med applikasjonen for å få en faktisk følelse. Dette trinnet blir igjen utsatt for forskjellige handlinger på tvers av selskaper.

BA kan gjennomgå omfanget av hele utgivelsen på en gang eller i biter. Avhengig av det samme, kan dette trinnet komme før den endelige fornuftstesten eller etter den siste fornuftstesten av testteamet.

Over 7 trinn skjer for at alle brukerhistoriene / kravene skal oppfylles, spesielt utgivelse (forsendelse). Når alle disse trinnene er fullført for alle kravene, sies utgivelsen å være klar for levering.

# 8) Forsendelse / frigjøring

Utgivelsen er merket som Klar for forsendelse etter vellykket gjennomgang av Business Analyst.

Anbefalt lesing=> Testutgivelsesprosess

Typer manuell testing (les menneskelig)

Vel, hvis vi må snakke om generelle typer testing i antall, så et sted jeg fant over 100 typer testing med forskjellige navn . For å være ærlig er jeg ikke smart nok til å forstå skillet mellom alle disse typene (ordspill ment).

Det er rett og greit: Testing av funksjonaliteten til applikasjonen mot det gitte kravet med menneskelig innsats og intelligens. Det blir videre delt inn i få typer basert på omfanget og agendaen for testing. Typer oppført i neste para.

Det blir videre delt inn i få typer basert på omfanget og agendaen for testing. Typer oppført i neste para.

Hvis jeg har lov til det, la meg snakke noen linjer med menneskelig testing (som jeg oppfordrer hver tester til å utføre bare manuell funksjonstesting). Ikke bli forvirret, etter mitt syn er manuell funksjonell testing en delmengde av menneskelig testing. Fordi det er så mange ting som bare menneskelig sinn kan gjøre.

Nedenfor er listen med noen av de populære og viktige testtypene som kan kategoriseres i menneskelig testing:

  • Manuell funksjonstesting : Testing av funksjonaliteten til applikasjonen mot det gitte kravet med menneskelig innsats og intelligens. Videre blir delt inn i ganske mange typer basert på omfang og agenda for testing, som systemtesting, enhetstesting, røykprøving, sunnhetstest, integrasjonstesting, regresjonstesting, UI-testing, etc.
  • Ytelsestesting : Dette blir kategorisert i ikke-funksjonell testing, ikke sant? Men igjen er det mennesket som implementerer det, selv om henrettelse blir gjort av enten menneske eller verktøy. Testeren bør i det minste gjøre denne testingen når det gjelder responstid (for å se om det er akseptabelt) hvis han ikke skal bruke noe verktøy for belastningstesting og alt.
  • Nettleser / Testing av plattformskompatibilitet: Søknad som testes skal se ut og fungere som forventet (åpenbart kan det være en liten forskjell avhengig av nettlesermotor) på tvers av nettlesere og plattformer (eller enheter hvis det er en mobilapplikasjon).
  • Brukervennlighetstesting : La meg først og fremst være enig i at dette er et stort tema i seg selv og vanligvis eies av spesialister innen brukervennlighetstesting. Jeg tror fortsatt at vi som tester i det minste burde rapportere eller fremheve om vi finner noe som mindre brukbart, eller vi bør dele vårt syn.
  • Sikkerhetstesting : Igjen veldig stor testtype og krever selvfølgelig mye praktisk kunnskap. Testeren skal prøve å lære og utføre i det minste grunnleggende tester som URL-manipulering, skripting på tvers av nettsteder, SQL-injeksjon, Session-kapring, etc. avhengig av tilgjengelig kunnskap og hvor det er aktuelt.
  • Multi-tenancy Testing: Hvis applikasjonen din er flere leietakere, dvs. enkeltforekomster som inneholder data fra flere klienter, er denne testen et must. Uansett eksplisitt omtale i kravene, bør dette gjøres. En klients data som vises til en annen er en slags utviklings- og testkriminalitet.

Merk: Over synspunkter er mine personlige synspunkter. Jeg anbefaler deg også å ta en titt på den omfattende listen over testtyper for din kunnskap og følge / bruke dem hvis du finner det nødvendig. Gjennom år har jeg forstått at uansett om du bruker noe eller ikke, du tror på noe eller ikke, så skal du fortsatt ha kunnskap om begreper som er mye brukt i ditt felt.

Det er alt for denne delen. Takk for at du leser. Del dine synspunkter / tilbakemeldinger i kommentarer.

I neste og siste del av dette veiledning for manuell testing , Jeg vil prøve å hjelpe dere alle med hvilket forberedelse du bør gjøre hvis du ønsker å komme inn i testfeltet og hva som er mulige måter å komme inn der.

Anbefalt lesing

^