Gisteren heb ik onderstaande vraag op het Testforum geplaatst, maar ik kan er natuurlijk ook op deze weblog aandacht aan besteden. Wie heeft hier praktijkervaring mee en zou er e.e.a. over kunnen vertellen?

Ik zou graag de volgende twee testorganisatiemodellen aan jullie voor willen leggen met daarbij de vraag of jullie binnen organisaties ervaring hebben opgedaan met het tweede model. Om het overzichtelijk en kort te houden laat ik allerlei randvoorwaarden en details weg, het is dus puur theoretisch en modelmatig.

Model 1: een project heeft een testmanager die het testproces opzet, de teststrategie bepaalt (met de stakeholders) en de aanpak vastlegt in een MTP. Daarnaast is er een systeemtestcoördinator die op basis van het MTP de detailaanpak voor de ST op zich neemt en hetzelfde geldt voor een acceptatietestcoördinator die dit voor de AT doet.

Model 2: een project kent dezelfde testmanager als uit model 1 en heeft daarnaast één testcoördinator die zowel de ST als de AT oppakt, de detailaanpak in één testplan beschrijft, zelf de overdracht van ST naar AT bewaakt/regelt en rapporteert aan de testmanager.

Mijn vragen t.a.v. model 2:

Is uit praktijkervaring gebleken dat dit model per saldo minder FTE kost? Met andere woorden, kan één testcoördinator prima de ST én de AT coördineren en ontstaat er ook een urenvoordeel (o.a. door minder plannen, minder communicatielijnen, meer verdieping in de materie, hogere kwaliteit van het eindproduct, et cetera).

Kan met dit model wel verzekerd worden dat de overdracht van ST naar AT "goed" verloopt, zeker als er sprake is van een gescheiden ontwikkelafdeling en gebruikersafdeling. M.a.w., hoe gaat één coördinator om met deze overdracht (wordt bijvoorbeeld de programmatuur na een kwalitatief magere ST doorgeschoven naar de AT, dan krijgt de coördinator de ellende op z’n eigen boterham, hoe kan omgegaan worden met bewijslast m.b.t. de inhoud en kwaliteit van de ST, et cetera).

Samenvattend: kan vanuit resourcemanagementoogpunt dus met model 2 uiteindelijk meer projecten worden bemand.

Technorati Tags: Testcoördinator, testmanager, ST, AT

Vorige maand alweer schreef Venkat Reddy Chintalapudi een post die sinds die tijd in mijn bookmarks staat om er hier nog even op door te gaan. Tester is not a Quality Police, zo luidt de titel van zijn betoog. De discussie over de raakvlakken van testen en kwaliteitscontrole is en blijft actueel in de testwereld en het leuke is dat er zoveel facetten aan kleven dat iedereen wel een beetje zijn of haar gelijk kan halen. Ik pak een paar uitspraken uit de post om er vervolgens een eigen ei over te leggen:

The perception from most of the management is that the Testers are the quality police for the products / projects that they develop… The attitude of acting like a Quality Police for testers is injected by the management from the beginning of their careers… The role of the Tester is to test software, find bugs, report them so that they can be fixed.

De redenatie van Venkat komt kort door de bocht op het volgende neer: wanneer een organisatie geen apart kwaliteitscontrole-team kent, legt het management deze bal bij de tester neer. Er wordt verwacht dat een tester niet alleen de software test, maar tegelijkertijd met een kwaliteitspet op te werk gaat. Hij gaat zelfs zo ver door te veronderstellen dat testers deze missie aan het begin van hun carrière opgelegd krijgen, terwijl daarentegen volgens hem alle betrokken teams verantwoordelijk zouden moeten zijn voor het kwaliteitsgehalte van het eindproduct.

Over die laatste conclusie zijn we het snel eens, maar voor wat betreft die opgedrongen QA-rol heb ik toch het gevoel dat hier wat ontbreekt in zijn verhaal. Ik heb namelijk niet het idee dat een tester die rol hoeft te worden opgelegd, die zou er eigenlijk al (van nature) moeten zijn. Hierbij interpreteer ik overigens het begrip Tester breed, ik versta er dus ook een testmanager of testcoördinator onder.

Waar ik naar toe wil is het zogenaamde donutmodel. Je kunt een donut verdelen in een binnenring en een buitenring. De binnenring kun je zien als het gebied waarop een tester grip heeft, denk daarbij bijvoorbeeld aan teststrategieën, testplannen, testgevallen en rapportages. De tester heeft dit (voor een groot deel) in eigen hand en kan er alles aan doen om deze producten kwalitatief op een hoog niveau te trekken.

Maar bij de buitenring van de donut ontstaat een probleem, helemaal wanneer het eerder genoemde kwaliteitsteam ontbreekt. Daar worden namelijk producten ontwikkeld, plannen bedacht en afspraken gemaakt waar een tester in eerste instantie veel minder grip op heeft. Denk bijvoorbeeld aan een projectopdracht, business requirements en functionele ontwerpen. Zaken die voor een tester echter van cruciaal belang zijn, het is de basis waarop de binnenring voortborduurt.

Het lijkt me daarom sterk (en dat mis ik in het verhaal van Venkat) dat het management die tester een duwtje in de rug moet geven. Dat zou toch onnodig moeten zijn. Die tester zoekt die buitenring echt zelf wel op door zich te bemoeien met de projectplanning, door met een testbril op requirements en ontwerpen te bestuderen en door te trekken aan die acceptatiecriteria. Natuurlijk zou een kwaliteitsteam een mooi steuntje in de rug zijn. Een team dat bijvoorbeeld kijkt naar de manier waarop processen verlopen, naar afgesproken reviewmomenten en naar de kwaliteit van de opgeleverde producten. Is dat team er echter niet, dan zul je in veel gevallen zien dat de tester zelf die pet op zet. Hoe beter de zaken in de buitenring worden geregeld, hoe eenvoudiger het proces in de binnenring verloopt. Dus laat dat duwtje nu maar achterwege, want een goede tester heeft die pet al default in de achterzak zitten.

Technorati Tags: kwaliteitspolitie, donutmodel, Quality Police, testers

Ik lees graag buitenlandse weblogs waarin wordt geschreven over software-ontwikkeling en testen. Enerzijds is het interessant te zien hoe sommige uitdagingen waar wij in Nederland mee stoeien ook in andere landen aan de orde van de dag zijn (bijvoorbeeld het succesvol managen én afronden van een project, opleveren wat de klant vraagt, de mate van testinspanning, et cetera). Maar anderzijds zijn het juist verschillen die me opvallen en waarvan ik probeer te achterhalen of ze me waardevolle input geven waar ik zelf weer iets mee kan.

Vandaag las ik een post op Steve Rowe’s Blog waarin hij ingaat op het carrièrepad van een tester. Wat me vooral opvalt aan zijn verhaal is het uitgangspunt dat een tester in veel gevallen een vervolg aan zijn of haar carrière wil geven richting software-ontwikkeling. In zijn post gaat hij vervolgens in op de hobbels die een tester tegenkomt om uiteindelijk dat doel te bereiken (benodigde opleidingen, gebrek aan tijd en vooral tegenwerking vanuit het management):

A lot of testers begin life as software test engineers.  That is, they execute tests but don’t do any (or much) programming.  The dream of many testers is to become a test developer or a developer.  Reciprocally, the dream of many test managers is to grow their testers into test developers.  Is this a realistic dream?  It can be, but probably isn’t in most cases.

Hoe ver zit ik er naast als ik vanuit mijn belevingswereld suggereer dat testers in Nederland veelal een carrièrepad richting project- of testmanagement ambiëren? Als we uitgaan van een ervaren tester of testanalist, zie je dan vervolgens in veel gevallen een switch richting software-ontwikkelaar? Ik betwijfel dat, maar kan het niet onderbouwen met statistieken. Als ik naar mijn eigen loopbaan kijk, is dit juist een tegengestelde beweging geweest; via ontwikkelaar en ontwerper aan de IT-kant naar de testcoördinatie en management aan de businesskant. Een beweging overigens die me veel voordelen heeft opgeleverd, omdat ik daardoor heb ervaren wat er aan beide kanten gebeurt en hoe er wordt gewerkt.

En jij? Ben jij een tester of testanalist en kun je je vinden in het betoog van Steve Rowe of liggen je ambities toch meer in een andere richting? Of ben je misschien werkzaam in de IT en heb je te maken met testers en hun groeipaden? Ik ben benieuwd naar jullie ervaringen op dit gebied.

Technorati Tags: tester, testanalist, Steve Rowe, test engineer

Een post op Developer Testing zet een aardig vraagstuk centraal: wat is de kleur van de testen die worden geschreven binnen het concept van Test-Driven Development (TDD). Een antwoord op die vraag is misschien wel onmogelijk en eigenlijk ook niet zo relevant, maar het is leuk om er even bij stil te staan en te analyseren waarom de eerste snelle reactie wit (White Box testen) in principe niet het goede antwoord is. Eerst even een korte toelichting.

TDD is een iteratieve en incrementele ontwikkelmethode waarbij de softwarecode pas wordt geschreven nadat er testen voor die code beschikbaar zijn. De testen zijn dus het uitgangspunt en de code die vervolgens in elkaar wordt gezet moet aantonen dat de testen succesvol zijn. Op deze manier groeit de testset mee met de software, is er sprake van een hoge testdekking en kan software in de meeste gevallen veel sneller worden aangepast. Dit is theorie, de praktijk is natuurlijk nog even een uitdaging, maar je ziet de interesse in en de toepassing van TDD steeds meer toenemen.

Nu terug naar de vraagstelling. In de testwereld zijn grofweg twee (eigenlijk drie) kleuren testen te onderscheiden. We kennen het White Box testen, dat zijn testen waarbij de interne werking van het testobject bekend is. Met andere woorden, de code staat centraal, de testen zijn gericht op de verschillende delen van de code, er worden paden doorlopen, et cetera. Bij Black Box testen daarentegen zijn de testen volledig onafhankelijk van de interne werking van de software. Uitgangspunt bij deze testen zou je heel simpel kunnen samenvatten als: wat stoppen we erin (invoer) en wat verwachten we dat eruit komt (uitvoer).

Bij TDD zijn de testen die als eerste worden ontwikkeld in principe gericht op de interne werking van het testobject, alleen de grap is dat er nog geen testobject is, dat is immers het principe van TDD. Je voelt het aankomen, dit wordt een beetje flauwe discussie. Achteraf gezien kun je het namelijk als White Box testen beschouwen, maar vooraf is dat dus eigenlijk onjuist. In de post waar ik naar verwijs wordt dit probleem onder meer handig opgelost door te veronderstellen dat we hier spreken over polished chrome, met als onderbouwing dat de testen weergeven hoe code zou moeten zijn, onafhankelijk van het feit of het ook daadwerkelijk zo is.

Ach, hoe cruciaal is het antwoord op deze vraag zo vlak voor Pasen. Mocht iemand nog een mooie kleur willen voorstellen, gooi hem in de comments en anders prettige dagen met mooie gekleurde eiëren.

Technorati Tags: TDD, White Box, Black Box, Test-Driven Development

Op de site van LogicaCMG is het nog even stil, maar Yahoo! Finance meldt wel vandaag de geboorte van Q-Talk, ofwel een requirements en risk based testaanpak gecombineerd met een QA-component. LogicaCMG rolt Q-Talk uit in samenwerking met Compuware:

Q-Talk will help IT departments effectively communicate the importance, business impact and return on investment of software testing to business unit customers. Additionally, Q-Talk will reduce time-to-delivery while mitigating project risk and increasing software quality.

Ik kan eerlijk gezegd niet helemaal meegaan met de onderbouwing zoals die in het persbericht wordt verwoord. Vrij vertaald: met deze "nieuwe" aanpak richt men zich met name op het definiëren en prioriteren van testrequirements. Met andere woorden, Q-Talk moet een brug slaan tussen de technische IT-er en de niet-technische business.

Ik vraag me dan af of het wel die technische IT-er moet zijn die met de business aan tafel gaat zitten om testrequirements in kaart te brengen. Is het wellicht een optie daar mensen op in te zetten die de taal van zowel IT als de business spreken? Het wordt een beetje gebracht alsof de tool hier de oplossing moet bieden, terwijl het proces om te komen tot een geprioriteerde set aan testrequirements m.i. in de eerste plaats mensenwerk is met tooling als ondersteunend hulpmiddel.

Verder ben ik het wel eens met de stelling dat de business (lees: de opdrachtgever) een voorkeur heeft voor inzicht in risico’s die met het testproces worden afgedekt en niet zit te wachten op een overzicht van de testgevallen die daarvoor nodig zijn. Daar komt dus de combinatie van requirements- en riskbased testen om de hoek kijken. Deze aanpak is overigens alles behalve nieuw in testland.

Zoals gezegd, het is nog vers van de pers, ik verwacht in de nabije toekomst wel het één en ander aan inzicht in de mogelijkheden die Q-Talk gaat bieden. Ongetwijfeld dat LogicaCMG en Compuware tijdens de komende seminars meer over dit product zullen laten zien.

Technorati Tags: Q-Talk, RRBT, LogicaCMG, Compuware

Trouwe lezers van deze weblog hebben inmiddels wel gemerkt dat ik zo af en toe met een testgerelateerde posting kom. Een bewuste keuze waarmee ik me terdege besef dat het blogtechnisch gezien geen handige is. Want ondanks de goede argumenten die voortkomen uit de je-bent-baas-over-je-eigen-weblog-discussie, is een aantal zeer uiteenlopende onderwerpen binnen een blog vaak verwarrend voor een lezer.

Desalniettemin vind ik het zo nu en dan leuk om over mijn vakgebied te schrijven. Maar ik merk tegelijkertijd dat er nauwelijks wordt gereageerd op dit soort  berichten. Dat kan ik voor een deel mezelf aanrekenen (te weinig diepgang, te weinig uitdagend en testen niet als duidelijke blogscope), maar het kan ook zijn dat de materie zich (nog) niet leent voor een weblog. Als ik namelijk naar mijn statistieken kijk, zie ik wel degelijk regelmatig bezoekers via een zoekmachine binnenkomen op trefwoorden als TMap, PAT of testtools. Met andere woorden, jullie zijn er wel maar hebben blijkbaar geen behoefte aan discussie (verkeerde conclusie?). Ook mijn oproep in december om hier te komen gastbloggen over testen leverde slechts een enkele reactie op.

Dus bij deze de vraag aan testers, testmanagers en andere vakgenoten, in hoeverre is er behoefte aan een Nederlandstalige testblog? Waar zijn jullie naar op zoek als je hier via Google op testgerelateerde zoekwoorden binnenkomt, wat verwacht je aan onderwerpen en diepgang? Daarnaast ook de vraag of testen zich meer leent voor een forum of dat het wel in blogform kan, daar dan dedicated, dus niet naast tal van andere onderwerpen. Zul je zien dat het opnieuw stil blijft, maar dan heb ik mijn best gedaan. De lezer is aan het woord, maar moet dan ook wel in de pen klimmen. En ten slotte, kritiek mag hoor, graag zelfs!

Technorati Tags: testen, testblog

IT Service Magazine refereert vandaag aan een persbericht van Compuware. Volgens dit bericht geven Europese IT-managers in meerderheid aan dat meer dan de helft van de ingebruiknames van nieuwe applicaties faalt. De nadruk wordt vooral gelegd op het feit dat bij implementatie van applicaties er onverwachte prestatieproblemen optreden.

Wat me opvalt aan het persbericht is dat het woord ‘testen’ precies nul keer wordt genoemd, laat staan dat er gesproken wordt over de Productie Acceptatie Test, in testjargon afgekort tot PAT. Als er ergens een moment in een ontwikkel- en testproces is waar je kunt achterhalen of er mogelijkerwijs prestatieproblemen kunnen treden, dan is het tijdens de PAT. Pikant detail is dat Compuware in de slotalinea aangeeft dat organisaties de verkeerde processen volgen en dat het opstellen van prestatieklassen niet als een essentiële stap binnen applicatieontwikkeling wordt beschouwd. Je kunt het echter ook omdraaien en je afvragen waartegen een applicatie dan beoordeeld wordt, als dat soort eisen hardnekkig blijft ontbreken. Is er dan niemand die zich bekommert om acceptatiecriteria?

Het blijkt maar weer eens hoe onderbelicht de inrichting en uitvoering van een PAT is binnen veel organisaties. Testtrajecten leggen in veel gevallen voornamelijk de nadruk op de functionele acceptatie van een applicatie. Maar na een vlekkeloos testtraject en een goed onderbouwd functioneel akkoord kan er nog van alles misgaan. Het opnemen van een Productie Acceptatie Test in je testaanpak kan een boel ellende voorkomen. Ik vraag me af hoe groot bovengenoemde prestatieproblemen zouden zijn als organisaties massaal tijdens de PAT de poort dicht zouden gooien. Zijn er geen prestatieklassen opgesteld? Zijn er geen afspraken vastgelegd in een SLA? Oké, dan hebben we geen testbasis, wordt er dus niet getest en komt er dus ook geen groen licht voor implementatie. Beheerafdelingen zouden deze aanpak alleen maar toejuichen, zij zijn immers degenen die als eerste met de productieproblemen worden geconfronteerd. Werk aan de winkel dus.

Technorati Tags: PAT, Productie Acceptatie Test

Eind vorige maand besteedde het Java Developers Journal aandacht aan een onderzoek van Gartner en Forrester Research waaruit bleek dat veel ontwikkelde .NET applicaties in productie onderuit gaan. Als belangrijkste oorzaak wordt het gebrek aan (performance-)testtooling genoemd waardoor .NET-ontwikkelaars vooralsnog onvoldoende middelen hebben om een goed testtraject uit te voeren.

Toevallig, of misschien ook wel weer logisch, om dit soort geluiden uit het Java-kamp te horen, de grote tegenhanger van .NET. De cijfers liegen er in ieder geval niet om: 71% van de problemen met .NET applicaties wordt niet gevonden gedurende een testtraject maar pas in productie. Excuse me!

In other words, despite all the effort and expense to assure application quality, actual users are still being used as QA and optimization tools.

By spanning multiple components inside and outside the data center, the complexity of .NET Web applications has diminished the efficacy of existing lab-oriented simulation or load-testing tools in predicting and monitoring application performance. For example, your development environment probably has a totally different configuration and load from your production infrastructure. Furthermore, the increasing trend toward virtualization and shared infrastructure means that an application that runs well in isolation in the lab could be sluggish “in the wild.” As a result, actionable information like the call tree shown above is needed to efficiently complete a .NET development project.

Ik kan nog wel meer opvallende uitspraken en conclusies uit het artikel citeren, maar interessanter is het om zelf het hele verhaal even te lezen. In ieder geval wordt uit de cijfers duidelijk dat de grote toename van .NET projecten en ontwikkelteams nog niet gepaard gaat met de ontwikkeling van specifieke testtools die in deze omgeving kunnen worden ingezet. Werk aan de winkel voor de ontwikkelaars van testtooling zou ik zeggen.

Technorati Tags: .NET, testtooling

Ik krijg geregeld vragen over de inhoud van het nieuwe boek TMap Next dat in december van dit jaar zal worden gepubliceerd. Enkele collega’s en vakgenoten zijn nauw betrokken geweest bij de totstandkoming van het boek. Uiteraard zijn ze gehouden aan de afspraken die rondom het vrijgeven van informatie zijn gemaakt. Het is dus nog even geduld hebben tot begin december.

Op Internet wordt echter wel hier en daar een tipje van de sluier opgelicht. Zo is op de TMap-site van Sogeti al onthuld dat het zogenaamde essentiemodel centraal zal staan in TMap Next. Dit model staat voor de volgende vier essenties, zo valt te lezen in het persbericht:

• Gebaseerd op een Business Driven Test Management aanpak (BDTM);
• Geeft een volledige beschrijving van het totale testproces;
• Er is sprake van een complete gereedschapskist met betrekking tot technieken, infrastructuur en organisatie;
• Een adaptieve methode en daardoor toepasbaar in de meeste ontwikkelomgevingen.

Met het centraal positioneren van deze essenties zal het bekende “TIFO-model” (Technieken, Infrastructuur, Fasering en Organisatie) naar ik aanneem niet meer worden gebruikt. Dat valt ook al min of meer af te leiden uit het feit dat de meeste componenten van dit model terugkomen in de gereedschapskist (essentie 3).

Ook geeft het persbericht globale informatie over de indeling van het boek. Zo zal er sprake zijn van een algemeen deel (introductie testen en TMap), worden de processen beschreven (zoals mastertestplanning, acceptatietesten, et cetera) en zullen verschillende componenten worden besproken (o.a. productrisicoanalyse en begrotingstechnieken).

Technorati Tags: TMap Next, essentiemodel

Een leuk artikel op Yahoo! News - Macworld. Onder de kop “Could a 30-in. monitor help you do your job faster?“, buigt een aantal experts zich over de testresultaten van een onderzoek naar productiviteit in relatie tot de grootte van een scherm waarachter wordt gewerkt. In dit rapport wordt verslag gedaan van een aantal productiviteitstesten met een 30-inch Apple Cinema HD Display.

The study, which evaluated Apple’s 30-inch Apple Cinema Display, concluded that large screens can offer gains of up to 50 percent to 65 percent in productivity on a variety of specific office tasks and can earn back their extra costs in time savings over several years. The 30-in. display costs $1,999.

But other experts say those conclusions are wrong, arguing that the productivity improvement estimates are too high and that using two monitors side by side would likely be a better productivity booster than one larger monitor.

Ik heb zelf het idee dat e.e.a. afhankelijk is van het soort werk dat je op het scherm verricht. Als ik veel documenten tegelijk open wil hebben, lijkt me één groot scherm ideaal, zeker als er het nodige geknipt en geplakt moet worden. Maar doe ik twee totaal verschillende dingen, bijvoorbeeld een document schrijven en op Internet surfen, dan lijken me twee monitoren naast elkaar (van een “normaal” formaat) net zo practisch. Maar ik geef toe, zo’n 30-inch Apple speeltje op mijn bureau lijkt me niet verkeerd. Ik zal morgen eens een businesscase schrijven, kijken of het wat gaat opleveren.

Technorati Tags: productiviteit, schermgrootte