Testen niet langer op het kritieke pad

Ikzelf ervaar het al jaren als een probleem: de testuitvoering bepaalt in sterke mate in hoeverre het project uitloopt. Niet zozeer door de test zelf, als wel doordat de kwaliteit van de code niet zodanig is als vooraf is verwacht. En het blijkt pas tijdens de eerste testrun of het haalbaar is om de deadline te halen, of dat het aantal First time-right zó laag blijft dat de verwachting om het de deadline te kunnen halen niet meer reëel is. Je zou dus kunnen stellen dat je pas bij de testuitvoering vast kunt stellen of de projectplanning reëel blijkt te zijn.bottleneck

Dat laat zich natuurlijk vervroegen door bij de developers al mee te kijken als tester. Het is aan de ene kant jammer dat de testers niet betrokken zijn bij het werk van de developers – en dus al eerder issues kunnen signaleren en er al eerder in zijn algemeenheid feedback komt op haalbaarheid van de verwachte planning. Maar aan de andere kant is er ook een vraagstuk dat de testuitvoering met het handje moet. Automatisch testen kan voor beide vraagstukken een tool zijn dat te adresseren.

In de testwereld bestaat het principe dat je automatisch testen pas inzet als de code volgroeit is; een zekere stabiliteit heeft bereikt. Het is immers nodig de automatische test exact te laten matchen met de gebruikte naamgeving van de code, anders faalt de test per definitie. Wanneer er code wordt aangepast moet ook de automatische test daarop weer aangepast worden. Er vind een continue afstemming plaats van de automatische test op de laatste versie van de code.
In moderne softwareontwikkeling gaat men daar anders mee om. De automatische test zegt simpelweg dat de code af is wanneer de test succesvol draait. Het is een leidraad voor de developer. Het is de code die aangepast wordt, ontwikkeld wordt, tegen de automatische test tot dat het gedrag van de code daaraan matcht.

De gedachte om code achteraf te testen is natuurlijk, dat wil zeggen in de context van de traditionele ontwikkelmethodieken. Je hebt immers eerst executeerbare code nodig voor je iets kunt testen.
Die vermeende ‘natuurwet’ is sinds het toepassen van de agile principes ontkracht tot een principe dat slechts van de methode onderdeel is maar zeker niet zo vast staat als het vallen van een appel uit de boom. De agile practice Test Driven Development (‘TDD’) (1) verplaatst niet alleen de volgorderlijke positie van codering en test maar verwijdert ook de test uit het kritieke pad. Het vermindert bovendien het kritieke pad daar waar het aankomt op de verificatie tussen de specificaties (de automatische tests) en de implementatie.

Hoe zou een traditioneel project verlopen waarin TDD wordt toegepast? Ik ben héél benieuwd naar een traditioneel project waarin dat wordt toegepast en wat de resultaten hiervan zijn!

(1) Meer over TDD:
http://www.agiledata.org/essays/tdd.html
http://testobsessed.com/2008/12/08/acceptance-test-driven-development-atdd-an-overview/

Dit bericht werd geplaatst in Agile like, Algemeen, ATDD, Testen en getagged met , , , , , , , , , , , , , , , . Maak dit favoriet permalink.

4 reacties op Testen niet langer op het kritieke pad

  1. harry zegt:

    Of je nu van TDD uitgaat of niet, je zult in eerste instantie altijd rekening moeten houden met voortschrijdend inzicht op de requirements. Ik zie nog veel te veel projecten waarin deze requirements te veel fluctueren. Zolang deze niet “vast” staan en smart zijn, zullen test (en development?) altijd op het kritieke pad blijven. Agile ontwikkelmethoden hebben juist de mogelijkheid om deze aanpassingen aan requirements te doen op ieder noodzakelijk gewenst moment en daarmee zal zowel test als development moeten bijsturen. Vroeg testen heeft zeker zijn voordelen om te sturen in het gehele ontwikkelproces. Je mag er ook vanuit gaan dat het samen werken aan ontwikkeling en testen van een applicatie zeker meer waarde heeft in situaties waarin de fluctuaties in requirements gering zijn. In andere gevallen moet je je terdege afvragen waar het meeste tijd wordt gewonnen en of Agile op dat moment nog wel voldoende voordelen biedt (indien er ook van TDD gebruik gemaakt wordt). Het is dan ook de vraag of in andere metodieken wel veel voordeel van TDD worden behaald. Het blijft altijd afwegen waar de meest optimale benadering ligt.

  2. Anko zegt:

    Harry, mijns inziens zie je 1 aspect over het hoofd, namelijk dat door toepassing van TDD de kwaliteit van de requirements (wanneer je TDD ook op requirements toepast) en die van de code verhoogt. Door in eindstaten (lees: testgevallen) te denken, kom je tot een verrijking van de oorspronkelijke formulering. Hierdoor zul je minder ‘test-and-fix-cycles’ hebben waardoor het testen minder op het kritieke pad komt.

    • harry zegt:

      Ja Anko, dat is precies ook wat ik zeg: “Je mag er ook vanuit gaan dat het samen werken aan ontwikkeling en testen van een applicatie zeker meer waarde heeft in situaties waarin de fluctuaties in requirements gering zijn” –> dit zal inderdaad bevorderen dat de fluctuaties nog minder worden. Het is een cirkel. Er zit m.i. echter wel een adder onder het gras. Indien de fluctuaties echt groot zijn (en dat kom ik helaas nog veel tegen) dan kun je niet echt veel met TDD. Dan zal dat eerder meer tijd vergen dan dat het oplevert en dan blijft het testen op het kritieke pad. De requirements moeten een bepaald niveau hebben voordat TDD wat op gaat leveren. Het is dus nog steeds zaak af te wegen of het project “volwassen” genoeg is om met TDD benaderd te worden. En natuurlijk eens dat het meerwaarde oplevert indien deze afweging leidt tot het doen van een TDD benadering. M.i. is het een vereiste om requiremenst in hoofdlijnen echt duidelijk en smart te hebben. Daar moet de eerste focus liggen, daarna op TDD

  3. Eric Jimmink zegt:

    Hallo Harry. Goed punt, fluctuerende requirements zijn er altijd, en daar wordt heel verschillend mee omgesprongen.
    Mary Poppendieck verwoordde het als volgt: “If you have requirements churn, you are specifying too early. If you have test-and-fix cycles, you are testing too late. Why do early specification and late testing seem like such a good idea?”.
    De agile gedachte is dat het proberen om a priori beter te specificeren doorgaans verspilde moeite is, omdit die voorbereiding niet meebeweegt met de business.

    Als bouw en test goed kunnen inspelen op een wijziging in de requirements, en bijvoorbeeld een wijziging kunnen implementeren en testen binnen twee dagen zodat deze weer releaseable is, dan kan er nauwelijks nog gesteld worden dat bouw en test op het kritieke pad zitten. (Immers, het beslissingstraject voor een wijzigingsverzoek is in veel organisaties beduidend langer.)

    Overigens kan ik uit ervaring zeggen dat in zowel officeel-Agile projecten, als ook in een traditioneel project met afgetekende requirements documenten, vroege samenwerking tussen bouw en test veel tijd kan besparen. Door samen te werken wordt eerder de noodzaak onderkend, om aan te sturen op een aanpassing van de requirements.
    Wanneer er zich meerdere oplossingsrichtingen aandienen, kan in overleg gekozen worden voor een variant die beter testbaar en/of onderhoudbaar is.
    TDD draait namelijk niet alleen om het snel produceren van de juiste code, uitgaande van de test. Veel meer gaat het om het goedkrijgen van het design, opdat de oplossing ordelijk en onderhoudbaar blijft. Tijdens het coderen is er namelijk ook veel voortschrijdend inzicht over de gekozen oplossing.

    Als er in een traditioneel project gekozen wordt voor TDD (dat heb ik nog maar 1 keer meegemaakt, in een herbouwtraject), dan heeft het monodisciplinaire ontwikkelteam daar hetzelfde voordeel van als een multidisciplinair team: omdat er veel testen zijn geschreven, kan de oplossing veilig aangepast worden.

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s