Insikter om ISTQB

Det går en skiljelinje idag mellan de testare som förespråkar traditionell testning och de som föredrar kontextdriven testning. Mitt i skottlinjen ligger ISTQB-certifikaten, som många av oss testare har och många organisationer efterfrågar. ISTQB-certifikaten har blivit en de-facto standard för testarbetet men det förenklade och smula dogmatiska innehållet gör att det ifrågasätts, främst av den kontextdrivna skolan. Eftersom det var ganska länge sen som jag tog min certifiering så satte jag mig ner för att fräscha upp minnet om vad ISQTB-syllabus verkligen innehåller.

Jag håller med om att ISTQB är skriven med ett genomgående självsäkert tonfall som får innehållet av verka mer vedertaget än vad som är fallet. Det är en teoretisering av samma typ man lär sig i skolan innan man förstår att den verkliga världen är mer komplex än vad lektionerna ger utrymme för. Det som jag tycker är mest graverande är dock tyngdpunkten vid traditionell testning och obskyra standarder. Många testare är påväg ifrån sådana begränsningar och om ISTQB ska vara relevant så borde man lämna utrymme även för kontextdrivna förhållningssätt.

Lite fler tveksamheter följer här:

• ISTQB gör ett stor nummer av skillnaden mellan "error", "defect", "fault", "failure" och "bug". Jag har aldrig förstått varför alla dessa distinktioner och nöjer mig med Rob Sabourins definition "To make our job more fun, whenever we have a concern with software, we call it a "bug".
• Att dela upp testarbetet i fem olika faser, varav en innehåller faktiskt testgenomförande till hälften, är inte bara vattenfall utan nedgradering av testarens viktigaste arbetsuppgift till förmån för administration. ISTQB's testprocess definieras såsom (planning and control, analysis and design, implementation and execution, evaluating exit criteria and reporting, test closure activities.
• ISTQB menar att oberoende leder till bättre tester. Jag tror att ett gemensamt ansvar för leverans och kvalité med testare som jobbar nära utvecklarna leder till oslagbara resultat.
• Integrationstester beskrivs som att systemkomponenter kopplas ihop och testas tillsammans innan systemtester tas vid. Systemintegrationstester nämns inte alls.
• Att ta upp "test design specification", "test case specification" och "test procedure specification" samt jämföra skillnader dem emellan är hårklyverier. Finns det organisationer som använder sig av alla dessa specifikationer och dokument. På samma sätt gör man en stor sak av skillnanden mellan "test policy", "test strategy", "master test plan" och "level test plan".
• ISTQB verkar närmast fixerad vid olika standarder och nämner IEEE-829, IEEE-1044, IEEE-1028, CMM, CMMi, TMM, TMMi och TPI. Jag har rätt ingående studerat IEEE-829 samt TPI och anser att det läggs alldeles för stor vikt vid dokumentation och frågan är om det gör att testerna blir så mycket bättre.