Testen 3.0 en RUP op Maat

We zullen een korte vergelijking maken van Testen3.0 en RUP op Maat®. Testen3.0 is het vervolg op Testen2.0 waarin Ordina de rol van de Agile Tester beschrijft. In Testen3.0, waarvan nog geen boek is maar wat in ontwikkeling is aan de hand van berichten op deze blog, staat het testen als Team in een Agile project centraal. RUP op Maat is de projectmethodiek die Ordina hanteert voor het agile toepassen van RUP. Deze aanpak zit vol met Scrum-elementen en is een uitstekend framework voor het agile uitvoeren van middelgrote projecten. In essentie zijn beide verhalen prima met elkaar te verenigen, namelijk als twee invalshoeken op eenzelfde visie.

Het aandachtsgebied van Testen3.0

Het aandachtsgebied van Testen3.0 is breed, maar biedt ruimte voor het gebruik van aanvullende methoden.

Scrum als een gemeenschappelijke basis
Allereerst moet worden opgemerkt dat in de meest recente versie van RUP op Maat net als in Testen3.0 een aantal concepten van Scrum zijn opgenomen. Beiden gaan bijvoorbeeld uit van een Product Owner met een Product Backlog, en een Scrum Master die het zelfsturende multidisciplinaire team faciliteert. Ook wordt er verondersteld dat het team na iedere iteratie de effectiviteit van haar eigen werkprocessen evalueert door middel van een zogenaamde retrospective.

Als we kijken naar de “Uitgangspunten van RUP” (zoals vermeld in RUP op Maat), dan zien we veel overeenkomsten:
Conceptuele verschillen
Uiteraard zijn er ook conceptuele verschillen. Zo kent Testen3.0 geen expliciete fasering, waar er in RUP op Maat sprake is van een viertal fasen. Die fasen streven de volgende doelen na:

Inception: overeenstemming over doelen, scope en procedure
Elaboration: stabiele architectuur in werkende code
Construction: product potentieel operationeel
Transition: product gereed voor release.

Die 4 fasen worden niet specifiek genoemd in Testen3.0, maar de doelen van de laatste 3 fasen wel.
Zoals ook vermeld in de tabel hierboven, staat het doel van elaboration ook centraal in Testen3.0 . Testen3.0 neemt het voorschrift van Scrum over dat iedere iteratie resulteert in een potentieel productierijp systeem. Daarmee hebben we dus ook het doel van de construction fase.
Bij de transition fase voor de in productie-name van een release merken we op dat in Testen3.0 de afrondende stappen expliciet benoemd worden als een aparte laag in de Definition of Done. In het ideale plaatje worden die stappen echter zoveel mogelijk reeds gerealiseerd als onderdeel van het reguliere werk binnen de iteratie.

In RUP op Maat wordt gesproken over acceptatie die mogelijk 1 iteratie achterloopt. In Testen3.0 streven we naar en we sturen op zoveel mogelijk continue acceptatie binnen de sprint omdat dat snelle correcties mogelijk maakt, de samenwerking ten goede komt en het risico inperkt van projectvertraging als gevolg van late of moeizame acceptatieprocessen.

In beide methoden kunnen teamleden meerdere rollen hebben. In RUP op Maat zijn de verantwoordelijkheden expliciet benoemd per rol en per fase. In Testen3.0 wordt dat achterwege gelaten, in de veronderstelling dat de teamleden en de betrokkenen van de business in een coöperatieve modus zitten en op dit punt geen sturing nodig hebben. Indien teamleden kunnen werken zonder strak omlijnde taken en verantwoordelijkheden, bereid zijn om taken uit te voeren buiten hun eigen comfort zone en pro-actief vragen om feedback, dan leren ze veel van elkaar en maken ze weinig fouten.

Testen3.0 kent geen formele use case specifications maar schrijft wel voor dat er testgevallen bij de specificaties worden opgesteld. Niet achteraf, maar juist vooraf, als richtpunt voor de bouw. Dit verbetert het begrip van de specificatie en zorgt dat de omvang ervan beperkt blijft.

De invulling van het testen
In RUP op Maat is de wijze waarop het testen wordt ingevuld, bewust in het midden gelaten, door dit slechts te beschrijven op het niveau van de overkoepelende workflow. Dat houdt in dat beide methodieken in principe gecombineerd kunnen worden. Waar RUP op Maat meer sturing geeft op projectniveau, geeft Testen3.0 aanvullingen voor wat betreft de uitvoering van het testen en de wijze van samenwerking met de business.

Testen3.0 gaat uit van een viertal werkwijzen die de onderlinge samenwerking op testgebied omschrijven:

  • ATDD (specificeren met voorbeelden), dus het schrijven van testgevallen bij specificaties (user stories, dan wel use cases)
  • Continue acceptatie (zie hierboven: samen met de klant, gedurende de iteratie)
  • Het strikt hanteren van een Definition of Done (wat niet voldoet aan het afgesproken kwaliteitskader, wordt niet uitgeleverd)
  • Collective test ownership (het met het voltallige team beheren van alle testen)

Afgezien van de gezamenlijke verantwoordelijkheid, die RUP op Maat voorschrijft en waar Testen3.0 geen onderscheid in de rollen maakt, zijn die vier werkwijzen geen van allen strijdig met RUP op Maat.

Binnenkort in de reeks vooruitblikken op Testen3.0: meer over de bovenstaande werkwijzen.

Over ericjimmink

Eric Jimmink is een testconsultant met een achtergrond als ontwikkelaar / meewerkend voorman. Zijn eerste agile project was al in 2001. Eric geniet bekendheid als co-auteur van het boek 'Testen2.0', als schrijver van artikelen over agile testen, en door het geven van presentaties. Momenteel is Eric bezig met 'Testen3.0', waarvan enkele fragmenten geplaatst worden op de AgileOrdina blog.
Dit bericht werd geplaatst in Agile methodieken, Algemeen, Testen3.0 en getagged met , , , , , , , , , , , , , , , , , , , , , , , . Maak dit favoriet permalink.

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