Wanneer een bug in productie komt, is de oorzaak vaak niet dat iemand vergeten is een test uit te voeren. Het is dat een vereiste nooit in twijfel werd getrokken, dat de testgegevens verkeerd waren of dat niemand het eens was over wat ‘gedaan’ betekende. De levenscyclus voor het testen van software pakt deze problemen aan door het testen een duidelijke structuur te geven, vanaf de eerste vereiste tot aan het eindrapport.

Deze gids legt elke fase uit en volgt vervolgens één illustratief kenmerk door ze allemaal: een inlogpagina die een account vergrendelt na vijf mislukte pogingen. Bronnen zijn het niet helemaal eens over het aantal fasen. Je ziet modellen met zeven of acht, maar meestal verdelen ze hetzelfde werk anders. Wij gebruiken de algemeen onderwezen zesfasenversie.

Wat is de STLC?

De STLC is een gedefinieerde reeks testactiviteiten die worden uitgevoerd om te bevestigen dat software aan de vereisten voldoet. Elke fase heeft een doel, input en output, zodat het testen gepland en traceerbaar is in plaats van aan het eind te improviseren.

De voordelen zijn praktisch. Testers worden er vroeg bij betrokken, wanneer defecten goedkoper te repareren zijn. Inspanning gaat naar de hoogste risico’s. En als een manager vraagt: “Zijn we klaar om vrij te geven?”, Kan het team antwoorden met bewijsmateriaal.

De zes STLC-fasen in één oogopslag

Toegangscriteria zijn de voorwaarden waaraan moet worden voldaan voordat een fase begint. Uitgangscriteria zijn de voorwaarden waaraan moet worden voldaan voordat deze eindigt. Ze weerhouden een team ervan om bijvoorbeeld tests uit te voeren op een kapotte build en daarmee een dag te verspillen.

Fase 1: Behoefteanalyse

Testers bestuderen de eisen om erachter te komen wat er getest kan worden en wat onduidelijk is. Dit is vaak de goedkoopste plek om een ​​bug te voorkomen, omdat een vraag veel minder kost dan een productiefix.

• Invoer: Er zijn vereiste documenten of gebruikersverhalen beschikbaar.
• Activiteiten: functionele en niet-functionele behoeften identificeren, vragen stellen, risico’s inschatten en beslissen wat geautomatiseerd kan worden.
• Afsluiten: open vragen worden beantwoord en de traceerbaarheidsmatrix (RTM) van eisen wordt gestart.
• Deliverables: een lijst met testbare vereisten en de RTM.

Inlogvoorbeeld. Het verhaal zegt: “Vergrendel het account na vijf mislukte pogingen”. Een goede tester vraagt: vijf in welke periode? Hoe wordt het ontgrendeld? Wordt bij een succesvolle aanmelding de telling gereset? Welke melding wordt getoond? Elk antwoord wordt iets toetsbaars.

Fase 2: Testplanning

Het team bepaalt de omvang, aanpak, mensen, middelen, planning en risico’s. Meestal is de testleider eigenaar van deze fase.

• Entry: analyseerde de vereisten en een eerste risicobeoordeling.
• Activiteiten: bepaal de reikwijdte, schat de inspanning, selecteer tools, wijs rollen toe en stel exitcriteria in voor latere fasen.
• Afsluiten: het testplan wordt beoordeeld en goedgekeurd.
• Deliverables: het testplan en de inspanningsschattingen.

Inlogvoorbeeld. In het bereik: uitsluitingsregels, reset- en foutmeldingen op internet en mobiel. Buiten bereik: eenmalige aanmelding, afgehandeld door een ander team. Het grootste risico is het buitensluiten van echte gebruikers, dus dat krijgt de meeste aandacht. Als je niet zeker weet hoe een plan verschilt van een strategie, lees dan Testplan versus teststrategie.

Fase 3: Ontwikkeling van testcases

Hier schrijven testers de gedetailleerde testcases, automatiseringsscripts en testgegevens.

• Toegang: een goedgekeurd testplan en stabiele eisen.
• Activiteiten: testcases schrijven en beoordelen, gegevens voorbereiden, geautomatiseerde controles scripten en de RTM bijwerken.
• Afsluiten: testcases en gegevens zijn beoordeeld en klaar.
• Deliverables: testcases, scripts en testgegevens.

Merk op dat TC-01 en TC-02 beide kanten van de limiet testen, wat rechtstreeks voortkomt uit grenswaardeanalyse. Voor meer informatie over hoe je deze goed schrijft, zie hoe je testcases schrijft.

Fase 4: Inrichting van de testomgeving

Tests moeten ergens realistisch kunnen worden uitgevoerd: de juiste servers, gegevens, accounts, browsers en netwerktoegang. Deze fase loopt vaak parallel met fase 3 en kan worden afgehandeld door ontwikkelaars of een DevOps-team.

• Invoer: een testplan, een architectuuroverzicht en omgevingseisen.
• Activiteiten: hardware of containers instellen, gegevens laden, toegang configureren en de build installeren.
• Afsluiten: de omgeving is gereed en een rooktest is geslaagd.
• Deliverables: een werkomgeving en een rooktestresultaat.

Inlogvoorbeeld. Staging krijgt testaccounts in bekende statussen, samen met een verkorte vergrendelingstimer, zodat testers niet hoeven te wachten. Een snelle rooktest bevestigt dat de login überhaupt wordt geladen voordat de volledige run begint. Containers helpen omgevingen consistent te houden, zoals u kunt zien in onze Docker Compose-tutorial.

Fase 5: Testuitvoering

Testers voeren de geplande tests uit, vergelijken werkelijke en verwachte resultaten en rapporteren defecten. Vaste bugs worden opnieuw getest en gerelateerde gebieden ondergaan regressietests.

• Entry: testcases zijn klaar, de omgeving werkt en er is een build opgeleverd.
• Activiteiten: voer tests uit, registreer resultaten, registreer defecten, test oplossingen opnieuw en update de RTM.
• Afsluiten: geplande tests worden uitgevoerd en defecten worden verholpen of formeel geaccepteerd.
• Deliverables: testresultaten en defectrapporten.

Inlogvoorbeeld. TC-04 mislukt: met twee browsers staat de teller slechts op vier. De tester registreert de bug met duidelijke stappen en bewijsmateriaal, zoals beschreven in hoe u een bugrapport schrijft. Zodra het probleem is verholpen, wordt TC-04 opnieuw uitgevoerd en doorlopen de bijbehorende inlogcontroles de regressiechecklist.

Fase 6: Testafsluiting

Deze fase wordt vaak overgeslagen, wat jammer is, want het is de manier waarop een team verbetert. Het team evalueert de cyclus, archiveert zijn werk en legt vast wat het heeft geleerd.

• Invoer: de uitvoering is voltooid en de defectstatus is bekend.
• Activiteiten: controleer de exitcriteria, analyseer defecttrends, archiveer testmiddelen en houd een retrospectief.
• Afsluiten: het afsluitingsrapport is afgetekend.
• Deliverables: het afsluitingsrapport en de geleerde lessen.

Inlogvoorbeeld. Uit het rapport blijkt dat alle vijf de gevallen na één oplossing zijn afgehandeld. De les is dat gelijktijdigheid pas laat werd getest, dus toekomstige functies met tellers krijgen dat scenario toegevoegd tijdens het ontwerp.

STLC versus SDLC

De SDLC, of levenscyclus van softwareontwikkeling, omvat het bouwen van het hele product. De STLC is het onderdeel gericht op testen en loopt ernaast.

Vereistenanalyse in de SDLC voedt de vereistenanalyse in de STLC, en ontwikkeling levert builds op voor de testuitvoering. Het testen hoeft niet te wachten tot het coderen is afgelopen. Vroeg beginnen is wat mensen bedoelen met ‘naar links verschuiven’.

STLC in Agile en DevOps

De fasen kunnen klinken als een lang eenrichtingsproces, maar dat hoeft niet zo te zijn. In Agile krimpen en herhalen dezelfde activiteiten binnen elke sprint, vaak in uren in plaats van weken:

• Behoefteanalyse gebeurt bij het verfijnen van de achterstand, door middel van vragen over het gebruikersverhaal.
• Planning gebeurt tijdens de sprintplanning, met lichte aantekeningen in plaats van lange documenten.
• Testontwerp gebeurt naast het coderen, vaak als acceptatiecriteria en geautomatiseerde tests.
• Het instellen van de omgeving wordt geautomatiseerd via containers en infrastructuur als code.
• Uitvoering wordt continu uitgevoerd in een CI/CD-pijplijn.
• Afsluiting wordt onderdeel van de sprintrecensie en retrospective.

Bewaar wat nuttig is en pas het papierwerk aan het risico aan. Voor een klein intern instrument is wellicht een korte checklist nodig, terwijl voor een banksysteem om regelgevingsredenen wellicht formele goedkeuringen nodig zijn.

Veel voorkomende fouten

• Testers te laat binnenbrengen. Bugs die in de vereisten worden aangetroffen, zijn veel goedkoper dan bugs die na de release worden gevonden.
• Vage exitcriteria. Zonder deze criteria bepalen deadlines voor jou de beslissing.
• Testen in een slechte omgeving. Fouten veroorzaakt door slechte gegevens of configuratie verspillen tijd en ondermijnen het vertrouwen.
• Afsluiting overslaan. Het team herhaalt dezelfde fouten in de volgende cyclus.
• Het te strikt volgen. De STLC is een leidraad. Zware documenten betekenen niet automatisch een betere kwaliteit.

Tot slot

De levenscyclus van het testen van software is simpelweg een gedisciplineerd antwoord op zes vragen: wat testen we, hoe, met welke cases, waar, wat is er gebeurd en wat hebben we geleerd? Kijk naar uw volgende functie en kijk welke van deze vragen uw team gewoonlijk overslaat. Als u dat ene gat oplost, krijgt u waarschijnlijk de grootste winst.

Veelgestelde vragen

Blijf leren