Agile werken vereist een nieuwe manier van testen

Nieuwe bedrijfsmodellen vereisen een nieuwe aanpak bij testen en ontwikkelen van software

Digitale transformatie is het nieuwe codewoord bij veel bedrijven. Ze gooien strategieën om, zetten de klant (in plaats van het product) centraal en tillen de klantervaring naar een hoger niveau. Althans, dat is wel de bedoeling. Dat lukt natuurlijk alleen als je jouw technologie en de ontwikkeling van nieuwe software ook fundamenteel verandert.

In het verleden maakten softwareontwikkelaars meestal desktop-gerelateerde apps, nu ontwikkelen ze vooral nieuwe web-based en mobiele apps. De bekende en beproefde Watervalmethode heeft inmiddels plaats gemaakt voor een Agile aanpak van continue ontwikkeling en release. Agile past volledig bij digitale transformatie, het maakt het bedrijf namelijk wendbaar en flexibel. Met een Agile aanpak ben je in staat snel te reageren op veranderingen buiten de onderneming.

Welke invloed heeft deze nieuwe manier van werken op de kwaliteit van onze software? Moeten we aan kwaliteit inboeten nu alles zoveel sneller gaat? En wat is precies de rol van testen in een Agile team? We bespreken het met Jishu Sharma, Quality Assurance Engineer bij E-ngineers in Sint-Petersburg.

Jishu, wat betekent volgens jou deze shift van waterval naar Agile voor het testen? Welke veranderingen zie je? Heeft dit ook een effect op de tools en methodes die teams nodig hebben in deze nieuwe situatie?

De IT-industrie verandert razendsnel, softwareontwikkeling is daar geen uitzondering op. Er zijn allerlei nieuwe manieren die teams helpen met sneller en efficiënter (samen)werken. Ook het testen verandert mee en evolueert continu. Zo werden Test Driven Development (TDD) en Behavior Driven Development (BDD) al snel een onderdeel van Agile.

TDD is een ontwikkelmethode waar eerst de test wordt geschreven, daarna pas de code. In eerste instantie zal de test volledig falen. Logisch, want de code bestaat helemaal nog niet! Pas daarna gaan de developers stap voor stap aan de slag met het schrijven van code die nodig is om de test te laten slagen. Het doel van TDD is met name het testen van functionaliteiten. Ook BDD is een test-first ontwikkelmethode, maar hier focust men zich op het testen van het gedrag van het systeem vanuit gebruikersperspectief. De applicatie wordt als het ware ontworpen door eerst het gedrag te beschrijven vanuit het perspectief van alle stakeholders.

Dit zijn maar twee voorbeelden die aantonen dat het testproces en -strategie behoorlijk verandert en dit resulteert inderdaad in een heel scala aan nieuwe testtools op de markt.

Welke testinstrumenten vind jij waardevol en welke meerwaarde leveren ze in het testproces?

Eén van de belangrijkste tools van dit moment is Selenium. Deze open-source software gebruiken we webapplicaties te testen en te automatiseren. Selenium is niet één tool, het is een heel framework dat inspeelt op de verschillende testbehoeftes in het team. We zien dat naar gelang we meer nieuwe functionaliteiten toevoegen aan bestaande apps, geautomatiseerd testen echt een must is voor teams. Zo vermijd je namelijk het aantal menselijke fouten en kunnen bedrijven het aantal QA-engineers beperken. Dat is belangrijk wanneer bedrijven op de kosten moeten letten.

Daarnaast zien we ook steeds meer tools die helpen bij het testen van services die op externe servers draaien. Voorbeelden hiervan zijn SOAPUI en REST ASSURED. Ook hier liggen kansen voor bedrijven om de kosten te drukken, je hebt namelijk minder testspecialisten nodig.

Wanneer we kijken naar performancetesten dan zijn WebLOAD en Apache JMeter twee populaire instrumenten. Bij performancetesten kijk je met name hoe jouw app reageert op normale belasting en piekbelasting. Dit is een belangrijk onderdeel van het testproces, want je wil uiteraard crashes en shut-downs van jouw applicatie vermijden. Daarom is het belangrijk dit soort grotere taken en herhalende werkzaamheden te automatiseren. Dit is een stuk sneller, nauwkeuriger en betrouwbaarder dan het handmatig te laten uitvoeren door QA-engineers.

Wat is het belang van Quality Assurance (QA) en hoe bereik je dat?

In de levenscyclus van een softwareproduct wordt de factor kwaliteit met name bepaald door parameters zoals naleving van het ontwerp, detectie en riskmanagement. Voor de QA is hier een belangrijke rol weggelegd. Hij of zij zorgt ervoor dat het product in iedere fase, van requirement gathering tot delivery, voldoet aan de requirements (vereisten) en de verwachtingen van de opdrachtgever.

Vroegtijdige opsporing

De QA streeft ernaar alle afwijkingen in de requirements, de defecten en de bugs dus, zo vroeg mogelijk boven water te halen. Zo blijven de productiekosten beperkt en komt de verdere ontwikkeling van het product niet in gevaar. Ontbreekt een requirement? Dan is dat altijd een defect. In de praktijk komt het vaak voor dat bedrijfsanalisten en productowners requirements over het hoofd zien, maar een QA met voldoende ervaring voegt deze alsnog toe aan het project. In veel gevallen gebeurt dat zelfs nog voor het ontwikkelteam start met implementatie. Zo draagt de QA opnieuw bij aan het beperken van de ontwikkelkosten.

Risicomanagement

De kwaliteitsfactor wordt verder ook bepaald door gebruikersveiligheid, hoe kritisch een product of project is, het belang en de behoefte aan nauwkeurigheid en precisie. Investeer daarom voldoende tijd in het inplannen van testen. Kies de juiste teststrategie, de juiste tools en zorg voor een ideaal testteam om dit alles in goede banen te leiden.

Hoe bepaal je de grootte, structuur en samenstelling van het testteam?

De grootte van een project speelt ook een grote rol bij QA en het testen. Een groot project heeft een groter testteam nodig, vaak met sub-teams voor handmatig testen, testautomatisering en performancetesten. Bij een kleiner project test de softwaredeveloper de bedrijfsgerelateerde functionaliteiten zelf, schrijft hij zelf testcases en automatiseringsscrips. Indien nodig kan hij zelfs helpen bij de implementatie en release.

Maar ook bij een kleiner project, waar gebreken en bugs behoorlijke financiële schade kunnen veroorzaken, heeft een groter en proactief testteam de voorkeur. Ook hier is automatisering dé manier om menselijke fouten tot een minimum te beperken.

Het belangrijkste is om bij elk nieuw project de grootte en de juiste, gepaste kwaliteitsinspectie vooraf te bepalen.

Wie brengt de kwaliteitseisen in kaart? En hoe ga je hierbij te werk?

Dit is de volledige verantwoordelijkheid van de Product Owner (PO). Zijn verantwoordelijkheid is een feilloze werking van de app. Hij onderzoekt welke applicatie het meest kritisch is voor de bedrijfsvoering en houdt hierbij rekening met gebruik, security en data. Hoe groter het zakelijk verlies bij een defecte applicatie, hoe groter de noodzaak om maximaal te testen.

Zodra de PO de bedrijfsrisico’s kent die samenhangen met de fouten van softwarecomponenten, wordt de QA-manager aangehaakt om het testproces te bespreken. Pas daarna kiest men de QA-tools en bepaalt men met een testplan en teststrategie in welke fase welke tests worden uitgevoerd, en hoeveel er nodig zijn. De QA-manager en de Product Owner buigen zich ook over zaken zoals technieken van bugrapportage en manieren om bugfixes te testen voor, tijdens en na de release.

Wat ik nog wil toevoegen is dat het belang van kwaliteitsborging niet altijd volledig wordt begrepen door gebruikers van de applicatie, soms niet eens door QA-teams! Testprocessen lijken vaak omslachtig en men heeft het gevoel dat het de snelheid uit het project haalt. Maar het is cruciaal dat fouten worden opgemerkt en aangepakt, zeker bij bedrijfskritische ontwikkelingen. Crasht zo’n bedrijfskritische app, dan hoef ik je niet te vertellen dat dit mogelijk een behoorlijke impact op jouw bedrijf en jouw winst heeft.

Goede communicatie is een ander domein waarin QA wil excelleren. Kwaliteitsborging is belangrijk om communicatiefouten te voorkomen. Zo is de rol van de scrum master in een Agile team een mooi voorbeeld van deze benadering. De scrum master zorgt voor heldere en duidelijke communicatie binnen het team, maar ook daarbuiten. Hij of zij zorgt ervoor dat iedereen bijvoorbeeld het doel van een meeting snapt en optimaal met elkaar samenwerkt.

Is de communicatie tussen de PO, het ontwikkelteam en het test- en release team essentieel?

Absoluut! Er zijn een aantal punten die erg belangrijk zijn voor een goede communicatie. Dat zijn:

• QA en de developer moeten de requirements op dezelfde manier interpreteren. Wat zijn de eisen en wensen die een gebruiker of klant stelt aan het product? Is daar overeenstemming, dan zitten ze op dezelfde golflengte. De QA-engineer weet hoe je iets test, wat de developer vervolgens implementeert. Hierbij helpt het om zowel de QA-engineers als de developers deel te laten nemen aan sessies met klanten om de requirements te inventariseren.
• Blijf communiceren, bijvoorbeeld in de daily stand-up, over de voortgang van het project en de toekomstige plannen en acties. Zo lopen de developers en QA-engineers synchroon om de levering te optimaliseren.
• Communicatie is belangrijk voor bugrapportage en bugfixing. Voor de release van een applicatie moeten QA-engineers worden bijgepraat door developers. Bij Agile-projecten, waar bugfixes wekelijks in productie worden gebracht, is dit van cruciaal belang.

De scrum master speelt hierin dus een belangrijk rol. Kan iedereen die rol op zich nemen?

Ja, eigenlijk kan iedereen scrum master zijn. Mits die persoon de juiste eigenschappen heeft natuurlijk. De rol van een QA-engineer bestaat al grotendeels uit het stellen van vragen en het vinden van bugs. Dat maakt de QA vaak een geschikte kandidaat om ook de rol van scrum master op zich te nemen.

Bovendien zijn de risicobeheersingsprogramma’s van softwareprojecten al grotendeels de primaire verantwoordelijkheid van QA!

Een juiste samenstelling van het testteam en een goede mix van teststrategieën, testtools en testmethoden zijn volgens mij de sleutel tot het bereiken van de juiste kwaliteit die een applicatie moet hebben.

Over de auteur

Jishu Sharma uit St. Petersburg is Team Lead, QA van E-ngineers. E-ngineers ontwerpt en bouwt groot- en kleinschalige softwaretoepassingen voor opdrachtgevers uit Rusland, Nederland, Zweden en Denemarken. Benieuwd of ze jou ook kunnen helpen met softwareontwikkeling? Neem dan contact met ons op!