Existuje mnoho metodik, článků, knih a jiných zdrojů, pojednávacích o Test Process Improvementu (TPI). Většina z nich je velmi podobná standardním process improvement metodikám v IT disciplínách. A je jedno jestli je to na straně IT operations nebo na straně IT projektů. Obecně jde o snahu nastavit interní procesy tak, aby výstupy z nich odpovídaly pokud možno co nejvyšší očekávané kvalitě.
Jak ale takové TPI nastavit ve společnosti, která dodává své služby různým zákazníkům v různých odvětvích a v různých typech projektů? Je vůbec možné testovací procesy nějakým způsobem unifikovat?
Specifikem IT dodavatelských firem je, že se podílí na různých projektech, s různou kulturou, různými nástroji a různými metodikami pro vývoj aplikací. To vede nejen k tomu, že není možné nastavit procesy metodicky pevně, ale také k velkým rozdílům v terminologii, rozdělení projektových aktivit apod. V praktické rovině se to promítá např. do struktury vytvářených artefaktů.
Na jednom projektu se zavádí Test Strategy, a k ní následně Test Plány pro jednotlivé releasy, na jiném se zase vytváří jeden společný dokument.
A to vše ještě navíc může mít jiný přístup či metodiku ze strany zákazníka.
Podobné je to i s použitím testovacích nástrojů (které samy o sobě vnucují svoji terminologii) nebo dokonce jejich kombinací. U jednoho zákazníka se tak můžete setkat s tím, že jeden nástroj se používá pro Test Management, jiný nástroj pro Defect management. Už to samo o sobě vede k nekonzistentnímu terminologickému slovníku s výrazným dopadem na nastavování procesů testingu.
Pokud se do toho ještě zapojí rozdílné postupy/procesy mezi různými projekty (třeba toho samého zákazníka), tak získáte skrumáž, ve které je těžko vybudovat nějakou stálou hierarchii procesů a tlačí vás to k výrazné agilitě. Ta ale bohužel často končí metodou „dělej, jak se dá“ nebo „prostě to nějak udělejte“. Výsledek může být ten, že vyspělost procesů je projekt od projektu různá a těžko predikovatelná. A tak se může stát, že jeden a ten samý tým IT dodavatele může být u jednoho zákazníka (nebo projektu) vnímán jako vysoce profesionální u jiného zase výrazně méně pozitivně.
Pokud k výše zmíněnému navzájem nekompatibilnímu prostředí připočítáte změny v čase, kdy jsou např. různé zúčastněné projekty v různých fázích, tak se situace komplikuje ještě více.
Jakým způsobem je v takovém prostředí možné hovořit o jednotných, vzájemně kompatibilních procesech či postupech v oblasti testingu? A jak v takovém prostředí zajistit jejich zlepšování?
Touto problematikou se v Ness Technologies zabýváme už několik let. Výsledkem je to, že jsme v rámci testingu upustili od striktně definovaných metodik, šablon a terminologie a orientujeme se jenom na hlavní uzly a artefakty testovacích procesů.
Máme tedy definované jenom hlavní artefakty, které na projektu vznikají, jejich základní obsah a propojení. Neřešíme tedy terminologii (a ani ji nevnucujeme projektům), ani detailní obsah artefaktů.
Kromě toho máme nad hlavními artefakty definované aktivity, které musí být realizované, ale taky komunikaci do týmu i mimo něj, a hlavně využívaní v praxi. Jde nám především o to, aby nešlo o mrtvé dokumenty, které se někde založí a už se více nepoužívají.
Tímto způsobem se snažíme zajistit adekvátní a navzájem komparativní úroveň výstupů testingu na různých typech projektů a u různých zákazníků.
Velmi nám v tom pomohl rámec TMMi, jehož základ vychází z podobných principů a metodik, které jsme běžně už dříve používali a používáme (např. ISTQB, RUP…). TMMi používáme ke vzájemné komparaci úrovně testingu na různých projektech.
Nejdřív na projektu porovnáváme úroveň testovacích aktivit a jejich výstupů vůči levelu 2 (cíle a praktiky zde uvedené považujeme pro projekt za mandatorní). Pokud jde o projekt dlouhodobější, tak následně pro zlepšování projektových procesů používáme komparaci s vyššími úrovněmi levelů TMMi. V určitých periodách pak porovnáváme úroveň testingu (podle struktury TMMi) přes různé typy projektů. Tímto způsobem jsme schopni zajistit:
- přenos know-how z jednoho projektu na jiný
- identifikaci případných nedostatků vůči Best Practices, obecně definovaným v TMMi
- zefektivnění procesů a jejich celkové maturity testingu na konkrétním projektu
- kontextově orientovanou diskusi ve vztahu k aktuálním potřebám a zkušenostem z daného projektu
Výsledkem je nejenom to, že naše služby jsou mezi jednotlivými projekty navzájem na velmi blízké úrovni vyspělosti testovacích procesů, ale také možnost pro jejich postupné zlepšování.
Výrazně se tak umožňuje přesun know-how, a tím kvalitnější dodávky pro naše zákazníky.
Jaroslav Strharský
Quality Assurance and Testing, Ness Technologies
Chcete se dozvědět více o testování a dalších IT službách? Potřebujete snížit náklady na firemní informační technologie? Využijte služeb společnosti Ness Technologies!
PŘEDPLATNÉ
ČLÁNKY DO MAILU