Prezentace se nahrává, počkejte prosím

Prezentace se nahrává, počkejte prosím

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

Podobné prezentace


Prezentace na téma: "© Adastra, Confidential se zaměřením na testování Procesní standardy Dušan Vaněk,"— Transkript prezentace:

1 © Adastra, Confidential se zaměřením na testování Procesní standardy Dušan Vaněk,

2 2 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í?

3 3 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.

4 4 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í ̶...

5 5 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ů

6 6 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“ ̶...

7 7 Přehled standardů životní cyklus vývoje SW  SPICE - ISO/IEC ̶ Software Process Improvement and Capability dEtermination ̶  CMMI (dříve SW-CMM) ̶ Capability Maturity Model Integration ̶  ITIL ̶ Information Technology Infrastructure Library ̶  EFQM Excellence Model ̶ European Foundation for Quality Management - Excellence Model ̶  C OBI T ̶ Control Objectives for Information and related Technology – (procesní oblast Acquire and Install AI7 - Install and Accredit Solutions and Changes) ̶  Six Sigma ̶

8 8 Přehled standardů testování SW  TMM ̶ Test Maturity Model ̶  ISTQB (CaSTB) ̶ International Software Testing Qualifications Board ̶  TMap ̶ Test Management Approach ̶  TPI ̶ Test Process Improvement ̶  TOM ̶ Test Organization Maturity ̶  TIM ̶ Test Improvement Model ̶

9 9 CMMI - Capability Maturity Model Integration

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

11 11 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í.

12 12 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).

13 13 Je tu důvod proč zvyšovat zralost? % úspěšnosti% ztrátyztracené finance na 1 miliardu Kč Kč 99,90, Kč 99,990, Kč 99,9990, Kč 99,99990, 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

14 14 Je tu důvod proč zvyšovat zralost? % úspěšnosti% nebezpečípočet nebezpečí na 1 mil. příležitostí ,90, ,990, ,9990, ,99990,00011  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?

15 15 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

16 16 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.

17 17 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.

18 18 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čů.

19 19 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í...

20 20 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í.

21 21 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ů)

22 22 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í)

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

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

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


Stáhnout ppt "© Adastra, Confidential se zaměřením na testování Procesní standardy Dušan Vaněk,"

Podobné prezentace


Reklamy Google