Jag får ibland frågor via mejl om saker inom test. I mån av tid så svarar jag så utförligt jag kan. Det här kom senaste veckan och nedanför är mitt svar.
Jag varit med på några SAST-möten och får intryck att du är en man med bred kunskap inom test. (kommentar: smicker är alltid en bra start) Jag har en liten fråga som du säker har ngn typ av svar på, men om inte kanske du vet ngn som kan.
Jag får hela tiden påpekningar att test är för dyrt. Det kanske dels för att vi gjort det tydligt i budget där vi brutit ut test och CM som separata poster. Det jag är på jakt efter är egentligen vad är en normal fördelning mellan antalet utvecklare och testare (om det nu finns ngt som är normalt). Nu håller vi inte på med ngn programvara som kan vara fara för någons liv. Men det kanske finns ngn “Best practice” i förhållandet mellan Utvecklare/unit testare/produkt testera/system testare. Det vore toppen om du hade ngt svar, kanske några tips på konkreta fall, hur är relationerna på andra företag, som man kan jämföra med.
Svar: Svaret på din fråga är (som alltid) att det beror på.
De enklaste sätten (grövsta) är att använda nyckeltal. Exempelvis 2 utvecklare per testare. En kollega på ett stort försäkringsbolag säger att detta passar dem. En annan kollega i England har ett 1-1 förhållande och säger att det passar där. Så även om du använder nyckeltal så beror det på situationen hos ER.
De mest komplicerade(detaljerade) tror jag är test point analys (TMAP) och work breakdown structure. I dessa fall delar du upp allt som ska göras i små bitar och beräknar tiden för varje del. Detta kräver att resten av projektet har en väldigt strukturerad process. Detta funkar sällan då resten av projektet saknar denna detaljerade analys och då är du rökt.
Jag tror att ett rimligt sätt att uppskatta tiden för test är att använda sig av erfarenhetsdata från tidigare projekt och justera dessa för det aktuella projektet. Säg att ett liknade projekt hos er förra gången krävde 1 testare per två utvecklare för att fungera bra. Vad skiljer sig denna gång: teknik, resurser, kvalitetskrav, förutsättningar. Är det enklare krävs det kanske lite färre resurser och vice versa. Efter hand som ni får in mer erfarenhetsdata från fler projekt kommer era uppskattningar att bli bättre.
Erfarenheter jag haft från olika projekt:
1. Om kraven är usla/ogenomtänkta kommer testtiden att öka kraftigt då vi måste göra ett kravarbete parallellt och resultatet ändå bli sämre då det kommer att vara mycket ändringar sent i projektet.
2. Om projektet är svårstyrt kommer antalet fel att öka stort. Exempelvis en ostrukturerad PL eller fysiskt olika platser för deltagarna. Kaos och dålig kommunikation leder till ett krokigt spår med fler missförstånd.
3. Små projekt med få deltagare kräver ofta, men inte alltid, en mindre andel test då det blir färre utvecklare och mindre integration.
4. Nyutvecklingsprojekt kan kräva relativt färre antal testare än förvaltningsprojket. Förvaltning betyder ofta små ändringar på flera ställen och en stor andel regressionstester för att verifiera att oförändrade delar fungerar.
5. Omogen utvecklingsprocess eller omogna testare kan dubbla testtiden… Riktiga duktiga testare kan halvera testtiden! Tidig medverkan KAN leda till bra kvalitetssäkring tidigt och därmed färre ändringar sent och då kortare testtid. Effektiv testdesign har för mig gjort att kraven och specarna rensats på de värsta felen och systemtesten går som en dans.
Det finns en del artiklar på stickyminds.com