se zaměřením na testování Procesní standardy se zaměřením na testování Dušan Vaněk, dusan.vanek@adastragrp.com © Adastra, Confidential

Obsah Cesty k ustavení oboru testování ve firmách Přehled standardů Jaké jsou důvody ke změně a aplikaci standardů? Jaká je skutečnost ve firmách? CMMI vs. CIMM Co konkrétně znaměná standard v testování?

Ustavení organizace a procesů testování 1. cesta - Testují jen srabi Není třeba to otestovat… (…a všechny nedostatky se projeví až v produkci) Regresní testování už vůbec není potřeba… (…a polovina oprav nefunguje, nebo vyvolala další chyby) Otestovat to může kdokoliv… (…tak testuje kdejaký laik, ale nikdo neví co, jak a už vůbec ne proč) Otestujeme to v prostředí pro produkci … (…tak jim tu produkci trošku pocucháme, nu co?) Metodika je příliš komplikovaná… (…tak si to raději zkomplikujeme chaosem, ve kterém na polovinu věcí zapomeneme) Otestují to uživatelé při používání… (...a naděláme si další nepřátele IT v byznysové části podniku) Hrozně by to prodražilo projekt… (…takže to radši zaplatíme na opravách a pokutách.

Ustavení organizace a procesů testování 2 Ustavení organizace a procesů testování 2. cesta – Od nikoho se již nemáme co naučit Víme nejlépe sami, jak to má být – a vymyslíme a připravíme si sami: procesní metodiku strukturu domény testování organizaci postupy, metody, techniky nástroje nebezpečí opomeneme velmi důležité aspekty, které by mohly mít obrovský přínos bude nás to stát hodně úsilí a peněz izolace týmu, neporozumění pojmům jiných kultur bude omezena inspirativní výměna informací s týmy působícími jinde obtížné začleňování pracovníků přicházejících z jiných kultur bude obtížné stanovit strategii dalšího rozvoje a zlepšování ...

Ustavení organizace a procesů testování 3. cesta - Přepoužít, co se dá „Neobjevujeme znovu Ameriku“ a použijeme standardy oboru, které mohou předkládat: rámec principů, které je vhodné aplikovat pojmový rámec, oborový slovník a logickou strukturu domény testování Best practices (osvědčené postupy), metody, techniky vzorovou procesní metodiku (aktivity, role, artefakty – vstupy a výstupy) rámec záměrů, cílů a ukazatelů, na kterých lze sledovat účinnost či hospodárnost konání rámec potřebných znalostí pracovníků

Ustavení organizace a procesů testování 3. cesta - Přepoužít, co se dá výhody: přesto, že jsou často standardy placené a jejich implementace opravdu nestojí málo prostředků, v konečném důsledku peníze velmi šetří umožňují poměřování s ostatními usnadňují začleňování nových pracovníků podporují porozumění mezi stranami, zejména: dodavatel-odběratel vedení projektu-tým vývoje-tým testování nadřízený-podřízený podporují stanovení strategie zlepšování a rozvoje působnosti nebezpečí necháme se „svést“ a řešíme i to, co v daný okamžik není potřebné – zbytečně překračujeme „potřebnou kvalitu“ a vynakládáme zbytečné úsilí a finance nevhodně zvolený standard se obtížně nahrazuje jiným past extrémů: „papežtější, než papež“ vs. „implementace pouhého názvu standardu“ ...

Přehled standardů životní cyklus vývoje SW SPICE - ISO/IEC 15504 Software Process Improvement and Capability dEtermination http://www.isospice.com/categories/ISO%7B47%7DIEC-15504-Standard/ CMMI (dříve SW-CMM) Capability Maturity Model Integration http://www.sei.cmu.edu/cmmi/ ITIL Information Technology Infrastructure Library http://www.itil-officialsite.com/ , http://www.itil.cz/ EFQM Excellence Model European Foundation for Quality Management - Excellence Model www.efqm.org/ , http://www.csq.cz/cs/model-excelence-efqm.html COBIT Control Objectives for Information and related Technology – (procesní oblast Acquire and Install AI7 - Install and Accredit Solutions and Changes) www.isaca.org/cobit/ , http://www.itil.cz/index.php?id=929 Six Sigma http://www.isixsigma.com/

Přehled standardů testování SW TMM Test Maturity Model http://www.tmmifoundation.org/ , http://www.improveqs.nl/ukindex.htm ISTQB (CaSTB) International Software Testing Qualifications Board www.istqb.org/ , http://www.castb.org/tiki-index.php TMap Test Management Approach http://eng.tmap.net/Home/ TPI Test Process Improvement http://www.sogeti.nl/Home/Expertise/Testen/tpi_other_languages.jsp TOM Test Organization Maturity http://www.gerrardconsulting.com/ TIM Test Improvement Model http://www.lucas.lth.se/events/doc2003/0113A.pdf

CMMI - Capability Maturity Model Integration

Je tu důvod proč zvyšovat zralost? Vstoupili byste do výtahu, či nechali se vézt automobilem, který by byl vyvinut v procesech zralosti č. 1? Budete-li se rozhodovat investovat většinu svých prostředků do SW, který vám má v budoucnu posloužit jako klíčový výrobní prostředek, obrátíte se na firmu, která používá procesy zralosti č. 2?

Je tu důvod proč zvyšovat zralost? Použití softwarových produktů ze zkoumaného vzorku: 2% bylo použito tak, jak byly vytvořeny 4% byly použity po mírném přepracování 19% bylo použito po zásadním přepracování 47% nebylo použito nikdy 28 % nebylo dokončeno (zdroj Borland, 2003) ...nu, nic z lidského konání není stoprocentní.

Je tu důvod proč zvyšovat zralost? Situace příkladu: dodavatelská firma svým zákazníkům dodává nějaké produkty, které vyrábí v rámci projektů. Když dodá správný produkt, zákazník zaplatí stanovenou cenu, když nedodá zákazník nezaplatí. Když dodá špatný a oprava projekt zpozdí může se stát, že dodavatel zaplatí na pokutách i tolik, kolik mu zákazník zaplatí (tedy stejné důsledky jako nedodání). V našem příkladu má dodavatel nasmlouváno projektů s příjmy 1 miliarda českých korun. Všimněme si, jak velký rozdíl v penězích je mezi 99% úspěšností a např. úspěšností 99,999% (což je rozdíl pouhého necelého jednoho procenta).

Je tu důvod proč zvyšovat zralost? % úspěšnosti % ztráty ztracené finance na 1 miliardu Kč 99 1 10 000 000 Kč 99,9 0,1 1 000 000 Kč 99,99 0,01 100 000 Kč 99,999 0,001 10 000 Kč 99,9999 0,0001 1 000 Kč Ve statistickém průzkumu jsme ovšem viděli („při zavřených očích“ – když řekneme, že mírné přepracování je zanedbatelné) úspěšnost pouhých 6%! Zbytek znamenal, že: někdo (zákazník či dodavatel) vydal další nemalé náklady na dokončení/přepracování nebo někdo (zákazník či dodavatel) o své peníze přišel

Je tu důvod proč zvyšovat zralost? % úspěšnosti % nebezpečí počet nebezpečí na 1 mil. příležitostí 99 1 10 000 99,9 0,1 1 000 99,99 0,01 100 99,999 0,001 10 99,9999 0,0001 Na Ruzyni je 1 mil. startů a přistání uskutečněno za 2000 dnů, tedy za cca 5,5 let. Uchopitelněji: 1000 vzletů a přistání za pouhé 2 dny... ...tedy při 99,9% to znamená nebezpečnou situaci každé 2 dny Případně parkovací brzdy TRW a jejich spolehlivost?

Jaká je situace na trhu z hlediska zralosti? „Jestliže se se mnou podíváte na celý svět dnešních softwarových společností, pak: většina jich spadá do úrovně zralosti 1, mnoho je jich na úrovni zralosti 2, některé jsou na úrovni zralosti 3, několik málo na úrovni zralosti 4, a opravdu jen hrstka špičkových je na úrovni zralosti 5.“ Ron Patton, Software testing, 2002

CIMM (Capability Im-Maturity Model) 0. - Negligent /Indifference/ - nedbalý, lhostejný přístup Nedbalost, nepozornost, řada chybně navržených procesů a špatná organizace firmy způsobuje, že vytvořený software má velký počet chyb, které se ani nestačí identifikovat, natož opravit. Termíny se nedaří plnit, plánované náklady se překračují, často se žádné plánování nákladů ani neprovádí. Práce, která je přesto provedena, je nakonec zmařena v důsledku různých jiných nedostatků. Vedení firmy i pracovníci často spoléhají na nějaká zázračná řešení, která způsobí okamžité divy. Produkty se firmě od zákazníků neustále vracejí, aby byly opraveny a dopracovány, přičemž řada zákazníků žádá slevy na dodané produkty.

CIMM (Capability Im-Maturity Model) minus 1. - Obstructive /Counter-productive/ - kontraproduktivní, mařící přístup Řada kontraproduktivních opatření ve firmě a protichůdných procesů téměř znemožňuje vytvořit kvalitní software. Často se objevují odmítavá stanoviska k zavádění takových věcí jako projektové řízení, řízení kvality (produktu a procesů), uznávané metody tvorby software, produkty CASE apod., s odůvodněním, že se jedná jen o byrokratická, administrativní opatření, která komplikují programátorům a dalším zaměstnancům práci. Jedna reorganizace stíhá druhou, stejně zmatenou jako byla ta předchozí. Kvalita software je tak špatná, že zákazníci neustále produkty reklamují, firmu penalizují a postupně přecházejí k jiným firmám.

CIMM (Capability Im-Maturity Model) minus 2. – Contemptuous /Arrogance/ – opovrhující, arogantní přístup Ve firmě pracovníci přehlížejí jakákoliv doporučení a zásady softwarového inženýrství. Programování je prohlašováno za umění, takže jakékoliv snahy o zavádění pořádku a systému do vývoje software je označováno jako útok na uměleckou tvořivost a svobodu. Nejsou vedeny žádné údaje o postupu vývoje softwaru, často jsou takové údaje záměrně ničeny. Zákazníkům není nasloucháno a jsou naopak přesvědčováni, že produkty, které dostali, jsou ty nejlepší, a jejich nefunkčnost je zapříčiněna vlastní nízkou úrovní znalostí uživatelů v používání počítačů.

CIMM (Capability Im-Maturity Model) minus 3. Undermining /Sabotage/ – podrývající, sabotující přístup Samorostlé názory pracovníků firmy na tvorbu software jsou zcela mimo chápání normálních lidí a podkopávají důvěru veřejnosti v softwarové inženýrství...

TMM - Level 1: Initial Na úrovni 1 je testování chaotické, nejsou definovány procesy a je považováno za část debuggingu. Cílem testování tohoto levelu je ukázat, že software pracuje bez majoritních chyb. Softwarové produkty jsou uvolňovány bez přiměřeného zohlednění kvality produktu a rizik nekvality. V produkčním prostředí software často nenaplňuje potřeby, kterým má sloužit, není stabilní nebo má nízký výkon. Projekt testování se vyznačuje nedostatkem zdrojů, nástrojů i vzdělaných a zkušených testerů.   V této úrovni nejsou definovány žádné dílčí oblasti procesu testování.

TMM - Level 2: Definition Na úrovni 2 je testování definovaným procesem a je jasně odděleno od debuggingu. V kontextu struktury procesu testování jsou sestavovány plány testování, obsahující i strategii testování. Test Cases jsou odvozovány z Requirements a jejich specifikace, k testování jsou Test Cases vybírány s přihlédnutím k těmto Requirements. Jsou aplikovány techniky formalizace návrhu testů. Nicméně, testování začíná stále relativně pozdě v životním cyklu tvorby SW, např. v době návrhu produktu nebo dokonce až v období programování produktu. Hlavním cílem testování je verifikace splnění specifikovaných požadavků. Dílčí oblasti procesu pro úroveň 2 jsou: Test Policy and Goals (Zásady a záměry testování) Test Planning (Plánování testování) Test Techniques and Methods (Techniky a metody testů)

TMM - Level 3: Integration Na úrovni 3 je testování plně integrováno do životního cyklu softwaru. Pokrývá všechny úrovně V-modelu. Plánování testování v ranném stádiu projektu představuje sestavení Master Test Plan. Strategie testování se vyznačuje znaky použití technik pro risk management a je založena na dokumentovaných Requirements. Testování má organizační strukturu, je sestaven program vzdělávání v testování, a testování je vnímáno jako profese. Reviews jsou uskutečněné, ačkoliv nekonzistentně a nikoliv podle dokumentovaných procedur. Kromě verifikace, že software splňuje Requirements, je testování stále zaměřeno na mnoho nevhodných testů.   Dílčí oblasti procesu pro úroveň 3 jsou: Test Organisation (Organizační struktura testování) Test Training Program (Program vzdělávání v testování) Test Life Cycle and Integration (Životní cyklus testování a jeho integrace s ostatními obory) Test Control and Monitoring (Řízení a sledování v testování)

TMM - Level 4: Managment and Measurement Testování je důkladně definovaným, podloženým a měřitelným procesem. Reviews a inspekce mají své místo v celém životním cyklu softwaru a jsou považovány za součást testování (resp. ověřování). Softwarové produkty jsou vyhodnocovány použitím ukazatelů kvality jako je spolehlivost, použitelnost a udržovatelnost. Test Cases jsou shromažďovány, ukládány a řízeny v rámci centrální databáze, která umožňuje jejich znovupoužití, tedy pro účely regresního testování. Program měření testování poskytuje informace a ukazuje jak kvalitu testovaného produktu, tak i kvalitu procesu testování. Testování je vnímáno jako vyhodnocování, jehož aktivity probíhají po celý životní cyklus produktu a týkají se nejen produktu jako celku, ale též všech součástí. Dílčí oblasti procesu pro úroveň 4 jsou: Peer Reviews (Revize v týmu, vzájemná revize mezi kolegy) Test Measurement (Měření testování) Software Quality Evaluation (Vyhodnocení kvality SW produktu)

TMM – Level 5: Optimisation Na základě všech výsledků, které byly dosaženy postupným plněním všech záměrů zlepšování předchozích úrovní, je testování kompletně definovaným procesem a je schopno zajistit řízení nákladů a účinnosti testování. Na úrovni 5 jsou metody a techniky optimalizovány a je zajištěno zaměření na neustálé zlepšování procesu testování. Kromě jiného jsou ustaveny jako dílčí oblasti procesu též "Defect Prevention" (prevence nedostatků) a "Quality Control" (řízení kvality). Proces testování je charakteristický měřením kvality na základě vzorkování (sampling based quality measurements). Uplatňují se systematické postupy pro vyhodnocení a výběr nástrojů testování. Pro proces testování je zajištěna co největší míra podpory nástroji a to zejména v oblasti Test Design, Test Execution, Regression Testing, Test Case Management apod. Hlavním záměrem procesu testování je předcházet nedostatkům.. Dílčí oblasti procesu pro úroveň 5 jsou: Defect Prevention (Prevence nedostatků) Test Process Optimisation (Optimalizace procesu testování) Quality Control (Řízení kvality)

Další zdroje web Dušana Vaňka http://dusanvanek.webgarden.cz/ konkrétně k tématu: http://dusanvanek.webgarden.cz/novinky/tmm-test-maturity-model-spim-a-2.html