Menu

Praktische software testen QA-processtroom (vereisten voor vrijgave)

practical software testing qa process flow

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Een compleet overzicht van de end-to-end QA Software Testing Process Flow:

Opmerking - We publiceren dit nuttige bericht opnieuw met bijgewerkte inhoud.

Het werk van een professionele software-tester is niet gemakkelijk. Het is gevuld met uitdagingen, die ook even veeleisend zijn. Testers worden verondersteld alert en enthousiast te zijn in elke fase van de applicatielevenscyclus.

Hoewel er uitdagingen zijn, zijn er ook verschillende geweldige kansen om de verschillende aspecten van testmethodologieën, processen en natuurlijk de software in detail te leren en te verkennen.

De rol van testingenieur begint al heel vroeg. En vanaf de conceptvorming van het project zijn testers betrokken bij gesprekken met de product owner, projectmanager en verschillende stakeholders.

Vereisten om vrij te geven

Deze tutorial over 'Software Testing Process flow' geeft u een compleet overzicht van de verschillende fasen in STLC, samen met de betrokken uitdagingen en de best practices om die uitdagingen op een gemakkelijk te begrijpen manier te overwinnen.

Wat je leert:

Vereiste om vrij te geven - een compleet overzicht

Levenscyclus van software testen

Van vereiste tot vrijgave wordt elke fase duidelijk uitgelegd. Laten we ze eens in detail bekijken.

# 1) Vereiste

Een project kan niet van de grond komen zonder een duidelijke eis. Dit is de meest cruciale fase waarin ideeën moeten worden geschreven in een goed begrijpelijk en opgemaakt document. Als u deel uitmaakt van het project waar u deelneemt aan de fase van het verzamelen van vereisten, beschouw uzelf dan als een geluksvogel.

testcases in softwaretestvoorbeelden

Afvragen waarom? Het is omdat je getuige bent van een project dat helemaal opnieuw wordt gemaakt. Hoewel er vanaf het begin trots op is, brengt het ook enkele verantwoordelijkheden en uitdagingen met zich mee.

Uitdagingen

Je kunt je niet alle vereisten voorstellen om in één keer samen te komen. Wees geduldig genoeg.

Er zullen veel discussies plaatsvinden, waarvan sommige eenvoudigweg niet relevant zijn voor uw project, maar zelfs dan kunnen ze essentiële informatie voor uw project bevatten. Soms overtreft de snelheid van de discussies uw begripsvermogen of besteedt u eenvoudigweg geen aandacht aan de producteigenaar.

De onderstaande afbeelding laat de cruciale stappen zien die nodig zijn bij het verzamelen van vereisten:

Vereisten LifeCycle

Elk stukje informatie dat wordt gemist, heeft een enorme impact op het algemene begrip en testen van het project. Om dit te verhelpen, volgen hier enkele best practices die tijdens deze fase moeten worden gevolgd.

Beste praktijken

  • Houd je geest open en let op elk woord van de producteigenaar.
  • Luister niet alleen, maar neem de twijfel weg, hoe klein die ook lijkt.
  • Gebruik altijd notitieboekjes om snel notities bij te houden. Je moet een laptop gebruiken, alleen als je echt met een redelijke snelheid kunt typen.
  • Herhaal de zinnen en laat ze verduidelijken vanuit de PO waarvan u denkt dat deze is wat u begreep.
  • Teken blokdiagrammen, linkteksten, enz. Om de vereisten op een later tijdstip duidelijker te maken.
  • Als de teams zich op verschillende locaties bevinden, probeer dan een WebEx- of vergelijkbare opname te maken. Het zal altijd helpen als je twijfelt nadat de discussies voorbij zijn.

Hoewel er niet voor elke fase een aparte wand is, veranderen de eisen zelfs pas laat in de ontwikkeling. Het idee is dus om de meeste vereisten te pakken en dit goed te documenteren.

Zodra het is gedocumenteerd met alle noodzakelijke punten, verspreid en bespreek je alle belanghebbenden, zodat eventuele suggesties of wijzigingen vroegtijdig worden opgemerkt en voordat verder wordt gegaan, zit iedereen op dezelfde pagina.

# 2) Teststrategie

Testers worden verondersteld met een teststrategie te komen die niet alleen voldoende is om de software beter te testen, maar die ook bij elke belanghebbende vertrouwen moet wekken over de kwaliteit van het product.

Teststrategie

Uitdagingen

Het meest cruciale aspect van deze fase is het creëren van een strategie die, wanneer eraan wordt gewerkt, een softwareproduct moet opleveren dat foutloos en duurzaam is en wordt geaccepteerd door de eindgebruikers.

Teststrategieën zijn iets dat u niet om de dag zult veranderen. In sommige gevallen moet u uw teststrategieën ook met de klanten bespreken. Dit deel moet dus met veel belang worden behandeld.

Beste praktijken

  • Hier zijn enkele van de best practices die, wanneer ze worden gevolgd, u grote verlichting kunnen bieden en kunnen resulteren in vlotte tests.
  • Doorloop het behoeftedocument nogmaals. Markeer de importpunten met betrekking tot de omgeving van de doelsoftware.
  • Maak een lijst van omgevingen waar de software daadwerkelijk wordt ingezet.
  • Omgevingen kunnen worden opgevat als een soort besturingssystemen of mobiele apparaten.
  • Als Windows het besturingssysteem is, vermeld dan alle versies van het venster waarin u uw software gaat testen. Als de versies namelijk. Windows 7, Windows 10 of Windows Server (s) zijn nog niet gedefinieerd in het vereiste document, dan is het de hoogste tijd dat deze besproken moeten worden.
  • Op dezelfde manier, verkrijg de doelbrowsers met de versies die zijn besproken en gedocumenteerd als de AUT een webgebaseerd systeem is.
  • Maak een lijst van alle software van derden die de applicatie nodig heeft (indien vereist / ondersteund). Dit kunnen Adobe Acrobat, Microsoft Office, eventuele add-ons, enz. Zijn.

Hier is het idee erachter om alle noodzakelijke en vereiste platforms, apparaten en software die onze applicatie nodig heeft, voor ons te houden, zodat een alomvattende strategie kan worden geformuleerd.

Onderstaande afbeelding zal u helpen de contouren van de teststrategie te begrijpen als u aan een agile project werkt:

Strategie testen

# 3) Testplanning

Nadat de testers gewapend zijn met alle informatie over AUT, is de planningsfase waar de Strategie wordt geïmplementeerd.

Net als een teststrategie is ook testplanning een cruciale fase.

Testplan

Uitdagingen

Aangezien het succes (of falen) van de AUT grotendeels afhangt van hoe de tests zijn uitgevoerd, wordt deze fase een belangrijk aspect van de gehele testlevenscyclus. Waarom? Omdat in deze fase een deel van het testen wordt gedefinieerd.

Om een ​​aantal uitdagingen te overwinnen, kunnen deze best practices echt nuttig zijn.

Beste praktijken

  • Houd er altijd rekening mee dat u geen middel onbeproefd laat als het gaat om het testen van uw applicatie.
  • Het is tijd om een ​​teststrategie te formuleren.
  • Maak een matrix van de omgeving zodat de software op alle platformen wordt getest.
  • Zoals Windows 10 + Internet Explorer 11+ Windows Office 2010+.
  • Zoals Android 4.2.2+ Chrome-browser.
  • Als uw applicatie met meerdere databases werkt (indien gedocumenteerd), bewaar de databases (MySQL, Oracle, SQLServer) dan zo in de testmatrix dat ze bij sommige tests teveel geïntegreerd zijn.
  • Configureer de testmachines dienovereenkomstig en noem ze SetUp1, SetUp2, etc.
  • SetUp1 heeft Windows 7+ IE 10+ Office 2007+.
  • SetUp2 heeft mogelijk Windows 10+ IE Edge + Office 2013+.
  • SetUp3 heeft mogelijk een Android-telefoon waarop uw .apk-bestand is geïnstalleerd.
  • Gefeliciteerd! Je testopstelling is klaar en je hebt ook elke mogelijke combinatie van platforms toegevoegd waarop je applicatie zal werken.

# 4) Testen

Bugs vinden

Eindelijk is de build van uw applicatie uit en bent u klaar om bugs te vinden! Nu is het tijd om aan de testplanning te werken en zoveel mogelijk bugs op te sporen. Als u in een agile omgeving werkt, zullen er enkele fasen tussen zitten, volg dan gewoon die scrum-methoden.

Onderstaand diagram toont de categorisering van verschillende testtypen:

Soorten testen

Uitdagingen

Testen is een omslachtig proces dat op zichzelf foutgevoelig is! Bij het testen van een applicatie kom je veel uitdagingen tegen. Hieronder vindt u enkele best practices om te redden.

Beste praktijken

Kop op! U probeert defecten in de code te vinden. U moet aandacht besteden aan de algehele werking van de software.

  • Het is altijd aan te raden om met een frisse blik naar de applicatie te kijken, ZONDER TESTCASES te doorlopen.
  • Volg het navigatiepad van uw software (AUT).
  • Raak vertrouwd met de AUT.
  • Lees nu de testgevallen (alle) van een bepaalde module (misschien naar keuze).
  • Ga nu naar de AUT en vergelijk de bevindingen met die genoemd in het verwachte deel van de testgevallen.
  • Het idee hierachter is om elke genoemde functie op elk ondersteund platform te testen.
  • Noteer elke afwijking, hoe triviaal deze ook lijkt.
  • Schrijf de stappen op van hoe u een afwijking bereikt, maak schermafbeeldingen, maak foutenlogboeken, serverlogboeken en andere ondersteunende documentatie die het bestaan ​​van defecten kan aantonen.
  • Aarzel niet om te vragen. Hoewel u het vereiste document heeft, zullen er momenten zijn waarop u twijfelt.
  • Neem bij twijfel contact op met de ontwikkelaars (als ze naast je zitten of als ze bereikbaar zijn) voordat je contact opneemt met de Product Owner. Begrijp het perspectief van de ontwikkelaar op de werking van de software. Ze begrijpen. Vindt u dat deze implementatie niet voldoet aan de eisen, informeer dan de testmanager.

# 5) Voor vrijgave

Voordat we een product op de markt brengen, moet de kwaliteit van het product worden gegarandeerd. Software wordt één keer ontwikkeld, maar wordt daadwerkelijk getest totdat ze worden vervangen of verwijderd.

Uitdagingen

De software moet rigoureus worden getest op veel van zijn parameters.

De parameters zijn mogelijk niet beperkt tot:

  • Functionaliteit / gedrag.
  • Prestatie.
  • Schaalbaarheid.
  • Compatibel met de genoemde platforms.

De uitdaging is ook om het succespercentage van een applicatie te voorspellen, die afhangt van vele iteraties van de uitgevoerde tests.

Beste praktijken

  • Zorg ervoor dat alle functies op alle platforms worden getest.
  • Markeer de gebieden die niet zijn getest of die meer testinspanningen vereisen.
  • Bewaar een matrix van alle testresultaten voordat u deze vrijgeeft. De testmatrix geeft een totaalbeeld van de stabiliteit van het product. Het helpt het management ook om op de releasedata te bellen.
  • Geef uw input / suggesties aan het team over uw ervaringen tijdens het testen van het product.
  • Uw inbreng waarbij u uzelf als de eindgebruiker beschouwt, komt de software in grote mate ten goede.
  • Vanwege tijdgebrek of een andere dergelijke situatie missen we ofwel enkele tests of gaan we hier niet diep op in. Aarzel niet om de teststatus aan uw manager te vertellen.
  • Presenteer de aanvraaggezondheidskaart aan de belanghebbenden. Gezondheidskaarten moeten een aantal van alle geregistreerde, open, gesloten, intermitterende defecten bevatten met hun ernst en prioriteit.
  • Stel een vrijgavedocument op en deel dit met het team.
  • Werk aan het voorbereidingsdocument.
  • Verbeter de gebieden die zijn voorgesteld door het management / team.

De onderstaande afbeelding toont de levenscycluskaart van de softwareversie:

Voor vrijgave

# 6) Laat los

Eindelijk komt de tijd dat we het product aan de beoogde gebruikers moeten leveren. We hebben allemaal als team hard gewerkt om het product te ondertekenen en de software zijn gebruikers te laten helpen.

Uitdagingen

Softwaretestingenieurs zijn primair verantwoordelijk voor de release van software. Deze activiteit vereist een procesgeoriënteerde workflow. Hier zijn enkele van de best practices die bij deze fase betrokken zijn.

Beste praktijken

  • Onthoud altijd dat u niet aan het vrijgavedocument werkt op de datum van WERKELIJKE RELEASE.
  • Plan de release-activiteit altijd vóór de daadwerkelijke releasedatum.
  • Standaardiseer het document volgens het bedrijfsbeleid.
  • Uw release-document moet proberen om positieve verwachtingen van de software te wekken.
  • Vermeld alle software- en hardwarevereisten die specifiek zijn voor hun versies duidelijk in het document.
  • Voeg alle openstaande defecten en hun ernst toe.
  • Verberg geen grote getroffen gebieden als gevolg van open defecten. Geef ze een plaats in het Release document.
  • Laat het document nakijken en digitaal ondertekenen (kan verschillen volgens het bedrijfsbeleid).
  • Wees zelfverzekerd en verzend het vrijgavedocument samen met de software.

QA-testproces voor een echt project - Watervalmethode

Ik heb een interessante vraag van een lezer, Hoe worden testen uitgevoerd in een bedrijf, dus in een praktijkomgeving?

Degenen die net zijn afgestudeerd en op zoek gaan naar banen, hebben deze nieuwsgierigheid: hoe zou de werkelijke werkomgeving in een bedrijf zijn?

Hier heb ik me gefocust op het eigenlijke werkproces van Software testen in de bedrijven ​

Werkelijk testproces in bedrijven

Elke keer dat we een nieuw project krijgen, is er een eerste kennismakingsgesprek. In dit gesprek bespreken we in principe wie de klant is? wat is de duur van het project en wanneer wordt het opgeleverd? Wie zijn er allemaal bij het project betrokken, d.w.z. manager, technische leads, QA-leads, ontwikkelaars, testers, enz.?

Vanuit het SRS (softwarevereiste specificatie) projectplan wordt ontwikkeld. De verantwoordelijkheid van testers is om vanuit dit SRS en projectplan een softwaretestplan te maken. Ontwikkelaars beginnen met coderen vanaf het ontwerp. Het projectwerk is opgedeeld in verschillende modules en deze projectmodules worden verdeeld onder de ontwikkelaars.

In de tussentijd is het de verantwoordelijkheid van een tester om een ​​testscenario te maken en testcases te schrijven volgens de toegewezen modules. We proberen bijna alle functionele testgevallen van SRS te dekken. De gegevens kunnen handmatig worden bijgehouden in sommige Excel-testcase-sjablonen of bug-trackingtools.

Wanneer ontwikkelaars de afzonderlijke modules hebben voltooid, worden die modules toegewezen aan de testers. Op deze modules worden rooktesten uitgevoerd en als ze niet slagen voor deze test, worden modules opnieuw toegewezen aan de respectievelijke ontwikkelaars voor een oplossing.

Voor geslaagde modules wordt handmatig getoetst vanuit de schriftelijke testcases. Als er een bug wordt gevonden die wordt toegewezen aan de moduleontwikkelaar en wordt ingelogd in het bug tracking tool ​Bij een bugfix voert een tester bugverificatie en regressietests uit van alle gerelateerde modules. Als de bug de verificatie doorstaat, wordt deze gemarkeerd als geverifieerd en gemarkeerd als gesloten. Anders wordt de bovengenoemde bugcyclus herhaald. (Ik zal de levenscyclus van de bug in een andere post behandelen)

Er worden verschillende tests uitgevoerd op individuele modules en integratietests op module-integratie. Deze tests omvatten compatibiliteitstests, d.w.z. het testen van applicaties op verschillende hardware, OS-versies, softwareplatforms, verschillende browsers, enz.

Ook belasting- en stresstests worden uitgevoerd volgens SRS. Ten slotte worden systeemtests uitgevoerd door een virtuele clientomgeving te creëren. Nadat alle testcases zijn uitgevoerd, wordt er een testrapport opgesteld en wordt besloten om het product vrij te geven!

Stappen in vereisten om vrij te geven

Hieronder vindt u de details van elke teststap die wordt uitgevoerd in elke softwarekwaliteit en testlevenscyclus gespecificeerd door IEEE- en ISO-normen.

# 1) SRS recensie ​ Beoordeling van de specificaties van de softwarevereisten.

# 2) Doelstellingen zijn ingesteld voor grote releases.

# 3) Streefdatum gepland voor de releases.

# 4) Gedetailleerd projectplan is gebouwd. Dit omvat de beslissing over ontwerpspecificaties.

# 5) Ontwikkel een testplan is gebaseerd op ontwerpspecificaties.

# 6) Testplan: Dit omvat doelstellingen, de gebruikte methodologie tijdens het testen, functies die wel en niet getest moeten worden, risicocriteria, testschema, ondersteuning voor meerdere platforms en de toewijzing van middelen voor testen.

# 7) Testspecificaties: Dit document bevat technische details (softwarevereisten) die vereist zijn voorafgaand aan het testen.

# 8) Schrijven van testcases

# 9) Ontwikkeling: Modules worden één voor één ontwikkeld.

# 10) Binding voor installateurs: Installateurs zijn opgebouwd rond het individuele product.

de standaardgateway is niet beschikbaar windows 10 ethernet

#elf) Bouwprocedure ​ Een build omvat installateurs van de beschikbare producten - meerdere platforms.

# 12) Testen: Rooktest (BVT): Basistest voor toepassing om een ​​beslissing te nemen over verdere tests.

  • Testen van nieuwe functies
  • Cross-browser en cross-platform testen
  • Stresstests en testen van geheugenlekkage.

# 13) Samenvatting testrapport

# 14) Code bevriezen

  • Er worden op dit moment geen nieuwe functies meer toegevoegd.

# 15) Testen: Build en regressietesten.

# 16) Besluit om het product vrij te geven.

# 17) Scenario na vrijgave voor verdere doelstellingen.

Dit was een samenvatting van een daadwerkelijk testproces in een bedrijfsomgeving.

Gevolgtrekking

Het werk van een softwaretester is vol uitdagingen, maar ook een plezierige. Dit is voor iemand die even gepassioneerd, gemotiveerd en vol enthousiasme is. Het vinden van fouten bij iemand is niet altijd even gemakkelijk! Dit vereist veel vaardigheid en een schot in de roos voor de gebreken.

Naast alle kwaliteiten moet een tester ook procesgericht zijn. Net als alle andere industrieën worden projecten in IT te gefaseerd uitgevoerd, waarbij elke fase een aantal goed gedefinieerde doelen heeft. En elk doel heeft een welomschreven acceptatiecriterium. Een test engineer moet veel softwarekwaliteit op zijn schouders dragen.

Tijdens het werken in elke fase van software, wordt van testers verwacht dat ze de best practices volgen en zich aansluiten bij het proces dat betrokken is bij de respectieve fasen. Het volgen van de best practices en een goed geformuleerd proces helpt niet alleen om het werk van testers te vergemakkelijken, het helpt ook om de kwaliteit van de software te waarborgen.

Heeft u deel uitgemaakt van een van de bovenstaande fasen? Deel gerust hieronder je ervaringen.

Aanbevolen literatuur

^