Menu

Praktisk softwaretestning af QA-procesflow (krav til frigivelse)

practical software testing qa process flow

Prøv Vores Instrument Til At Fjerne Problemer

En komplet oversigt over end-til-ende QA-softwaretestprocesflow:

Bemærk - Vi udgiver igen dette nyttige indlæg med opdateret indhold.

Jobbet som professionel softwaretest er ikke let. Den er fyldt med udfordringer, hvilket også er lige så krævende. Testere formodes at være opmærksomme og entusiastiske i hver eneste fase af applikationens livscyklus.

Selvom der er udfordringer, er der også flere enorme muligheder for at lære og udforske de forskellige aspekter af testmetoder, processer og selvfølgelig softwaren i detaljer.

Testingeniørens rolle begynder meget tidligt. Og lige fra konceptualiseringen af ​​projektet er testere involveret i diskussioner med produktejeren, projektlederen og forskellige interessenter.

Krav til frigivelse

Denne tutorial om 'Software Testing Process flow' giver dig et komplet overblik over de forskellige faser i STLC sammen med de involverede udfordringer og de bedste fremgangsmåder til at overvinde disse udfordringer på en let forståelig måde.

Hvad du lærer:

Krav til frigivelse - En komplet oversigt

Software Test af livscyklus

Lige fra krav til frigivelse forklares hver fase tydeligt. Lad os se nærmere på dem.

# 1) Krav

Et projekt kan ikke starte uden at have et klart krav. Dette er den mest afgørende fase, hvor ideer skal skrives i et godt forståeligt og formateret dokument. Hvis du er en del af projektet, hvor du deltager i kravindsamlingsfasen, så betragt dig selv heldig.

devops interviewspørgsmål og svar til erfarne

Gad vide hvorfor? Det er fordi du er vidne til et projekt, der laver fra bunden. Selvom der er stolthed at være siden starten, kommer det også med nogle ansvar og udfordringer.

Udfordringer

Man kan ikke forestille sig alle kravene til at samles i et enkelt møde. Vær tålmodig nok.

Mange diskussioner vil ske, hvoraf nogle måske simpelthen er irrelevante for dit projekt, men selv da kan de indeholde nogle vigtige oplysninger til dit projekt. Nogle gange kan diskussionshastigheden overstige dine forståelsesfunktioner, ellers vil du simpelthen ikke være opmærksom på produktejeren.

Nedenstående billede fremhæver de afgørende trin, der er involveret i kravindsamling:

Krav Livscyklus

Hvert stykke information, der går glip af, har en enorm indflydelse på den samlede forståelse og testning af projektet. For at overvinde dette er her nogle bedste fremgangsmåder, der skal følges i denne fase.

Bedste praksis

  • Hold dit sind åbent og vær opmærksom på hvert ord fra produktejeren.
  • Lyt ikke bare, ryd din tvivl, uanset hvor lille den ser ud til at være.
  • Brug altid notesbøger til hurtig notatopbevaring. Du skal kun bruge en bærbar computer, hvis du virkelig kan skrive med en rimelig hastighed.
  • Gentag sætningerne, og få dem afklaret fra PO, som du synes er det, du forstod.
  • Tegn blokdiagrammer, linktekst osv. For at gøre kravene mere klare på et senere tidspunkt.
  • Hvis holdene er forskellige steder, skal du prøve at gøre det til en WebEx eller lignende optagelse. Det vil altid hjælpe, når du er i tvivl, når diskussionerne er slut.

Selvom der ikke er nogen separat væg som sådan for hver eneste fase, ændres kravene endda meget sent i udviklingen. Så ideen er at få fat i det meste af kravet og dokumentere dette korrekt.

Når det er blevet dokumenteret med alle de nødvendige punkter, skal du distribuere og diskutere alle interessenter, så eventuelle forslag eller ændringer bliver fanget tidligt, og før alle går videre, er alle på samme side.

# 2) Teststrategi

Testere formodes at komme med en teststrategi, der ikke bare er tilstrækkelig til at teste softwaren bedre, men også bør indgyde tillid til enhver interessent med hensyn til produktets kvalitet.

Teststrategi

Udfordringer

Det mest afgørende aspekt af denne fase er at skabe en strategi, der, når der arbejdes på, skal levere et softwareprodukt, der er fejlfrit, bæredygtigt og accepteret af slutbrugerne.

Teststrategier er noget, du ikke vil ændre hver anden dag. I nogle tilfælde skal du også diskutere dine teststrategier med kunderne. Så denne del skal behandles med stor betydning.

Bedste praksis

  • Her er nogle af de bedste fremgangsmåder, som når de følges, kan give dig stor lettelse og resultere i glat test.
  • Gå igen gennem kravdokumentet. Fremhæv importpunkterne i forhold til målsoftwaren.
  • Lav en liste over miljøer, hvor softwaren faktisk bliver implementeret.
  • Miljøer kan forstås som en type operativsystemer eller mobile enheder.
  • Hvis Windows er operativsystemet, skal du liste alle versioner af det vindue, hvor du vil teste din software. Hvis versionerne, dvs. Windows 7, Windows 10 eller Windows Server (er) er stadig ikke defineret i kravdokumentet, så det er på høje tid, når disse skal diskuteres.
  • På en lignende note, få målbrowsere med de versioner, der er diskuteret og dokumenteret, hvis AUT er et webbaseret system.
  • Lav en liste over alle de tredjepartssoftware, som applikationen har brug for (hvis nødvendigt / understøttet). Disse kan omfatte Adobe Acrobat, Microsoft Office, eventuelle tilføjelser osv.

Her er ideen bag at beholde enhver nødvendig og krævet platform, enheder og software, som vores applikation skal fungere foran os, så en omfattende strategi kan formuleres.

Nedenstående figur hjælper dig med at forstå oversigten over teststrategi, hvis du arbejder på et smidigt projekt:

Teststrategi

# 3) Testplanlægning

Når testerne er bevæbnet med al information om AUT, er planlægningsfasen, hvor strategien implementeres.

Ligesom en teststrategi er testplanlægning også en afgørende fase.

Testplan

Udfordringer

Da AUT's succes (eller fiasko) i høj grad afhænger af, hvordan testene blev udført, bliver denne fase et vigtigt aspekt af hele testets livscyklus. Hvorfor? Fordi en del af testen er defineret i denne fase.

For at overvinde nogle udfordringer kan disse bedste fremgangsmåder virkelig være nyttige.

Bedste praksis

  • Husk altid at ikke lade nogen sten være upåvirket, når det kommer til at teste din ansøgning.
  • Det er tid til at formulere en teststrategi.
  • Opret en matrix af miljøet, så softwaren testes på alle platforme.
  • Ligesom Windows 10 + Internet Explorer 11+ Windows Office 2010+.
  • Ligesom Android 4.2.2+ Chrome-browseren.
  • Hvis din applikation fungerer med flere databaser (hvis dokumenteret), skal du opbevare databaserne (MySQL, Oracle, SQLServer) i testmatrixen på en sådan måde, at de er for integrerede med nogle tests.
  • Konfigurer testmaskiner i overensstemmelse hermed og navngiv dem som SetUp1, SetUp2 osv.
  • SetUp1 har Windows 7+ IE 10+ Office 2007+.
  • SetUp2 kan have Windows 10+ IE Edge + Office 2013+.
  • SetUp3 har muligvis en Android-telefon med din .apk-fil installeret.
  • Tillykke! Din testopsætning er klar, og du har også inkluderet alle mulige kombinationer af platforme, som din applikation vil arbejde på.

# 4) Test

Finde bugs

Endelig er din applikationsopbygning ude, og du er klar til at finde fejl! Nu er det tid til at arbejde på testplanlægning og finde så mange fejl som muligt. Der vil være nogle faser imellem, hvis du arbejder i et smidigt miljø, så følg blot disse scrummetoder.

Nedenstående diagram viser kategoriseringen af ​​forskellige testtyper:

Typer af test

Udfordringer

Test er en besværlig proces, som i sig selv er udsat for fejl! Man finder mange udfordringer, når man tester en applikation. Nedenfor er nogle af de bedste fremgangsmåder til redning.

Bedste praksis

Op med humøret! Du prøver at finde fejl i koden. Du skal være opmærksom på den samlede funktion af softwaren.

  • Det er altid tilrådeligt at se på applikationen med et nyt look, UDEN AT GÅ TIL TESTSAGER.
  • Følg navigationsstien til din software (AUT).
  • Bliv fortrolig med AUT.
  • Læs nu testcases (Alle) for et bestemt modul (måske efter eget valg).
  • Gå nu til AUT, og match resultaterne med dem, der er nævnt i det forventede afsnit af testsagerne.
  • Ideen bag dette er at teste alle nævnte funktioner på enhver understøttet platform.
  • Noter enhver afvigelse, uanset hvor triviel den ser ud til at være.
  • Skriv trinene til, hvordan du når enhver afvigelse, tager skærmbilleder, registrerer fejllogfiler, serverlogfiler og enhver anden understøttende dokumentation, der kan bevise eksistensen af ​​mangler.
  • Tøv ikke med at spørge. Selvom du har kravdokumentet, vil der være tidspunkter, hvor du vil være i tvivl.
  • Nå ud til udviklerne (hvis de sidder ved siden af ​​dig, eller de er tilgængelige) i tvivl, før du når til produktejeren. Forstå udviklerens perspektiv på, hvordan softwaren fungerer. Forstå dem. Hvis du mener, at denne implementering ikke er i overensstemmelse med kravet, skal du informere testlederen.

# 5) Før frigivelse

Før vi frigiver et produkt på markedet, skal produktets kvalitet sikres. Software er udviklet en gang, men de er faktisk testet, indtil de udskiftes eller fjernes.

Udfordringer

Softwaren skal testes nøje for mange af dens parametre.

Parametrene er muligvis ikke begrænset til:

  • Funktionalitet / adfærdsmæssig.
  • Ydeevne.
  • Skalerbarhed.
  • Kompatibel med de nævnte platforme.

Udfordring er også at forudsige succesraten for en applikation, som afhænger af mange iterationer af den udførte test.

Bedste praksis

  • Sørg for, at alle funktionerne på alle platforme er testet.
  • Fremhæv de områder, der ikke er testet, eller det område, der har brug for mere testindsats.
  • Opbevar en matrix med alle testresultaterne inden frigivelse. Testmatrixen giver et samlet billede af produktets stabilitet. Det vil også hjælpe ledelsen med at ringe til udgivelsesdatoerne.
  • Giv dit input / forslag til teamet om dine oplevelser, mens du tester produktet.
  • Dit input, der betragter dig selv som slutbruger, vil gavne softwaren stort set.
  • På grund af tidsnød eller enhver anden sådan situation går vi enten glip af nogle test eller går ikke dybt ind i dette. Tøv ikke med at fortælle teststatus til din manager.
  • Præsenter ansøgningens sundhedskort for interessenterne. Sundhedskort skal have et antal af alle loggede, åbne, lukkede, intermitterende defekter med deres sværhedsgrad og prioritet.
  • Udarbejd et frigivelsesdokument, og del dette på tværs af holdet.
  • Arbejd med frigivet dokument udarbejdet.
  • Forbedre de områder, som ledelsen / teamet foreslår.

Nedenstående billede viser livscykluskortet til softwareudgivelse:

Før frigivelse

# 6) Slip

Endelig kommer det tidspunkt, hvor vi skal levere produktet til dets tiltænkte brugere. Vi har alle som et team arbejdet hårdt for at afmelde produktet og lade softwaren hjælpe sine brugere.

Udfordringer

Software testteknikere er primært ansvarlige for frigivelsen af ​​enhver software. Denne aktivitet kræver en procesorienteret arbejdsgang. Her er nogle af de bedste fremgangsmåder, der er involveret i denne fase.

Bedste praksis

  • Husk altid, at du ikke arbejder på frigivelsesdokumentet på datoen for FAKTISK RELEASE.
  • Planlæg altid frigivelsesaktiviteten inden den faktiske udgivelsesdato.
  • Standardiser dokumentet i henhold til virksomhedens politikker.
  • Dit frigivelsesdokument skal forsøge at skabe positive forventninger fra softwaren.
  • Nævn alle software- og hardwarekrav, der er specifikke for deres versioner, tydeligt i dokumentet.
  • Inkluder alle de åbne mangler og deres sværhedsgrad.
  • Skjul ikke større påvirkede områder på grund af åbne fejl. Giv dem en plads i frigivelsesdokumentet.
  • Få dokumentet gennemgået og digitalt underskrevet (kan variere alt efter virksomhedspolitik).
  • Vær sikker og send frigivelsesdokumentet sammen med softwaren.

QA-testproces på et rigtigt projekt - vandfaldsmetode

Jeg fik et interessant spørgsmål fra en læser, Hvordan udføres test i et firma, dvs. i et praktisk miljø?

De, der bare går ud af college og begynder at søge efter job, har denne nysgerrighed - hvordan ville det faktiske arbejdsmiljø i en virksomhed være?

Her har jeg fokuseret på den egentlige arbejdsproces for Softwaretest i virksomhederne .

Faktisk testproces i virksomheder

Når vi får et nyt projekt, er der et indledende projektkendskabsmøde. I dette møde diskuterer vi grundlæggende, hvem der er klienten? hvad er projektets varighed, og hvornår leveres det? Hvem er alle involveret i projektet, dvs. leder, Tech leads, QA leads, udviklere, testere osv.?

Fra SRS (softwarekravspecifikation) udvikles projektplanen. Testernes ansvar er at oprette en softwaretestplan ud fra denne SRS og projektplanen. Udviklere begynder at kode fra designet. Projektarbejdet er opdelt i forskellige moduler, og disse projektmoduler fordeles mellem udviklerne.

I mellemtiden er det en testers ansvar at oprette et testscenarie og skrive testcases i henhold til de tildelte moduler. Vi forsøger at dække næsten alle funktionelle testsager fra SRS. Dataene kan vedligeholdes manuelt i nogle excel-test case-skabeloner eller bug tracking-værktøjer.

Når udviklere afslutter de enkelte moduler, tildeles disse moduler til testerne. Røgtest udføres på disse moduler, og hvis de fejler denne test, tildeles moduler til de respektive udviklere for at få en løsning.

For beståede moduler udføres manuel test ud fra de skriftlige testcases. Hvis der findes en fejl, der tildeles moduludvikleren og bliver logget ind i bug tracking værktøj . Ved fejlrettelse foretager en tester fejlbekræftelse og regressionstest af alle relaterede moduler. Hvis bug passerer verifikationen, er den markeret som verificeret og markeret som lukket. Ellers gentages ovennævnte bugcyklus. (Jeg vil dække bugens livscyklus i et andet indlæg)

Forskellige tests udføres på individuelle moduler og integrationstest på modulintegration. Disse tests inkluderer test af kompatibilitet, dvs. test af applikationer på forskellige hardware, OS-versioner, softwareplatforme, forskellige browsere osv.

Belastning og stresstest udføres også i henhold til SRS. Endelig udføres systemtest ved at skabe et virtuelt klientmiljø. Når alle testsagerne er udført, udarbejdes en testrapport, og beslutningen tages for at frigive produktet!

Trin i krav til frigivelse

Nedenfor er detaljerne i hvert testtrin, der udføres i hver softwarekvalitet og testlivscyklus, der er specificeret af IEEE og ISO-standarder.

# 1) SRS anmeldelse : Gennemgang af specifikationerne til softwarekrav.

# 2) Mål er indstillet til større udgivelser.

# 3) Måldato planlagt til udgivelserne.

# 4) Detaljeret projektplan er bygget. Dette inkluderer beslutningen om designspecifikationer.

# 5) Udvik testplan er baseret på designspecifikationer.

# 6) Testplan: Dette inkluderer mål, den metode, der er anvendt under testning, funktioner, der skal testes og ikke skal testes, risikokriterier, testplan, support under flere platforme og ressourcetildeling til test.

# 7) Testspecifikationer: Dette dokument indeholder tekniske detaljer (softwarekrav), der kræves inden test.

# 8) Skrivning af testsager

  • Røg ( BVT ) test tilfælde
  • Sanity Test-sager
  • Tilfælde med regressionstest
  • Negative testsager
  • Udvidede testsager

# 9) Udvikling: Moduler udvikles en efter en.

# 10) Binding af installatører: Installatører er bygget op omkring det enkelte produkt.

manuelle testinterviewspørgsmål til 5 års erfaring

#elleve) Bygprocedure : En build inkluderer installatører af de tilgængelige produkter - flere platforme.

# 12) Test: Smoke Test (BVT): Grundlæggende applikationstest for at tage en beslutning om yderligere test.

  • Test af nye funktioner
  • Cross-browser og test på tværs af platforme
  • Stresstest og hukommelses lækage test.

# 13) Testoversigtsrapport

# 14) Kodefrysning

  • Der tilføjes ikke flere nye funktioner på dette tidspunkt.

# 15) Test: Test af opbygning og regression.

# 16) Beslutning om frigivelse af produktet.

# 17) Scenarie efter frigivelse for yderligere mål.

Dette var et resumé af en faktisk testproces i et virksomhedsmiljø.

Konklusion

Jobbet med en softwaretester er fuld af udfordringer, men alligevel en behagelig opgave. Dette er for en person, der er lige så lidenskabelig, motiveret og fuld af entusiasme. At finde fejl hos nogen er ikke altid et let job! Dette kræver en masse færdigheder og et øje med manglerne.

Udover alle kvaliteterne skal en tester også være procesorienteret. Ligesom alle de andre industrier er projekter inden for IT forarbejdede i faser, hvor hver fase har nogle veldefinerede mål. Og hvert mål har et veldefineret acceptkriterium. En testingeniør skal bære mange belastninger med softwarekvalitet på sine skuldre.

Mens de arbejder i enhver fase af software, skal testere følge de bedste fremgangsmåder og skal tilpasse sig processen, der er involveret i de respektive faser. Ved at følge den bedste praksis og den velformulerede proces hjælper det ikke kun med at lette testernes arbejde, det hjælper også med at sikre softwarekvaliteten.

Har du været en del af en af ​​ovenstående faser? Del gerne dine oplevelser nedenfor.

Anbefalet læsning

^