Procesní standardy se zaměřením na testování Dušan Vaněk

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

Obsah § § § 2 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í 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… 3 (…takže to radši zaplatíme na opravách a pokutách.

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 4 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: 5 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čí 6 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 d. Etermination http: //www. isospice. com/categories/ISO%7 B 47%7 DIEC-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 AI 7 - Install and Accredit Solutions and Changes) www. isaca. org/cobit/ , http: //www. itil. cz/index. php? id=929 § Six Sigma 7 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 (Ca. STB) 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 8 Test Improvement Model http: //www. lucas. lth. se/events/doc 2003/0113 A. pdf

CMMI - Capability Maturity Model Integration 9

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? 10

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) 11

Je tu důvod proč zvyšovat zralost? § Situace příkladu: 12 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 99 99, 9999 % ztráty 1 0, 01 0, 0001 ztracené finance na 1 miliardu Kč 10 000 Kč 100 000 Kč 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: 13 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

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 14

CIMM (Capability Im-Maturity Model) § 0. - Negligent /Indifference/ - nedbalý, lhostejný přístup 15 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 16 Ř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 17 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 18 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 § § § § 19 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: § § § 20 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: 21 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: 22 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: § § 23 Defect Prevention (Prevence nedostatků) Test Process Optimisation (Optimalizace procesu testování) Quality Control (Řízení kvality)

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

www. adastragrp. com ADASTRA CZ Nile House Karolinská 654/2 186 00 Praha 8 Tel. : +420 271 733 303 info@adastra. cz www. adastra. cz Děkuji za pozornost… ADASTRA GROUP North America 8500 Leslie St. Markham, Ontario, L 3 T 7 M 8 Canada Tel: +1 905 881 7946 info@adastragrp. com 25 ADASTRA GROUP Europe Karolinska 654/2 186 00 Praha 8 Czech Republic Tel. : +420 271 733 303 info@adastragrp. com