Testen in klein agile team

[Rekcor]

Ik werk bij een klein softwarebedrijf (2 programmeurs) aan een webapplicatie: Angularjs frontend, Drupal 7 backend.

Deze applicatie is in de loop der jaren een stuk complexer geworden. Waar we nu tegenaan lopen is dat, dankzij onze verwoede testinspanningen, er regelmatig bugs/bugjes in nieuwe releases blijken te zitten. Tot nu toe gelukkig zonder al te ernstige gevolgen, maar dat is natuurlijk een kwestie van tijd.

Er moet dus een goed testbeleid komen.

De vraag is alleen: Waar te beginnen? De meeste resources op internet (bijv. https://www.lynda.com/IT-...ter/772329/5009748-4.html) gaan uit van grote bedrijven en navenante teams, waar kennelijk mensen rondlopen die 100% van hun tijd kunnen besteden aan testen. In het bedrijfje waar ik werk, is dat (financieel) niet aan de orde.

Wat zijn de eerste grote/simpele stappen die we kunnen nemen? Wat is een handige manier om het testproces te structureren? (want wij testen natuurlijk wel, maar nog niet heel gestructureerd).

[Davidshadow13]

Wat doen jullie nu al aan testen je kunt binnen de development team namelijk al best wat dingen implementeren om meer stil te staan bij testability. Zoals bijvoorbeeld werken volgens TDD. Maar dat hangt er helemaal vanaf hoe mature jullie al zijn?

• Hoe ziet jullie DevOps straat eruit?
• Hebben jullie al geautomatiseerde Unit Test/Integration Test/UI Tests?
• Documenteren jullie je Test Effort? Bijv. regressie testen bijhouden in TestRail, Azure DevOps Test Plans etc.

Iets meer inzicht geven in jullie huidige proces helpt om je beter op weg te kunnen helpen.

[Rekcor]

Dank!

Onze huidige 'proces'
- We werken qua versiebeheer zo https://map-client.readth...atest/_images/gitflow.png
- Developers testen eerst zelf en sturen als een (feature) branch af is, een mailtje naar onze interne gebruikers om te testen op een testsite; uiteraard beschrijven we zo goed mogelijk wat er hoe getest moet worden. Hier volgen meestal issues uit, die we dan weer fixen, etc.
- Bij een release wordt alles nogmaals getest, door een developer en minstens 1 andere interne gebruiker.

Er is dus niets geautomatiseerd. Het probleem is dat we nu duizenden en nog eens duizenden regels code hebben, met allerlei onderlinge afhankelijkheden (en over 3rd party libs nog maar te zwijgen) en dat het echt een sh#tload werk is om al die tests te schrijven en tools als TestRail e.d. aan te schaffen, in te richten, e.d. In het geval van oneindig tijd/geld is dit natuurlijk wat er minstens moet gebeuren, maar helaas is er geen oneindig tijd/geld.

Ik hoef niet overtuigd te worden dat dit is waar het uiteindelijk naar toe moet, maar ben voor nu het beste geholpen bij een paar realistische stappen om van onze huidige situatie naar de gewenste situatie te groeien.

[ Voor 0% gewijzigd door Rekcor op 23-03-2020 14:14 . Reden: verduidelijking ]

[Nvidiot]

- Als dit nog niet gebeurd is, richt een code-review tool in. Dit gaat een hoop bugs schelen.
- Voeg voor alle code die je aanpast / toevoegt een test toe. Dit lost niet het probleem op dat er nog geen tests zijn voor alle oude code, maar alle nieuwe code (en de code waar je bugs in fixt) hebben wel tests
- Richt de code-review tool zo in dat als je code niet door de tests komt je de code niet kunt opnemen in de main branch
- Pak een X aantal uur per week waarin je 'technical debt' oplost. Begin dan met het schrijven van tests voor een stuk(je) van de huidige code en ga daarna de code netjes maken. Dit kan een leuk klusje zijn voor bijvoorbeeld de vrijdagmiddag.

Voor de stukken die niet makkelijk te automatiseren zijn qua tests zul je of moeten refactoren zodat het wel testbaar wordt, of een handmatige test-beschrijving moeten opschrijven. Dat test plan pak je er dan bij zodra je een nieuwe versie wilt uitrollen, zodat je kunt controleren of dat stuk van de applicatie nog goed werkt. Focus je hierbij op de kritieke stukken van de applicatie en de stukken van de applicatie die de meeste bugs bevatten.

[Tk55]

Eens met @Nvidiot. Verandering in code betekent vereist toevoegen van tests. En zeker af en toe technical debt aanpakken incl nieuwe tests. Zo krijg je langzaam aan een steeds stabielere applicatie, die ook beter met veranderingen om kan gaan, dankzij de tests.

Probeer ook in kaart te brengen waar de grootste problemen zitten, dan kun je daar je tijd in investeren.

[Rekcor]

Dank zover, erg nuttig!

- Voeg voor alle code die je aanpast / toevoegt een test toe. Dit lost niet het probleem op dat er nog geen tests zijn voor alle oude code, maar alle nieuwe code (en de code waar je bugs in fixt) hebben wel tests

Dit vind ik nog de lastigste onderdeel: dit is toch ontiegelijk veel werk? Als ik https://www.guru99.com/angularjs-testing-unit.html bekijk, is de test-code langer dan de te testen code.

Bovendien: er zijn zo ontzettend veel dingen/aspecten/samenwerkende stukken code waarvoor we dan tests moeten schrijven, ook nog eens allemaal asynchroon (client-side dan). Dat is toch niet te doen? En als je moet kiezen: hoe weet je dan wat je moet kiezen?

Dat test plan pak je er dan bij zodra je een nieuwe versie wilt uitrollen, zodat je kunt controleren of dat stuk van de applicatie nog goed werkt. Focus je hierbij op de kritieke stukken van de applicatie en de stukken van de applicatie die de meeste bugs bevatten.

Het probleem bij ons is dat die kritieke stukken eigenlijk altijd wel goed gaan (die vallen per definitie op en testen wij als devs natuurlijk erg goed); het gaat vooral mis bij meer obscure use cases, in sommige browsers, en dan ook niet altijd, vanwege async / race condities.

[Nvidiot]

Rekcor schreef op maandag 23 maart 2020 @ 17:03:

Dit vind ik nog de lastigste onderdeel: dit is toch ontiegelijk veel werk? Als ik https://www.guru99.com/angularjs-testing-unit.html bekijk, is de test-code langer dan de te testen code.

Bovendien: er zijn zo ontzettend veel dingen/aspecten/samenwerkende stukken code waarvoor we dan tests moeten schrijven, ook nog eens allemaal asynchroon (client-side dan). Dat is toch niet te doen? En als je moet kiezen: hoe weet je dan wat je moet kiezen?

Begin met testen zo klein mogelijk. Pak de losse functies die je hebt en schrijf daar tests voor. (Unit testing) Daarmee pak je niet de bugs die zitten in de interactie van meerdere functies, maar het is een goed begin.

Als dat een beetje begint te lopen, kun je gaan kijken naar integration tests, het combineren van verschillende functies die tot het gewenste resultaat leiden.

Daarna kun je gaan kijken naar system testing, denk daarbij aan iets als Selenium, wat automatisch je frontend kan benaderen en tests kan uitvoeren.

En als laatste heb je de user acceptance tests, die je zo te lezen al hebt ingericht.

Probeer niet meteen met system testing of integration tests te beginnen, die zijn vaak veel werk om op te zetten, en er is al een boel winst te behalen door het simpelweg testen van de kleinste stukken van je code. Je zult merken dat zodra je jezelf dwingt om *elke* functie die je schrijft te testen je vanzelf beter testbare functies gaat schrijven. Dit leidt vanzelf tot minder bugs - een functie van 100+ regels code is bijna niet goed te testen, 10 losse functies met 10 regels code is vaak wel goed te testen.

[Gomez12]

Rekcor schreef op maandag 23 maart 2020 @ 17:03:
[...]
Dit vind ik nog de lastigste onderdeel: dit is toch ontiegelijk veel werk? Als ik https://www.guru99.com/angularjs-testing-unit.html bekijk, is de test-code langer dan de te testen code.

Bovendien: er zijn zo ontzettend veel dingen/aspecten/samenwerkende stukken code waarvoor we dan tests moeten schrijven, ook nog eens allemaal asynchroon (client-side dan). Dat is toch niet te doen? En als je moet kiezen: hoe weet je dan wat je moet kiezen?

Tja, dat is een beetje de kunst van goed testen kunnen schrijven. Je moet een beetje aanvoelen waar het wel en niet zinnig is om testen te schrijven, 100% code-coverage is nog wel te doen, maar 100% alle situaties aftesten is simpelweg niet meer te doen.

Wat bij ons redelijk werkt is om de tests door een collega te laten schrijven zonder dat die de code ziet (die krijgt alleen een lijstje method-names), ik zie de tests niet en schrijf simpelweg de code. 1e stap van code-review is dan tests uitvoeren over de code.

Als je namelijk zelf tests gaat schrijven voor je eigen code moet je op een bepaalde manier heel erg goed zijn, want wat wij merkten is dat wij dat niet konden, onze tests gingen inherent over situaties die we ook al in code afhandelden, oftewel leuk voor refactoring, maar in 1e instantie slagen alle tests, want als ik het kan bedenken om ervoor te testen kan ik het net zo goed direct in code fixen.
Terwijl ik nu alles fix wat ik kan bedenken en als mijn collega iets anders kan bedenken dan faalt het.

[...]
Het probleem bij ons is dat die kritieke stukken eigenlijk altijd wel goed gaan (die vallen per definitie op en testen wij als devs natuurlijk erg goed); het gaat vooral mis bij meer obscure use cases, in sommige browsers, en dan ook niet altijd, vanwege async / race condities.

Tja, houd er ook rekening mee dat een gedeelte van "bugs" simpelweg geen bugs zijn, maar puur spec-fouten...

Zo hadden we laatst een discussie met een klant die wilde dat iets utf-8 op het scherm ging verwerken. Tuurlijk, geen probleem. Toen bleek er een of andere etter bij de klant te zitten die dus even liet zien dat er aparte utf-8 codes zijn, oftewel de klant was niet echt blij dat er emoticons doorheen gingen, dat er right-to-left control characters etc etc doorheen gingen.
Toen hebben we hem maar verteld dat hij of een whitelist kan geven van wat hij wel wil toestaan, of hij kan een blacklist aanleveren als hij iets per definitie niet wil, maar het is voor ons onmogelijk om wel utf-8 toe te staan alleen random characters te weigeren.

Zoals je zelf al zegt "in sommige browsers" zijn dat wel officieel ondersteunde browsers door jullie? Want het is heel leuk als het fout gaat op IE6, maar dat heet pech. Het is heel leuk als het fout gaat op Brave, maar is dat echt relevant? Het is heel leuk dat het fout gaat op een Android 4.0 toestel, maar is dat relevant?

Oftewel beperk ook je doelgroep goed. Doe je dit niet dan zal je idd alles moeten testen en dan wordt het een onmogelijke taak...

[Davidshadow13]

Rekcor schreef op maandag 23 maart 2020 @ 17:03:
Dank zover, erg nuttig!


[...]


Dit vind ik nog de lastigste onderdeel: dit is toch ontiegelijk veel werk? Als ik https://www.guru99.com/angularjs-testing-unit.html bekijk, is de test-code langer dan de te testen code.

Als je puur volgens TDD werkt dan is je test code meestal ook langer dan je business logica, omdat je je tests dan eerst schijft. Maar uit jouw antwoorden merk ik een paar dingen op.

• Git workflow is duidelijk maar wat is jullie proces workflow? Ik begrijp dat er dus geen peer code reviews zijn in jullie proces en dat er niet met Pull Request gewerkt wordt? Als dit inderdaad het geval is begin hier dan mee. Waar hosten jullie je Git repository, elk platform heeft wel zijn eigen PR / Review tooling. GitLab en Azure DevOps werkt erg fijn vind ik. Peer reviews kan je inbouwen als aparte swimline op je workflow board in de proces tooling die je gebruikt (JIRA/YouTrack/DevOps Boards) Gebruik je deze tooling nog niet? Begin hier dan mee.
• Ik begrijp dat er ook nog geen geautomatiseerde unit tests zijn? Begin hier dan ook mee. Zorg dat je een test framework opzet voor je back-end code en voeg een test toe wanneer je een bepaalde functie/methode aanpast. "Test for the smallest possible unit" zodat je scope klein blijft en je tests dus ook.
• Probeer meer structuur in de manuele regressietesten te krijgen door van te voren alle mogelijke happy flows te documenteren die getest moeten worden, samen met een aantal voor de handliggende foutieve flows en documenteer dit in een regressie test tool.

Ja al het bovenstaande kost heel veel tijd. Je kunt niet in één keer je hele codebase aanpassen. Maar door dit in te bouwen in je workflow voeg je tests toe voor alle code die je aanpast dus met een jaar of 2 is je hele codebase gecoverd. Ik heb dit meerdere keren geimplementeerd in kleine teams en werkt erg goed. Je hebt enkel een week (ongeveer) nodig om je unit test platform netjes op te zetten en te integreren, samen met je DevOps straat als je die nog niet hebt. Mocht je meer details willen stuur dan even een PM.

[Rekcor]

Code review doen we inderdaad ook, niet altijd, maar meestal.

Maar als een programmeur een uur werkt, hoeveel tijd is bezig met echt programmeren, en hoeveel tijd met het schrijven van tests, reviewen van andermans code, happy flows documenteren etc? Ik krijg een beetje het gevoel dat dit al snel naar 50/50% gaat?

[Davidshadow13]

Rekcor schreef op dinsdag 24 maart 2020 @ 16:45:
Code review doen we inderdaad ook, niet altijd, maar meestal.

Maar als een programmeur een uur werkt, hoeveel tijd is bezig met echt programmeren, en hoeveel tijd met het schrijven van tests, reviewen van andermans code, happy flows documenteren etc? Ik krijg een beetje het gevoel dat dit al snel naar 50/50% gaat?

Dat kan soms het geval zijn. Maar bij TDD zit het echt in je proces verwerkt. Je bekijkt het development stukje dan een stuk anders aan. Dit opzetten kost in het begin wat tijd maar uiteindelijk gaat de kwaliteit van je software er drastisch op vooruit. Je hebt minder bugs en dus ben je ook minder tijd kwijt met incident management etc.

In kleine teams is dit lastiger te implementeren want veel overhead. Je hoeft dus ook niet alle processen op de letter te volgen maar iets investeren in kwaliteit gaat zich weldegelijk uitbetalen. Als je zorgt voor goede reuseability van je back-end en tests dan scheelt dat al een hele hoop.

Verder klinkt het alsof je zoekende bent naar waar in het "maturity process" voor een software development team. Een aanrader is dan om dit artikel eens te lezen en de Joel test voor jezelf te maken: 12 steps to better code.