Volgens Janssen is er geen testmethode die bij specifieke projecten precies vertelt wat je moet doen. 'Je hebt vaak weinig aan de bestaande methoden. Met gezond verstand bepaal je wat je wel en niet doet.' Test-M zou dat gezonde verstand op papier zetten, zegt de initiatiefnemer. 'De testmethode is een receptenboek, geen ingrediëntenboek. Je wordt bij de hand genomen.'
Door de nieuwe methode te gebruiken zouden testprojecten 30 tot 50 procent goedkoper kunnen uitvallen, beweert de dienstverlener. 'Dat doe je onder andere door een andere manier van organiseren. Bij andere methoden tuig je een enorme kerstboom op met testmanagers, testcoördinatoren, testspecialisten en testers. Daarmee creëer je, naast je bestaande projectorganisatie een nieuwe, dubbele organisatie.' Bij de methodiek van Janssen zijn er twee rollen, namelijk een testmanager en testers.
Eigen medewerkers
Daarnaast wil Janssen dat het testen zoveel mogelijk wordt uitgevoerd door medewerkers van het bedrijf. 'Dat is goedkoper, maar deze mensen hebben ook verstand van zaken. Het komt regelmatig voor dat de belangrijke dingen niet worden getest, omdat de tester niet echt verstand van zaken heeft', zegt hij.
Het bedrijf heeft nog geen klanten die werken met de nieuwe testmethode. 'Zodra de markt weer gaat aantrekken, verwachten we klanten te krijgen. We merken dat bedrijven nu niet investeren door de slechte economie.'
Reacties
Ik heb op het laatste TestNet event een presentatie bijgewoond over Test-M. Het idee voor een topic gerichte testaanpak spreekt me wel aan. De bestaande testmethodieken zijn generiek van aard waardoor de testprofessional zelf "het gerecht moet bereiden."
Mijn verwachtingen waren hoog gespannen waar het niet dat ik de uitvoering van Test-M niet echt vernieuwend vind. Zoals bijv. dat testen begint in het voortraject waar de requirements worden helder gemaakt, je een risico analyse uitvoert, je testen richt op de belangrijkste risico's. Dit zijn zaken die ISTQB/Testframe/TMAP Next ook beschrijven en best practices/templates voor aanreikt.
Begrijp overigens ook niet de opmerking "Bij andere methoden tuig je een enorme kerstboom op met testmanagers, testco?rdinatoren, testspecialisten en testers. Daarmee cre?er je, naast je bestaande projectorganisatie een nieuwe, dubbele organisatie."
Geen enkele testmethode verplicht je een overhead op te tuigen. Het zijn handleidingen die je kan volgen. Het is naar mijn mening de kennis en kunde van de testprofessionals die uiteindelijk bepalen hoeveel resources nodig zijn om de benodige testeffort uit te kunnen voeren.
ISTQB is geen methode maar een framework. Beetje jammer.
@anoniem: wat is precies het verschil?
@Jeroen: eens! Die kerstboom zie ik ook niet zo. Volgens mij zeggen alle testmethodes/frameworks/standaards/etc. dat je de procedures moet aanpassen aan de situatie waarin je ze toepast.
Ik zou graag 30 tot 50 percent van de testkosten verder willen besparen, maar ook alle andere aanpakken, frameworks beogen ook zo effecient en effectief mogelijk te testen. Dus een testprofessional die een der aanpakken, frames e.d. goed beheerst heeft juist geen recept nodig maar de juiste ingredienten waarvan hij/zij voor het specifieke project het juiste recept samensteld.
Klinkt als TMAP-Next in een nieuw jasje.
Test-M brengt hierbij niets nieuws ten opzichte van bijv. TMap (NEXT) of andere methodieken. Hierbij lijk Test-M zich voornamelijk te richten op het vooraf bepalen van de risico?s. Dit is niets anders dan risk-based testing. Vooraf is het altijd belangrijk om bijvoorbeeld documenten goed te controleren, denk maar aan Boehm.
De genoemde kerstboom hoeft ook volgens andere testmethodes niet gecre?erd te worden. Een testmanager en testers kunnen altijd volstaan, alleen ligt dat voornamelijk aan de grootte van het project. E?n testmanager en 25 testers zal de beheersbaarheid van het testtraject drukken. Het gebruik van eigen medewerkers door een bedrijf is evenmin vernieuwend. Bij het opzetten van een testtraject dient altijd te worden bepaald wie de testen gaan uitvoeren. Dat kunnen gebruikers zijn, testprofessionals (eigen of inhuur) of een mix ervan. Beide situaties hebben voor- en nadelen. Ingehuurde professionele testers zijn duur en hebben minder materiekennis. Gebruikers zijn dan wel goedkoop en hebben die materiekennis, maar zij zijn niet voor niets de gebruikers en zijn daardoor regelmatig niet beschikbaar omdat zij de core business van het bedrijf uitvoeren. Ook missen zij net die testkennis die soms nodig is om de juiste bevindingen te doen. Besparen op resources kan ook op andere manieren, bijvoorbeeld door gebruik te maken van crowdtesting (testen van applicaties middels crowdsourcing).
Wat doen we met maatwerk? Als ik de presentatie bekijk die via http://www.test-m.nl/index.php?option=com_docman&task=cat_view&gid=47&Itemid=50 te downloaden is lijkt het te richten op 3 pijlers. Pakketten, infrastructuur en uitbesteding.
Veel pakketten zijn in de praktijk nog steeds maatwerk, en infrastructuur is altijd maatwerk. Ben wel benieuwd naar het boek.
Ik ruik een verkoopverhaal. Er gebeurt niets nieuws, er is niets anders ingericht, ondanks de "kort door de bocht" oplossing, er zijn geen andere partijen bij betrokken, maar wel 30 tot 50 % besparing.
Hans Kazan is back!!!! And better than ever!
Inderdaad oude wijn in nieuwe zakken! Ben het eens met een aantal bovenstaande reacties over de kerstboom. Als dat het onderscheidende vermogen is van Test-M dan is het droevig.
De opmerking: "het bedrijf heeft nog geen klanten die met de nieuwe methode werken" zegt genoeg.
Waarom zouden bestaande testmethoden niet werken voor outsourcings- of infrastructuurprojecten of bij de implementatie van pakketten? Een goede tester/testmanager weet hoe hij de bestaande methodes moet toepassen in alle situaties. Met gezond verstand, ervaring en een bestaande methode kom je een heel eind.
Waarom moet ieder bedrijf dat in Nederland met testen bezig is, zo nodig een boek schrijven?
@Oude Wijn: de reden waarom testers boeken schrijven, heeft dezelfde grondslag als het verschijnsel dat een topic over testen onevenredig veel reacties krijgt ... (t.o.v. andere Development topics).
Ik denk dat er al genoeg testjargon aanwezig is en meer "bijbels" meer spraakverwarring bij klanten bezorgen. Klanten hebben al moeite om al die termen te begrijpen: Integratie test, functionele integratie test, ketentest, systeem integratie test. Wie weet het verschil cq overeenkomst nog??
Ik pleit voor algemene voorschriften en best pratices zoals ISO om samen met business en ict volgens een univerele testtaal te communiceren. Ik geloof dat ISTQB al een goede stap in de richting is.