‘Je laat een slager toch zijn eigen vlees niet keuren?'. Deze opmerking hoor ik de laatste tijd nogal eens voorbijkomen. Daarmee wordt dan bedoeld dat software altijd getest moet worden door een andere partij dan de partij die de software maakt. Waar komt dat idee toch vandaan?
Ik kijk wel eens naar ‘Oorlog in de keuken', waarin Gordon Ramsay in het slop geraakte restaurants steevast van de ondergang weet te redden. Je ziet maden in de keuken, ruziënd personeel en ook koks die hun eigen gerechten nooit proeven. Die krijgen van Gordon ongenadig er van langs. En terecht! Elke zichzelf respecterende kok proeft hoogstpersoonlijk het eten dat hij bereidt! Een slager hoort zijn eigen vlees WEL te keuren. Een softwareleverancier test zijn eigen product, punt uit!
Let wel, je laat iedere slager natuurlijk niet zelf bepalen of zijn producten voldoen aan de eisen die de warenwet stelt. En laat de klanten maar uitmaken of het vlees lekker is of niet; dat de slager het lekker vindt zegt natuurlijk niets, hij is immers bevooroordeeld. Maar het lijkt me logisch dat de slager zelf ook zijn controles uitvoert en niet wacht tot de keuringsdienst van waren of een klant ontdekt dat er beestjes in het gehakt kruipen.
Terug naar de ict: ik zie in de praktijk dat de analogie met de slager vaak te onpas wordt gebruikt, als excuus voor ontwikkelaars om ongeteste software op te leveren. De begrippen ‘testen', ‘accepteren' en ‘onafhankelijk keurmerk geven' worden continu door elkaar gehaald. Mijn stelling is dat het testen van software gewoon hoort tot de verantwoordelijkheden van de leverancier. Het accepteren – vaststellen of de leverancier zijn afspraken goed is nagekomen – is de verantwoordelijkheid van de opdrachtgever. Vaststellen of een product voldoet aan normen en wettelijke eisen (onafhankelijk keurmerk) behoort tot het domein van onafhankelijke instanties.
Bij uitbesteding van software-ontwikkeling lijken deze uitgangspunten soms ineens niet meer geldig en ik maak dus mee dat een opdrachtgever na oplevering uitgebreide softwaretesten uitvoert (of laat uitvoeren) die eigenlijk gewoon door de leverancier hadden moeten worden gedaan. Er zijn natuurlijk genoeg testbedrijven die in zo'n geval maar al te graag dit werk overnemen, maar ik heb toch liever een kok die zelf goed proeft.
Vreemd. Ik heb ISEB ISTQB Foundation behaald uit interesse en ik heb nog nooit als software tester werkzaam geweest. Al die genoemde begrippen en methoden worden uitgebreid gedefinieerd en besproken in zo’n entry level examen.
Beste Gerlof,
Je klinkt nogal boos. Ik kan me voorstellen dat het op den duur nogal kan frustreren dat de leverancier niet goed (systeem)test. Ook ik heb soms het gevoel dat ik geen tester ben, maar een debugger. Aan de andere kant, as zou alles piekfijn getest zijn dan hadden wij ook niet door de opdrachtgever ingehuurd hoeven worden en hadden wij ook geen werk gehad. Hoe minder (goed) er door ontwikkelpartijen zelf getest wordt, hoe groter de markt voor ‘de tester’.
Tot zover het commerciële oogpunt. Vanuit kwaliteitsoogpunt vind ik ook dat de leverancier de opgeleverde software goed getest moet hebben. Het moet in ieder geval technisch werken en er mogen geen grote/blokkerende functionele bevindingen zijn; het testobject moet testbaar zijn.
Hier kom je achter door een gedegen pretest op te stellen en in te plannen en entrycriteria voor de acceptatietest op te stellen. Je spreekt samen met de opdrachtgever en leverancier af waar de software aan moet voldoen, voordat jij begint met de acceptatietest. Afspraken met je stakeholders zijn de basis voor een goed testtraject. Ook afspraken over definities als testen, accepteren, keurmerken etc.
Als je vindt dat testen, die de opdrachtgever uitvoert eigenlijk door de leverancier uitgevoerd had moeten worden zou je de opdrachtgever kunnen adviseren om andere afspraken te maken en op een andere manier te sturen. Belangrijk hierbij is om business driven te werk te gaan. De opdrachtgever blijft aan het sturen. Jij adviseert en signaleert. Als jij vindt dat het testen niet goed gaat, is het dus aan jou om dat bij je opdrachtgever aan te kaarten.
Succes met je opdracht!
Met vriendelijke groet,
Mark
Er kan door de aanname van bouwers dat er toch nog getest wordt inderdaad een stap overgeslagen worden in de kwaliteitstoetsing. Hierbij spelen diverse belangen mee.
Uiteraard dient de leverancier zelf te testen en dat kan die leverancier heel goed als heel helder is waar het product aan moet voldoen. Helaas weten veel opdrachtgevers niet goed SMART criteria op te stellen en zie daar, onder druk van tijd en geld wordt er dan opgeleverd zonder zelf goed getest te hebben. Spreek daarom een SLA af, waarin je per verwijtbare bug (een bug die men zelf had kunnen vinden met heldere criteria) een boete oplegt, of een korting op het product bedingt.
Om veel discussies te voorkomen over kwaliteit, is het overigens altijd verstandig om zoveel mogelijk met elkaar te communiceren en altijd te vragen naar de testaanpak en testrapportage van de leverancier.
Een leverancier kan zonder aantoonbare testaanpak wellicht beter overgeslagen worden in de selectieprocedure…
@Frank: Ik zie de testfase niet als een vervanging van het testen door de bouwers, maar als een extra kwaliteitsslag om de kwaliteit van het systeem voor de opdrachtgever aan te tonen. Niet om bouwers het werk uit handen te nemen.
De leverancier moet ook testen; het moge duidelijk zijn dat hier de acceptatiecriteria aan ten grondslag liggen. Het is de taak van de (ingehuurde) tester/testcoördinator deze boven water te krijgen. Acceptatiecriteria zijn essentieel voor het bepalen van strategie, dekking en technieken. Testen zonder acceptatiecriteria is als naar de slager gaan, maar eigenlijk niet weet wat je wilt kopen en dan maar besluit een biefstuk te kopen, met als risico dat je achteraf toch een varkenshaas had moeten hebben.
Om dan meteen met SLA’s, verwijtbare bugs en boetes te werken vind ik wat overdreven. Het doen van bevindingen calculeer je in. Maak gewoon goede afspraken, zorg ervoor dat elke partij weet waar hij aan toe is en wat zijn verantwoordelijkheden zijn en zorg ervoor dat je elkaar daar op kunt aanspreken zonder dat daar de relatie door beschadigd raakt. In die afspraken staat ook dat de leverancier rapporteert over hoe en wat er getest is; de testaanpak en –strategie.
Kortom: Investeer in een goede relatie, communiceer, maak iedereen bewust van de teststrategie, testaanpak. Zorg ervoor dat iedereen voor een goed resultaat gaat.
@Mark__: Ik zeg ook niet dat testen niet meer gedaan moet worden (ik snap dat je mijn zin zo kon interpreteren). Er treedt een mogelijk psychologisch verschijnsel op bij bouwers dat er nog een vangnet is dat testen heet en dat zij (de bouwers) mogelijk nog niet aan alle kwalitatieve eisen hoeven voldoen als de druk (lees tijd en geld) (te) hoog wordt. In praktijk zie ik vaak bouwers die weldegelijk goed willen testen, maar ook terug worden gefloten door projectmanagers, omdat er veel op tijd en geld wordt gestuurd. Dat zijn vaak korte termijn visies, want bugs treden altijd een keer op…
Mee eens dat een goede relatie cruciaal is, mijn voorstel over sla’s (lees afspraken) zijn een stok achter de deur bij notoire leveranciers.
Het is absoluut ongehoord als de IT-leverancier die een product bouwt het niet test alvorens het op te leveren. Hij is er voor verantwoordelijk dat het voldoet aan de afspraken en dat hij daarvoor zijn hand in het vuur kan steken (een klein lijstje met gevonden afwijkingen daargelaten).
De slager is verantwoordelijk voor de kwaliteit van het product dat hij levert, dus óók of het voldoet aan de warenwet. De overheid keurt het vlees, sommige slagers zullen dat een mooie uitvlucht vinden om zelf de kwaliteit niet te testen. Maar dat neemt niet weg dat ze zelf wel volledig verantwoordelijk zijn. Als een product wordt afgekeurd is het toch echt de slager (of de slachter) die moet boeten.
Dus de IT-leverancier zou er toch echt voor moeten boeten als hij niet goed geteste producten op de markt brengt.
De vergelijking met de slager vind ik wel leuk, maar waar is de keurslager onder de ICT-ers gebleven.
Het is leuk dat de groenteboer met zijn SLA als stok achter de deur kan fungeren, maar ik ben op zoek naar ICT-ers die vakmanschap en eigenaarschap ten toon spreiden, en gewoon goed werk leveren, net zoals de auteur op zoek is naar die kok die zijn eten wèl proeft alvorens hij het uitserveert.
Of zou diezelfde groenteboer een kok ook om zijn oren kunnen slaan met SLA (om maar in de culinaire synoniemen te blijven 😉 )
Misschien moeten we ook maar een michelingids voor software-producenten in gaan voeren?
Testen is meten en meten is weten. Geen regelen zonder meten. Is er geen behoefte de kwaliteit van de software te beheren, dan hoeft er ook niet getest te worden 😉 Na een gecertificeerde aflevertest die aan de eisen van de opdrachtgever voldoet kan een acceptatietest achterwege blijven.