Wat we over het hoofd zien bij het ontwikkelen van onze end-to-end teststrategie
An INFJ personality wielding brevity in speech and writing.
Het spreekt voor zich dat het documenteren van een netjes gearticuleerde teststrategie helpt bij het waarborgen van de softwarekwaliteit. Er zijn zoveel blogs over dit onderwerp en er zijn kernprincipes die moeten worden gevolgd bij het benaderen van een teststrategie.
Een teststrategie zou doorgaans het volgende moeten hebben:
- Doelstellingen/bereik testen
- Duidelijk overzicht van het project
- Risico’s verbonden aan het project
- Middelen testen
- Test schema
Het zou ook moeten helpen gebieden te identificeren waar aanvullende tests nodig kunnen zijn. Het schrijven van een effectieve teststrategie is wat vaardigheidstesters opdoen met ervaring. Daarom is de kans op het missen van een testactiviteit erg klein wanneer een goede teststrategie is gedefinieerd.
End-end teststrategie
End-End Test Strategy legt de testdekking voor de gehele applicatie vast en zorgt ervoor dat de gegevensstroom in stand wordt gehouden voor allerlei acties van eindgebruikers.
Testers moeten er altijd voor zorgen dat de End-End Test Strategie alles omvat wat een klant nodig heeft en soms zelfs een stap verder kan gaan dan nodig is om hen een bevredigend product te bieden.
Dit artikel geeft een overzicht van wat er in een teststrategie moet worden opgenomen, wat we over het hoofd zien bij het opstellen van een teststrategie en hoe u er een kunt maken die werkt voor uw project.
Formuleren van een E2E teststrategie
Een afbeelding die de componenten van de teststrategie weergeeft
#Testbereik en overzicht
Dit moet de belangrijkste reikwijdte van het project bevatten en de overzichtsinformatie over wie toegang zal krijgen tot dit document, en het bevat de details zoals: wie deze documenten zal beoordelen en goedkeuren.
Mensen die de teststrategie meestal beoordelen:
- Test teamleider
- Ontwikkelingsmanager
- Manager Kwaliteitsanalist
- Productmanager
#Testbenadering
Het volgende onderdeel in de teststrategie gaat over de testaanpak. Het volgende kan u misschien op weg helpen.
- Proces testen
- Rol en verantwoordelijkheid binnen het QA-team
- Wijzigingsbeheer processen
- Soorten testen die aan de klant kunnen worden gepresenteerd
- Test technieken
- Mechanismen voor het afhandelen van defecten
- Afmelding testen
#Testomgevingen
De testomgeving specificeert – omgevingen waarin testtypes zullen plaatsvinden en ook configuraties.
Het moet instructies bevatten voor het maken van testgegevens en het gegevensherstelproces. Een zwakke teststrategie met onvolledige informatie kan resulteren in definitieve implementaties die geplaagd worden door defecten en fouten.
#Testtools
Een essentieel onderdeel van een teststrategiedocument omdat het de informatie bevat over de testautomatisering en beheertools om de testuitvoering uit te voeren.
Bepaalt de verhouding tussen open-source en commerciële tools om niet-functionele parameters zoals beveiliging, prestaties, bruikbaarheid en het aantal gebruikers dat ondersteuning biedt te verzekeren.
#Testuitgaven
Dit deel van de teststrategie definieert het releasebeheerplan en de versiegeschiedenis om ervoor te zorgen dat alle wijzigingen die in die release zijn aangebracht, worden opgenomen.
Dit leent zich voor het bouwen van een beheerproces om te bepalen waar de nieuwe build beschikbaar moet zijn wanneer deze wordt opgeleverd, wie deze gaat inzetten, hoe de release kan worden stopgezet in geval van fouten, enzovoort.
#Resourceplanning
Zoals de naam al aangeeft, bepaalt het hoeveel resources betrokken zullen zijn bij het testproces en hun verantwoordelijkheden voor de taak die aan hen is toegewezen.
#Risico analyse
Risicoanalyse – om de mogelijke risico’s in te schatten die kunnen optreden tijdens de testuitvoering en een duidelijk plan om het risico te beperken en een noodplan wanneer risico’s zich in realtime voordoen.
#Beoordelingen en goedkeuringen
Dit is het laatste stukje informatie in het teststrategiedocument waarin het projectmanagement- en ontwikkelingsteam al deze activiteiten beoordeelt en aftekent.
Aan het begin van het document moet een samenvatting van de herzieningswijzigingen worden getraceerd, samen met een goedgekeurde datum, naam en opmerking.
Het volgende gedeelte leidt u door een andere discussie over teststrategie door Harini Mohan, onze testleider.
Wat zien testers over het hoofd bij het opstellen van een teststrategie?
Testschatting en testplanning brengen veel afhankelijkheden met zich mee die kunnen leiden tot variantie in testschatting.
Bij het opstellen van een teststrategie moeten managers en testers zich bewust zijn van de uitdagingen op het gebied van coördinatie en miscommunicatie en een geschikte strategie voor een project plannen.
Onze Senior test engineer, Harini Mohan, deelt een aantal factoren die testmanagers over het hoofd zien bij het opstellen van een teststrategie.
Veranderende eisen
Een applicatie met veranderende eisen zorgt voor onnauwkeurige testschattingen. Het is absoluut noodzakelijk om een goed verandermanagementproces te hebben om de vereisten bij te houden om bedrijfsrisico’s te minimaliseren.
Een screenshot dat de verandermanagementpraktijken van onze klant benadrukt:
| OBSERVATIE | IMPACT NIVEAU | OPMERKINGEN |
|---|---|---|
| Geen formele change management board | Hoog | Leden van de CAB beoordelen wijzigingsverzoeken. De CAB-leden doen aanbevelingen die zijn gebaseerd op de impact op bestaande diensten, de kosten van de wijziging en andere relevante factoren. De CAB-leden moeten zodanig worden gekozen dat zakelijke en technische functies adequaat vertegenwoordigd zijn. |
| Prioritering | Hoog | Een formele benadering van prioritering moet worden opgeschreven op basis van criteria zoals ROI, verhoogde omzet, verbeterde winstgevendheid, implementatiekosten, verbeterde klantenservice, toegenomen concurrentie en middelen die nodig zijn om te implementeren. |
| Geen formele goedkeuringsprocessen | Hoog | Er is een formeel goedkeuringsproces nodig om bedrijfsrisico’s te minimaliseren en om de algehele implementatiestappen voor wijzigingen die als onderdeel van de release zijn gevolgd, te beoordelen. Auditing van veranderingsstappen, zoals code review, end-to-end testen, sign-offs, etc., is belangrijk voordat de wijziging naar klanten kan worden gepusht. |
Geen testgegevens/verkeerde testgegevens
Testgegevens zijn de eerste vereiste waarmee rekening moet worden gehouden voordat met de uitvoering van de test wordt begonnen. Sommige projecten beschikken niet over de juiste testgegevens, wat resulteert in chaos bij het testen.
Daarom moeten testers continu de meest efficiënte benaderingen voor gegevensverzameling, generatie, onderhoud, automatisering en uitgebreid gegevensbeheer verkennen, leren en toepassen voor elk functioneel en niet-functioneel testtype.
Projectcommunicatie/coördinatie
Sommige projectmanagers vergeten tijd vrij te maken voor samenwerking in hun teststrategie, wat, vooral in een offshore/onsite-model, ertoe zou leiden dat er meer tijd aan het project wordt besteed dan gepland.
Onduidelijkheid in planning
Gebrek aan of onduidelijkheid tijdens de planningsfase leidt tot een mislukking vooraf. Als er in de planningsfase niet voldoende zorg wordt besteed, bestaat de mogelijkheid dat er een inefficiënte teststrategie ontstaat, waardoor veel tijd en moeite op de verkeerde plaatsen wordt geïnvesteerd en risicovolle gebieden worden overgeslagen.
Teststrategie in agile
In een agile wereld waar testers in sprints van twee weken aan meerdere projecten/user stories werken, is het normaal om na te denken of we een teststrategie nodig hebben voor zulke korte sprints. Als we voor elk project een teststrategiedocument maken, zou er veel tijd worden besteed aan het herhalen van de documentatie.
Daarom hebben we enkele vragen van testgemeenschappen over dit onderwerp geïdentificeerd en geprobeerd deze te beantwoorden.
Disclaimer: jij doet jezelf en wat het beste is voor je team
Is een “per project” teststrategiedocument de juiste aanpak in een agile omgeving?
In de Waterfall-omgeving moet u bekend zijn met alle zware documentatie die bij het testproces hoort. U kent het formaat en de inhoud van die documenten en zoals we weten is het een enorm tijdrovende klus om al die documenten te ontwikkelen.
Maar de strategie die u samenstelt, beschrijft uw testbenaderingen, uw testrapportagemethoden, uw strategie voor het beheren van omgevingen, uw strategie voor het rapporteren van bugs, belangrijke belanghebbenden en besluitvormers, enz.
Een lean-teststrategie zou echter moeten werken voor zowel waterval- als agile-modellen. Het document kan voor het hele project zijn in plaats van sprints in het agile model. Alleen dan heeft het zin voor de teamleiders of managers om voldoende informatie te hebben, plannen te maken voor testontwerpen, etc.
Zou een globaal teststrategiedocument de juiste benadering zijn die meer een statisch, bedrijfsbreed teststrategiedocument is, dat meer als governance fungeert, in plaats van dit voor elk project te doen?
Het idee van een globaal document moet worden herzien, aangezien de teams op elk moment moeten kunnen beslissen wat geschikt is voor hun project.
Is een teststrategiedocument überhaupt wel nodig?
Natuurlijk! Elk project moet een teststrategie hebben, omdat dit helpt bij het opzetten van het testkader voor elk project.
