Een ontwikkelaar krijgt vaak te maken met het realiseren van oplossingen en/of het uitbreiden van bestaande oplossingen. Bij deze oplossingen zijn vaak de wensen al bekend. De specificaties worden aan de hand van wensen bepaald en de totale werking van de oplossing wordt dan in documentatie vastgelegd. Uiteindelijk kan een ontwikkelaar aan de slag. Als ontwikkelaar zorg je voor de realisatie, maar hoe zorg je voor kwaliteit? Alleen testen is zeker niet voldoende. Zeker niet als het gaat om het testen van je eigen werk. Een optie is om iemand in te schakelen die de testwerkzaamheden kan doen op het opgeleverde werk.
Als ontwikkelaar zorg je ervoor dat een oplossing eerst werkt volgens de specificaties die zijn vastgesteld. Tijdens het ontwikkelen voer je af en toe kleine testwerkzaamheden uit om onjuistheden te achterhalen, zodat deze ook meteen hersteld kunnen worden. Uiteindelijk is het moment dan zover om het werk op te leveren. Het werk is afgerond volgens de specificaties en de functionaliteit is nogmaals goed gecontroleerd. Als ontwikkelaar ben je vervolgens tevreden over het eindresultaat. Het is voltooid en dus gereed om het werk over te dragen aan de testers.
Voor een ontwikkelaar kan een afkeuring van de testers op het opgeleverde werk een ergernis zijn. Want geen goedkeuring betekent geen oplevering. Hierdoor kan discussie ontstaan tussen de tester en de ontwikkelaar. Waarom is het niet goedgekeurd? Begrijpen de testers het weer niet? Of heb ik het niet goed gedaan? Er kunnen een paar mogelijke oorzaken zijn:
- meningsverschillen tussen de testers en de ontwikkelaars;
- onvolledig of onvoldoende getest vanuit de ontwikkelaars.
Meningsverschillen zijn vaak te voorkomen door concrete punten vast te leggen op papier. Helaas kunnen niet alle details van te voren worden opgenomen. Meestal zijn deze pas kenbaar nadat de oplossing ‘visueel waarneembaar’ is. Alle kleine details komen dan boven tafel. Dit kan dus leiden tot irritaties bij de ontwikkelaars want het vereist natuurlijk weer aanpassingen, ofwel: extra inspanningen.
Al met al is het zeker niet voldoende als een ontwikkelaar zijn eigen werk test. Een ontwikkelaar legt zijn focus namelijk met name op de technische vlakken waardoor de testwerkzaamheden zich beperken tot het technische deel. De functionele aspecten die bijvoorbeeld belangrijk zijn voor de eindgebruikers kunnen dan makkelijk over het hoofd worden gezien. Deze twee aspecten leiden al snel tot verscheidene vragen: ‘Tot hoe ver zou een ontwikkelaar zijn eigen werk moeten testen? Het gehele werk? Of is testen volgens de specificaties voldoende?’
Naar mijn mening zijn testers een goede sparringpartner voor ontwikkelaars. Zij hebben namelijk een heel andere blik op het opgeleverde werk: minder technisch en meer in het belang van de oplossing. Op deze manier leveren ze een grote bijdrage aan de kwaliteit van het eindresultaat. Hoeveel irritatie je als ontwikkelaar ten opzichte van de testers ook hebt, het valt niet te ontkennen dat zij onmisbaar zijn in een ontwikkeltraject.
Reacties
Tester zijn niet alleen goede sparringspartners voor ontwikkelaars maar ook voor business analisten, informatie analisten, requirement opstellers, de business, etc.
Jammer genoeg wordt in de praktijk de tester vaak pas op het laatst bij het project betrokken, wanneer ontwikkeling al een feit is. Terwijl iedereen toch inmiddels weet dat hoe eerder je de fout eruit haalt des te minder de herstelkosten zijn? Gelukkig worden bedrijven zich hier steeds meer bewust van.
Wat een slecht artikel zeg. Wel heel erg gericht op het gelijk van testers. Zo zijn er bij meningsverschillen tussen ontwikkelaar en tester nog wel een paar mogelijkheden, die niet genoemd worden. Bijvoorbeeld: de tester heeft zijn werk niet goed gedaan of de specs niet goed geïnterpreteerd.
Erik,
Niet te vergeten het aantal keren dat specs incompleet zijn, of er eigenlijk helemaal geen specs zijn doch slechts een kreet in de wandelgangen.
Je zou ze de kost niet willen geven.
Hebben we het nog niet gehad over specs die tijdens de ontwikkeling nog eens zes keer zonder enig overleg voledig nieuw verzonnen worden.
ICT... wat een vak he.
Uit ervaring weet ik dat slecht opgeleverd werk vaak komt door de gebrekkige functionele en technische ontwerpen. Door voor de programmeerfase de testscripts te schrijven, zijn al een heleboel fouten te onderkennen.
Maar al te vaak heb ik mee gemaakt dat er te veel aannames worden gedaan die achteraf niet juist blijken te zijn.
Maak de functionele en technische ontwerpen zo uitgebreid mogelijk. Dit voorkomt dat er te veel "foute" progrmmatuur wordt opgeleverd.
@ Robin Rijken
De schuld ligt ook vaak bij de business. We willen "iets". Ja prima. definiëer iets.
Als ervaren tester weet ik dat je als tester echt niet hoeft te wachten op de ontwikkelaar, business analist of ontwerper. Dat is een aanname die een goede tester snel afleert.
Dus testers, een goed voornemen voor 2012:
Ga, indien iets niet duidelijk is, het navragen bij de verantwoordelijke persoon en vraag door tot het duidelijk is. En niet via email, maar aan het buro als het kan.
En doe dit zo vroeg mogelijk in het testproces.
Een voornemen waar ik me, net als de voorgaande jaren, aan wil houden in 2012.
PS:
Tester (ook @Robin en @de tester) laat je werk reviewen.
Niet alleen door een collega-tester, maar ook een ontwikkelaar, ontwerper of business-analist. Wij testers maken ook fouten en wellicht kan er zo in een vroeg stadium mogelijke vertraging vermeden worden.
Het betrekken van testers, business analysten, programmeurs: allemaal waar.
Vergeet echter een partij niet: "ontwikkeling is de eerste fase van beheer". Afhankelijk van het onderzoeksbureau blijkt 60-80% van kosten van een applicatie in beheer te zitten. Het loont om al in de ontwikkelfase een beheerder te betrekken bij het test- en implementatietraject.
@ Michiel Kroon: Helemaal juist: na een project van een jaar zit Beheerd (technisch en functioneel) zeven jaar of langer vast aan het systeem. Terecht dat ook Beheer het ontwerp reviewt.
Jammer genoeg wordt dat reviewen niet altijd (of zelden of nooit) serieus opgepakt: Na de lunch onderuit in de bureaustoel, lekker in het zonnetje, bekertje koffie erbij en de voeten op het bureau: "Zo, nu even dat ontwerp reviewen. (geeuw)" Met als resultaat: "Ja, dat is wel ongeveer wat we bedoelen." Daar hebben we niet zoveel aan.
Als een reviewer niet vanuit zijn eigen functie het belang van goed reviewen ziet (als het niet van binnen komt) dan kan een projectmanager nog bevorderen dat er serieus gereviewd wordt. Maar projectmanagers worden beoordeeld op hoe zij het project hebben afgerond - niet op hoeveel nazorg hun product nodig heeft. Dus hebben zij geen prikkel om serieus werk te maken van reviews.
Dan komt de bal te liggen bij de opdrachtgever. Volgens PRINCE2 is de "stuurgroep", het gremium waarin opdrachtgever overlegt met de gebruikersorganisatie en de bouwers, verantwoordelijk voor kwaliteitsbewaking.
Is dat moeilijk? Nee, niet echt: vraag de projectleider om bij het periodieke voortgangsoverleg een lijstje te tonen waarin per ontwerp is aangegeven wanneer het is gereviewd, door welke functionarissen, hoeveel bevindingen er zijn genoteerd en welke afhandeling werd afgesproken. In PRINCE2 heet dat een Quality log.
zolang je maar niet zoiets doms bedenkt als 'stragile testen' gaat alles wel goed. gewoon old-school. eerst discussie, dan feiten, dan testplan.
en niet andersom.