Test Outsourcing Een introductie Algemene informatie voor medewerkers van: SYSQA B.V.
Organisatie SYSQA B.V. Pagina 2 van 11 Inhoudsopgave 1 Samenvatting... 3 2 Inleiding... 4 2.1 Algemeen...4 3 Argumenten voor test outsourcing... 5 4 Risico s van test outsourcing... 6 5 Geschiktheid van testsoorten voor outsourcing... 8 6 Stappen en aandachtspunten... 9 7 Bronnen... 11 Versiebeheer Versie Datum Opmerkingen Auteur 0.3 6-9-2007 0.4 21-9-2007 0.5 24-9-2007 1.0 26-9-2007
Organisatie SYSQA B.V. Pagina 3 van 11 1 Samenvatting Dit document bevat een kort overzicht van motieven voor wel of niet outsourcen van testen. Daarnaast is ingegaan op welke testsoorten zich lenen voor outsourcing. Het document is gebaseerd op diverse publicaties over test outsourcing en biedt daarmee een neutraal beeld. Outsourcing van testen biedt kansen maar levert ook risico s op. Kansen en risico s verschillen per organisatie. Outsourcing biedt kansen zoals kostenbesparing en hogere kwaliteit van het testwerk doordat het door specialisten wordt uitgevoerd. Het levert risico s op zoals het verwijderen van de last wall of defence en het (gedeeltelijk) verdwijnen van diepgaande applicatiekennis binnen de organisatie. Van de testsoorten die worden onderkend zijn vooral de systeemtest en de functionele acceptatietest geschikt om te worden uitbesteed. De programmatest / unittest is meestal onlosmakelijk met ontwikkelen van software verbonden. De gebruikersacceptatietest en productieacceptatietest is minder geschikt voor uitbesteding. Voor deze testsoorten geldt dat er veel inhoudelijke kennis van het bedrijfsproces of van het productieplatform en beheerproces noodzakelijk is. Succesvolle outsourcing vereist het gestructureerd doorlopen van een aantal stappen. Het hanteren van checklists en daarmee gebruik maken van ervaring van andere outsourcingstrajecten voorkomt dat potentiële valkuilen over het hoofd worden gezien. Het doel en de scope moeten bepaald worden evenals de voorwaarden waaraan het te outsourcen platform moet voldoen. Vervolgens moet er een leverancierskeuze plaatsvinden om daarna een generiek master testplan op te stellen. Hierin moeten werkwijzen en KPI s worden vastgelegd, evenals communicatielijnen.
Organisatie SYSQA B.V. Pagina 4 van 11 2 Inleiding 2.1 Algemeen Dit document heeft tot doel een beknopt en neutraal beeld te schetsen van de meest recente inzichten op het gebied van test outsourcing. Het document kan projectmanagers, testmanagers en lijnmanagement behulpzaam zijn bij beeldvorming rondom testoutsourcing binnen een organisatie. Daarnaast bevat dit document hints om specifieke kansen, risico s en beheersmaatregelen voor individuele projecten of organisaties snel te kunnen identificeren. Het document is opgesteld op basis van een literatuurstudie van publicaties met betrekking tot test outsourcing. Een overzicht van gebruikte publicaties is opgenomen in hoofdstuk 7 Bronnen. In de tekst is daar waar van toepassing de betreffende bron tussen haakjes vermeld. Dit document is geen uitgebreid receptenboek om vervolgens tot gestructureerde uitbesteding van testen te komen. Hiervoor wordt verwezen naar specifieke literatuur en ervaringen bijvoorbeeld met inrichting van regiebureaus (zie kennisbank). Achtereenvolgens wordt er stilgestaan bij: Argumenten voor outsourcing van test; Risico s van outsourcing van test; Geschiktheid van testsoorten voor outsourcing; De stappen en aandachtspunten om tot test outsourcing te komen. Er worden verschillende vormen outsourcing onderkend: Near shoring: outsourcing naar een partij binnen Nederland, naar een partij dicht over de grens, bijvoorbeeld binnen Europa; Off Shoring: outsourcing naar een partij ver weg, bijvoorbeeld naar India. In dit document wordt geen verder geen onderscheid gemaakt in deze verschillende vormen van test outsourcing.
Organisatie SYSQA B.V. Pagina 5 van 11 3 Argumenten voor test outsourcing Om tot test outsourcing over te gaan worden de volgende redenen genoemd: 1. Kostenbesparing (1,4,6, 13). Lonen off shore en near shore liggen lager dan de lonen hier. Ook kan het zijn dat een gespecialiseerde organisatie efficiënter en daarmee goedkoper werkt. Lagere kosten kunnen ook voortkomen uit schaalgrootte van de leverancier; 2. Afvlakken pieken in werkbelasting testers (6). Aanbod van testwerk is niet gelijkmatig over het gehele jaar verdeeld, hierdoor zitten de eigen testers duimen te draaien om korte tijd later zich de benen onder het lijf vandaan te rennen. Als de externe partij voldoende schaalgrootte heeft, kunnen deze fluctuaties door hen eenvoudig opgevangen worden; 3. Toegang tot kwalitatief hoogwaardige expertise (6, 9, 13). Testen is een vak apart dat door specialisten effectiever en efficiënter wordt uitgevoerd. Het bedrijf wil zich meer op zijn kerncompetenties richten. De motivatie voor de langere termijn is niet de kostenbesparing maar de grotere toegevoegde waarde van deelopdrachten die uitbesteed worden aan testspecialisten. De testleverancier heeft meerdere klanten met soortgelijke problemen en zal hiervoor een betere oplossing kunnen aanbieden terwijl de opdrachtgever veel meer moeite zal hebben om zijn kennis up-to-date te houden. Daarnaast zal een specialist eerder met innovatieve oplossingen komen die een grotere toegevoegde waarde kunnen bieden dan de oplossingen die de opdrachtgever zelf kan genereren; 4. Toegang tot gekwalificeerd personeel (1). In de krapper wordende arbeidsmarkt wordt het steeds moeilijker om gekwalificeerd personeel te vinden. Daarnaast geldt dat ook medewerkers zélf vaker kiezen voor specialisatie om toegang te krijgen en deel te gaan uitmaken van hoogwaardige expertise; 5. Vaste kosten omvormen tot variabele kosten (9). Vaste (personeels) kosten worden vervangen door variabele kosten. Op het moment dat bepaald werk niet meer uitgevoerd hoeft te worden kan het werk zonder personele problemen bij opdrachtgever gestopt worden; 6. Kostenbeheersing (9). De kosten van een externe leverancier zijn beter beheersbaar. Van te voren is een werkpakket afgesproken binnen een contract. Voor meerwerk moet een nieuw contract afgesloten worden. Dit is een gevaarlijk argument want daarmee geeft een bedrijf eigenlijk aan dat zij haar interne proces van kostenbeheersing niet goed op orde heeft; 7. Onafhankelijkheid van testen (9). Een onafhankelijke partij stelt vast of de software aan de kwaliteitseisen voldoet. Als een derde vaststelt of de beide partijen zich aan de spelregels op specificeren en bouwen van software hebben gehouden, geeft dat minder discussie. De testende partij wil het opgelost hebben, of door de software of door de specificaties aan te laten passen. Overigens kan dit in de praktijk soms voor de testende partij een drijfveer zijn tot het uitvergroten van issues om daarmee hun bestaansrecht aan te tonen. Het meedenken in een project van de testorganisatie om tot het gewenste projectresultaat te komen is dan verleden tijd.
Organisatie SYSQA B.V. Pagina 6 van 11 4 Risico s van test outsourcing Als risico s bij het outsourcen van test worden de volgende punten genoemd: 1. Verwijderen van last wall of defence (6, 8, 9). Uitbesteden van testen kan leiden tot slechtere software op productie indien verder geen kwaliteitscontrole meer plaatsvindt (6,9). Testen is het laatste middel om risico s van onvoldoende kwaliteit en daarmee bedrijfsrisico s te reduceren (8). 2. Onvoldoende beheerst uitbestedingsproces (10). Outsourcing vergt veel van de uitbestedende partij en vereist een hoge mate van professionaliteit om zelf regie te houden op het uitbestede werk. Interne testexpertise is vereist om een volwaardige gesprekpartner van de leverancier te zijn. 3. Onvoldoende beheerst ontwikkelproces (2, 6, 13). Het gehele ontwikkeltraject en regieproces van de uitbestedende organisatie is nog onvoldoende volwassen. De processen voor en na het testen in het ontwikkeltraject zullen volwassen moeten zijn. Dit betekent dat ze zeer betrouwbaar en stabiel (planbaar) moeten functioneren. Is dit niet het geval, dan kunnen de afstemmingskosten behoorlijk stijgen. Ook vormt het ontbreken van heldere afspraken over op te leveren documentatie in het ontwikkelproces en concrete toetsbare kwaliteitscriteria voor deze documenten vaak een struikelblok. 4. Geen aansluitend Testproces en Ontwikkelproces (7). Testproces komt niet overeen met de ontwikkelmethodiek. Fouten komen later aan het licht doordat bij outsourcing vaak een sequentiële ontwikkelmethode, zoals de watervalmethode, wordt toegepast. Test vroegtijdig inschakelen in het ontwikkeltraject is lastiger. 5. Afnemend hergebruik van testgevallen (6). Een zelf uitgevoerde test levert voor de organisatie herbruikbare testgevallen op. Dit risico kan deels ondervangen door vooraf met de testorganisatie een percentage hergebruik van testgevallen af te spreken. Daarmee wordt de testorganisatie in feite gedwongen tot hergebruik, wil het tot rendabele testtrajecten komen. In de praktijk blijkt de herbruikbaarheid van door een derde organisatie opgestelde testware niet altijd even goed te zijn. 6. Vendor Lock-in (4). De wijze van uitbesteden kan er toe leiden dat deze leverancier als enige kennis in huis houdt over het systeem waarmee eventuele insourcing of overdracht naar een andere derde partij in de toekomst niet meer mogelijk is. Gebruik van specifieke (niet-standaard) methoden of technieken, leveranciers-gebonden tools voor onderhoud en het uitblijven van herhaalbare tests en documentatie zijn factoren die de kans op vendor lock-in vergroten. 7. Tijdelijkheid van het kostenvoordeel (5). Het kostenvoordeel is tijdelijk en niet blijvend. Off shore players blijven namelijk geen off shore players: a. Ze willen taken en processen gaan uitvoeren die niet op afstand kunnen en nu worden uitbesteed aan lokale spelers. b. Door salarisdruk zal het prijsverschil afnemen naar geen verschil, zeker nu off shoren een hype is. 8. Taalbarrière (1). De software heeft te veel taalafhankelijke kenmerken die ook getest moeten worden (invoerschermen bijvoorbeeld) dat dit niet zonder grondige kennis van de Nederlandse taal kan worden uitgevoerd. 9. Koppeling met andere systemen (9). Het uit te besteden (deel)systeem heeft zoveel koppelingen met andere systemen en partijen dat dit het uitbesteden bemoeilijkt. 10. Inzicht in kwaliteitsverbeteringen vervalt (10,11,13). Testen leveren verbeterinformatie op. Kwaliteitsmanagement in projecten en testen ligt in het verlengde van elkaar. Testen leveren naast informatie over productkwaliteit ook informatie over proceskwaliteit. Input vanuit testafdelingen vormt dikwijls triggers
Organisatie SYSQA B.V. Pagina 7 van 11 binnen organisaties om tekortkomingen in het gehele ontwikkelproces aan te pakken en daarmee fouten te voorkomen en écht besparingen te realiseren. Dit risico kan deels worden ondervangen door als uitbestedende organisatie dergelijke informatie in rapportages van de leverancier te verlangen; 11. Minder flexibel. Als het in-huis getest wordt kan er meestal van alles tussendoor of ongepland plaatsvinden of er kunnen vele scope wijzigingen plaatsvinden. Om dit op te vangen en met name om inzicht te houden in de (financiële) verantwoordelijkheid tussen opdrachtgever en opdrachtnemer neemt de bureaucratie toe. De toename is afhankelijk van de volwassenheid van het testproces, maar ook van het ontwikkelproces. Bij volwassen processen zal de toename van bureaucratie gering zijn, in tegenstelling tot een onvolwassen proces.
Organisatie SYSQA B.V. Pagina 8 van 11 5 Geschiktheid van testsoorten voor outsourcing Niet iedere testsoort leent zich om uitbesteed te worden. In grote lijnen worden de volgende testsoorten onderscheiden: 1. Programmatest 2. Integratie- en systeemtest 3. Acceptatietest 4. Regressietest De programmatest wordt ook wel unittest genoemd. De programmatest wordt overwegend door de softwarebouwer uitgevoerd, omdat deze meestal onlosmakelijk met de realisatie van de software verbonden is. Deze test leent zich niet om los uitbesteed te worden. De systeemtest wordt meestal uitgevoerd met veel kennis over testen en minder kennis over het bedrijfsproces. De acceptatietest kan in 3 testsoorten uiteenvallen: 1. Functionele acceptatietest. Deze testsoort heeft tot doel aan te tonen of de software gebouwd is conform de specificatie of de gespecificeerde eisen. Hiervoor is uitgebreide kennis van het systeemspecificaties noodzakelijk. Deze staan in de ontwerpen verwoord. 2. Gebruikers acceptatietest. Doel hiervan is de Fit for use te bepalen. Anders gezegd: Kan ik met de applicatie in deze vorm in de praktijk mijn werk doen. Hiervoor is kennis van het operationele bedrijfsproces en eventuele aanpassingen in de bedrijfsprocessen noodzakelijk. 3. Productie acceptatietest. De beheerbaarheid en stabiliteit van de applicatie of het systeem worden tijdens deze test bepaald. Hiervoor is kennis van het productiesysteem en haar beheerwijze noodzakelijk. Daarnaast is een testomgeving noodzakelijk die representatief voor de productieomgeving. Een testsoort die vaak onderdeel is van de systeemtest en/of de acceptatietest is de regressietest. Deze test moet aantonen dat de bestaande, niet aangepaste functionaliteit van de software nog steeds conform de specificaties blijft functioneren. Uit het bovenstaande blijkt dat vooral de systeemtest geschikt is om voor uitbesteding in aanmerking te komen, evenals de functionele acceptatietest (1,6). Zeker als het aandeel regressietest relatief hoog is ten opzichte van de progressie. Overigens leent de regressietest zich over het algemeen goed voor geautomatiseerd testen. Innovatie van de ontwikkeling van software vraagt een steeds verdere integratie van ontwikkeling en test (2). Bijvoorbeeld de testgedreven aanpak leent zich minder voor uitbesteding van testsoorten vanwege de sterkere verwevenheid van het ontwikkelproces met het testproces (7). Waar de markt al jaren geleden is overgestapt naar meer iteratieve en dynamische processen - omwille van wendbaarheid - lijkt men bij uitbesteding weer terug te grijpen op de strikte watervalmethodes. Voor kleine aanpassingen en onderhoud kan dit goed werken, maar voor de ontwikkeling van geheel nieuwe software leent deze werkwijze zich minder. Goede afspraken en regie kunnen iteratieve processen en flexibele applicaties ook bij uitbesteding mogelijk maken (4).
Organisatie SYSQA B.V. Pagina 9 van 11 6 Stappen en aandachtspunten Om tot test outsourcing te komen moeten een aantal stappen worden doorlopen. Eerst zal er stilgestaan moeten worden bij het doel, de scope, keuze van de leverancier, de SLA (Service Level Agrement) en/of een GMTP (Generiek Master Test Plan) voordat er tot implementatie en daarmee tot daadwerkelijke uitvoering van test outsourcing kan komen. De doelstelling(en) voor het uitbesteden moeten eerst duidelijk worden. Pas daarna kan zinvol worden overwogen welke testactiviteiten voor uitbesteding in aanmerking komen. Om het welgeslagen van het uitbesteden te kunnen meten moeten kwantitatieve doelen worden gedefinieerd (2,4). Het bepalen van de precieze scope bij het uitbesteden van testen is uitermate belangrijk. Van belang is welke afspraken er over het testen worden gemaakt. Hiervoor is tijdige inbreng van onafhankelijke testexpertise noodzakelijk. Binnen het testproces zelf kan een selectie worden gemaakt van de testsoorten die worden uitbesteed en de testvormen die worden uitbesteed. Het is raadzaam zo vroeg mogelijk alle voor uitbesteding in aanmerking komende testactiviteiten in kaart te brengen (2,9). Gekeken moet worden naar de mogelijkheid om ze uit te besteden maar ook naar de kosten en de baten hiervan. Er zal dus een make or buy beslissing genomen moeten worden. De eerste vraag die beantwoord moet worden, is of een testsoort uit te besteden valt en bij een positief antwoord vervolgens of het bedrijfseconomisch gezien zinvol is om het uit te besteden. Hierbij moet niet alleen naar de korte termijn gekeken worden: wat op de korte termijn verlies inhoud kan op de langere termijn tot enorme besparingen leiden. Bij de keuze van de leverancier is het belangrijk te letten op zijn testexpertise en kennis van het product of de materie (2). Ook dient te worden voorkomen dat door de wijze van uitbesteden deze leverancier als enige kennis in huis houdt over het systeem, of dat er nietstandaard methoden, technieken of tooling worden toegepast (vendor lock-in) (4). Het implementatieproces vraagt tijd, resources, budget en goede communicatie (1,2). Daarnaast zijn de volgende punten van belang voor de implementatie: 1. Goede communicatie, goede afspraken en nauwgezette monitoring (1,2). 2. Strakke sturing door opdrachtgever door goed ingerichte onshore coördinatie (1). 3. Afgestemde producten (om de status te monitoren zoals voortgangsrapportages, testplannen, testscripts) (1,6,8). Hierbij moet ook stil gestaan worden bij de gebruikte projectmanagement methode en de daarvoor vereiste (tussen) producten (12). 4. een acceptatietest van de goedgekeurde software uitvoeren (1). Dit geldt zeker bij de eerste uitbestedingsprojecten, maar ook daarna. 5. Uitgebreide intake van de uitgangsdocumentatie zoals testscripts, testplannen etc. (om de gewenste kwaliteit te waarborgen) (1,8). 6. Goede entry- en exitcriteria voor het testproces afspreken (1,6). 7. Goed vertaalproces en bijbehorende reviewprocedure (1,3). 8. Dedicated contactpersonen, duidelijke en tijdige afhandeling van vragen en bijhouden van een vragenlog (1). 9. Kiezen voor een gezamenlijke testmethodiek en voor één terminologielijst (1). 10. Zorgvuldig het moment kiezen waarop de testware wordt overgedragen door de leverancier (1). 11. Kennisborging van het betreffende systeem binnen de uitbestedende organisatie zodat eventueel in de toekomst insourcing kan plaatsvinden 12. Goede KPI s afspreken zoals (9): o Aantal wijzigingsverzoeken tijdens het testproces.
Organisatie SYSQA B.V. Pagina 10 van 11 o Aantal fouten in de testspecificatie. o Aantal fouten in de functionele test. Hoeveel fouten mogen er gevonden worden tijdens de test van welke zwaarte voordat er sprake is van meer werk. Maar ook hoeveel fouten van welke zwaarte mogen er na de test nog gevonden worden en wat consequenties heeft dat dan voor de leverancier? o Efficiëntie van de foutoplossing. o Testvoortgang. o Geplande en gerealiseerde testduur per testobject. o Aantal hertets per testobject. o Behaalde dekkingsgraad. Denk daarbij ook aan de wijze waarop de KPI s gemeten worden (meetvoorschrift) en aan welke grenswaarden moet worden voldaan (norm). Maak duidelijke afspraken over consequenties bij overschrijden van de grenswaarden voor zowel opdrachtgever als opdrachtnemer. 13. Afspraken maken over te hanteren standaarden voor testen (8) o Worden de testen gebaseerd op IEEE, Tmap, ISTQB?. 14. Kwaliteitsattributen. Welke kwaliteitsattributen worden door de leverancier getest? (8). 15. Toegang tot en werkwijze binnen de Bevindingenadministratie (1,8). o Kunnen zowel de opdrachtgever als de leverancier bij de bevindingentool? o Hoe gaan opdrachtgever en leverancier om met meningsverschillen over een bevinding die de leverancier van de software niet wil oplossen? 16. Inrichting van regievoering over het uitbestede testwerk. Gedacht kan worden aan intake van de testopdracht, kwaliteitsborging van de systeemontwikkeling (10). 17. Functie van regisseur. De testmanager stuurt geen testteam meer aan maar een leverancier. De sturing gebeurt nu op basis van rapportages van de leverancier, gesprekken met de leverancier en de interpretatie van deze rapportages en gesprekken en niet meer door direct met de tester te overleggen. 18. Inrichting van de testorganisatie. o Hoe verloopt de procedurele reguliere communicatie? o Hoe verloopt de aansturing? o Langs welke procedurele weg vinden escalaties plaats? 19. Testoutsoursing laten aansluiten op de gebruikte projectmanagement methodiek (8,10). Veel van bovenstaande punten kunnen worden vastgelegd in het Generieke Master Testplan (GMTP) of een soortgelijk document (8). Voor het inrichten en bepalen van het proces, de procedures en acceptatiecriteria moet zoveel mogelijk aangesloten worden bij de bestaande werkwijze binnen de organisatie. Afhankelijk van de invloed die de opdrachtgever wil hebben op het testproces kunnen bepaalde werkwijzen, templates, rapportages en kwaliteitseisen aan testers worden voorgeschreven. Wat is voorgeschreven moet wel controleerbaar zijn. Het heeft geen zin om kwaliteitseisen aan de testers voor te schrijven als je niet in staat of bij voorbaat niet van plan bent bent dit te controleren, desnoods in India.
Organisatie SYSQA B.V. Pagina 11 van 11 7 Bronnen 1 Offshoring van testopdrachten een reëel alternatief? Door Chris Boulton en Andre Weber. Informatie november 2006. 2 De route naar succesvol uitbesteden van testen. Test Outsourcings Governace Approach. Door Martin Pol. Informatie juli / augustus 2006. 3 Testoutsourcing in de praktijk. Ervaringen bij ABN Amro. Door Huco de Vos en Lies Malipaard. Informatie juli / augustus 2006. 4 Kosten uitbesteding applicaties moeilijk vooraf in te schatten. Door Alex van den Bergh en Wijnand Kamerling. Automatiseringsgids nr 06, 2007. 5 Offshore-partijen blijven niet off shore. Leslie Willcocks. Automatiseringsgids nr 01, 2007. 6 Uitbesteden van testen is een riskante zaak. Door Jan Jaap Cannegieter. Automatiseringsgids 10 december 2004. 7 Testgedreven project uitvoering. Door Jan Jaap Cannegieter en Cornell Heutink. Informatie juli/augustus 2006. 8 Tmap Testtopics. Door Tim Koomen en Rob Baarda. Uitgeverij Tutein Nolthenius 2004. 9 Outsourcing der Software-Entwicklung. Risiken erkennen Risiken minimeren. Anonymus. Software Quality Systems, juli 2005. 10 Regiebureau. Olaf Achterbosch en Jan Jaap Cannegieter. Informatie mei 2007. 11 Kwaliteitszorg in ICT projecten, de PROQA methode. Jan Jaap Cannegieter. Ten Hagen Stam uitgevers, 2001. 12 Managing Succesful Projects with PRINCE2. Office of Government Commerce. Eleventh Impression 2004. 13 ICT-Strategie en organisatie. Prof. Drs. J.A. Oosterhaven, Academic Service. 2e herziene druk 2007.