Antwoord.

Het bepalen van de reikwijdte van handtesting (scope) is een fundamentele taak voor handtesting, waarmee de focus kan worden gelegd op de meest actuele en kritische delen van de applicatie.

Geschiedenis van de vraag

Met de ontwikkeling van projecten groeit de hoeveelheid te testen functionaliteiten, handmatige dekking van alle scenario's blijft onmogelijk. Met de opkomst van Agile/incremental ontwikkeling is de rol van het bepalen van de scope aanzienlijk toegenomen.

Probleem

Als de grenzen van de testing wazig zijn, bestaat het risico:

Ineffectieve testing uit te voeren, waardoor middelen worden verspild aan belangrijke functies
Kritieke bugs in belangrijke scenario's te missen
Te overlappen met het werk van andere testers, waardoor duplicatie ontstaat

Oplossing

De scope van de testing moet worden bepaald op basis van:

zakelijke prioriteiten, gebruikersscenario's en risico's
analyse van vereisten, gebruikersverhalen en specificaties
overleg met het team (analisten, productmanagers, ontwikkelaars)

Belangrijke kenmerken:

Focus op de belangrijkste functies en risicogebieden
Duidelijke vastlegging/documentatie van de dekking in het testplan om misverstanden te voorkomen
De mogelijkheid om de scope snel te herzien bij veranderingen in vereisten

Misleidende vragen.

Moet je altijd alles testen wat is gerealiseerd, zelfs de kleinste details?

Nee, het principe van testen is focussen op de prioritaire en kritische delen, vooral daar waar fouten waarschijnlijker zijn en bugs een significant effect op het bedrijf zullen hebben.

Kan de tester zelfstandig de scope uitbreiden of verkleinen wanneer er nieuwe vereisten zijn zonder afstemming?

Nee, alle wijzigingen in de scope moeten worden afgestemd met de productmanager of teamleider om gaten of duplicatie van werk te voorkomen.

Is het voldoende om alleen op technische documentatie te vertrouwen voor het bepalen van de scope?

Nee, je moet ook rekening houden met de zakelijke context, de echte gebruikersbehoeften, en feedback van de klant.

Typische fouten en antipatterns

Scope is niet vastgelegd en verandert constant
Negeert zakelijke prioriteiten ten gunste van secundaire functies
Gebrek aan communicatie tussen teamleden bij het wijzigen van de grenzen van de testing

Voorbeeld uit het leven

Negatieve case

Een tester besluit zelfstandig alle functies en gevallen te dekken, waardoor er uiteindelijk geen tijd overblijft om kritische paden te testen, en de belangrijkste bugs ontsnappen.

Voordelen:

Formeel zijn er veel scenario's getest

Nadelen:

Kritische blokkering bugs blijven onopgemerkt door een verspreide aandacht
Vertragingen door een onterecht groot volume aan testing

Positieve case

Aan het begin van de sprint neemt de tester deel aan de planning, legt de scope vast samen met het hele team, met de nadruk op de belangrijkste gebruikersscenario's, stemt het werkvolume af en documenteert het in Confluence.