TPI vs. KPI

Test- en QA professionals zijn over het algemeen heel druk bezig om testprocessen – of breder – softwarevoortbrengingsprocessen te verbeteren. Hoewel deze activiteiten uiteindelijk waarde (moeten) toevoegen aan de business van de klant wordt de relatie daartussen vaak slechts impliciet verondersteld en zelden expliciet en meetbaar gemaakt.

Een bekende valkuil in de testwereld is het volledig opgaan in het eigen vakgebied. Veel testprofessionals proberen aan de klant uit te leggen in testjargon wat ze allemaal doen. De klant snapt dit vaak niet en zit hier ook helemaal niet op te wachten.

De klant heeft gewoon een of meerdere problemen die opgelost moeten worden.

Op zich is dit nog geen ramp ware het niet dat de testprofessional soms zelf niet snapt wat – en of –  hij/zij aantoonbaar iets toevoegt aan de waarde voor de klant – en dit ook niet vlot kan uitleggen.

Bij Identify wordt altijd eerst gekeken naar de behoefte van de klant en de pijnpunten die de klant ervaart. Wij gaan dus niet naar de klant met de TPI (Test Process Improvement) bijbel onder onze arm, maar we bekijken de situatie door de ogen van de klant. Welke zaken lopen er aan de klantkant en in productie niet lekker? Waar hebben service & support en sales last van? Welke kansen worden daardoor in de markt mogelijk gemist?

Onlangs bleek dat een klant voorafgaand aan iedere release enorm worstelde met de regressietest. Bedrijfskritische business processen waren niet beschreven en er lagen geen E2E testscenario’s. Hierdoor duurde het regressietesten telkens veel te lang en was men evengoed niet zeker over de dekkingsgraad van de test.

We hebben de inhoudelijk deskundigen vervolgens geholpen met het documenteren en overdraagbaar maken van regressietestscenario’s, waarmee een belangrijke bottleneck was opgelost.

Vervolgens hebben we samen met de klant een nieuwe lijst met prioriteiten opgesteld om aan te gaan pakken.

Wanneer eenmaal de pijnpunten en bottlenecks in kaart zijn gebracht, kunnen er KPI’s (Kwaliteits Prestatie Indicatoren) worden benoemd waar beter op gescoord moet gaan worden, zoals bijv. het aantal errors in productionele klantomgevingen, operationele performance van de software, of schaalbaarheid, flexibiliteit en aanpasbaarheid van het product.

Het grote voordeel van het eerst definiëren van KPI’s is, dat dit aansluit bij de beleving van de klant en expliciet maakt wat de klant moet gaan merken – in positieve zin uiteraard – van alle TPI inspanningen.

Eerst daarna benoemen we TPI aspecten die verbeterd moeten worden om er voor te zorgen dat de KPI scores omhoog gaan. Een bijkomend voordeel van deze ‘omgekeerde’ aanpak (eerst KPI en daarna TPI aspecten benoemen. i.p.v. andersom) is dat we de klant niet hoeven te vermoeien met alle details van de TPI-theorie. Dat valt onder ons vakgebied; de klant is geïnteresseerd in het resultaat, niet in de aanpak – daarvoor haalt hij juist externe expertise binnen.

De voortgangsrapportage wordt dus ook gerelateerd aan de KPI’s  en de voltooide deliverables.

Zo’n deliverable is bijv. een nieuwe testprocesbeschrijving c.q. werkwijze.

De rapportage geeft hiermee de voortgang aan in termen van toegevoegde waarde voor de klant waardoor geen vertaalslag meer nodig is naar de doelstellingen van de klant.

Een ander aspect in de dienstverlening waarmee Identify zich onderscheidt in de markt is het principe: ‘voordoen – samen doen – zelf doen’. Bij het implementeren van kwaliteitsverbeteringen bij de klant of van een andere werkwijze laten we eerst zien hoe dit aangepakt moet worden. Vervolgens laten we de klant niet zwemmen maar nemen we hem aan de hand om het samen te gaan doen. Pas wanneer de nieuwe werkwijze door de klant is omarmd en is ingesleten in de dagelijkse gang van zaken laten we de klant los. We weten dan dat e.e.a. is geborgd en dat men niet meer zal afglijden naar de oude praktijken. De consultant van Identify gaat pas weg als het resultaat bereikt is