2007 Návrh snadno testovatelného software LaTes 07 Štěpán P. Nadrchal www.pdqm.cz nadrchal@pdqm.cz Cíl prezentace Základní otázky 1. Kdo má vliv na to, jestli software půjde testovat a kolik to dá práce? 2. Co udělat pro to, aby testování bylo co nejjednodušší a přitom zůstalo kvalitní? 2 Program 1. Představení 2. Kdy je třeba začít myslet na testování 3. Co všechno má vliv na možnosti testování 4. Jak testovat efektivně 3 (c) 2007, PDQM; LaTes 07 1
Představení PDQM Kvalitní řízení procesů a dat Cílem společnosti PDQM je podpora: Využití procesů organizace pro zlepšování efektivity práce Zavádění a zlepšování řízení kvality projektů (zejména kvality software) podpora procesu vývoje zajištění kvality v rámci projektů nákupu a realizace metodická podpora řízení projektů Podpora zlepšování interního fungování organizace Kvalita software www.pdqm.cz 4 Představení Štěpán P. Nadrchal, Ph.D Konzultace v oblasti zajištění kvality SW aplikací Podpora řízení a kontrola kvality na softwarových projektech Vědecká specializace Spolehlivost a bezpečnost real-time systémů Profesní specializace Optimalizace firemních procesů a projektů Školení v oblasti kvality procesů, jejich zlepšování a implementace metodologie CMMI (T-Mobile, CN Resource Technologies, GMC, ) 5 Kdy začít myslet na testování Dřív než na cokoli jiného (c) 2007, PDQM; LaTes 07 2
Testování začíná, když A) Zjistí se, že software obsahuje chybu B) Je hotová aplikace C) Zákazník se shání po předávacím protokolu D) Zákazník se na předávací testy ptá E) Přijde poptávka 7 Přijde poptávka Jsme schopni systém vyvinout? Umíme porozumět tomu, co zákazník chce? Jsme schopni dodat? Jsme schopni ověřit, že dodáváme, co zákazník skutečně chce? Umíme vytvořit takové podmínky, abychom ověřili, že náš produkt je tím, co zákazník potřebuje? Máme kapacity a schopnosti na testování? Umíme spočítat a ocenit, kolik bude ověřování stát? Umíme definovat požadavky, které potřebujeme splnit, abychom byli schopni systém testovat? 8 a následuje smlouva Zpřesňujeme požadavky (funkční i technologické) Pracujeme na detailech architektury Vybíráme technologie Sestavujeme tým Sestavujeme plán projektu Definujeme projektové činnosti a kroky Obsazujeme projektové role Stanovujeme odpovědnosti a plán úkolů Odhadujeme celkové nároky na zdroje 9 (c) 2007, PDQM; LaTes 07 3
Požadavky Ideální způsob verifikace požadavků: Navrhněte, jak je otestujete Ověříme, že požadavku korektně rozumíme (verifikace požadavků) Ujasníme si, co bude testování znamenat Můžeme využít pro akceptační testy 10 Odpověď č. 1a Kdo má vliv na to, jestli software půjde testovat? Business Analytici Management projektu Poučení Zapojte zkušené testery do projektu hned od začátku 11 Architektura a technologie Zvolená globální architektura má zásadní vliv na způsob testování a požadované schopnosti a nástroje Testování distribuovaných, klient/server nebo terminálových aplikací se zásadně liší Implementace midleware vyžaduje znalosti platformy i od testerů Různé druhy rozhraní se testují různě (Corba, SOAP, FTP, DCOM, ) Interní architektura je podstatná: Objektové knihovny nebo atomizované moduly s API Funkčnost definovaná daty Real-Time moduly Paralelismus Load-balancing 12 (c) 2007, PDQM; LaTes 07 4
Jak testovat efektivně aneb jak udělat co nejvíce muziky za co nejméně peněz Efektivní nástroje pro testování Objektové knihovny vyvíjet vždy společně s testy (xunit) nechte xunity vyvíjet testery Podporovat testovací mód umožňující sledovat interní chování Vytvořit testovací (ATI) rozhraní umožňuje přímo volat interní funkce Víceúrovňový log Paralelní systémy vybavit logováním umožňujícím kontrolovat synchronizace činností Nikdy netestovat jak black-box ale naopak se zaměřit na testování oblastí, které jsou kritické Distribuované systémy Podpora globálního logu Podpora sledování dostupnosti modulů Pro každý modul (externí i interní) vyvinout stub 14 Více úrovní testování Nenechávat unit testy na programátory Není dokumentované Není ohlídatelné Není objektivní Je dobré společně plánovat jednotlivé úrovně testů (unit testy, funkční, integrační, testy rozhraní) Společným plánováním testů se ušetří redundance (často úspora až 50% objemu práce) Pro každý typ kontroly se vybere nejvhodnější úroveň Zajistí se lepší pokrytí celku 15 (c) 2007, PDQM; LaTes 07 5
Co je dobré pro pána není dobré pro kmána Různé části aplikace je třeba testovat různě Každá unita má specifická rizika, různá pro spolehlivost, dostupnost, přesnost Potřeba testování se mění i podle původu testované jednotky Jinak testuji funkčnost obsaženou v koupeném balíku s 1000 instalacemi a jinak v nově vyvinutém řešení Různou míru kontroly uplatňuji na moduly vyvinuté týmy s různou úrovní zralosti interních procesů 16 Odpověď č. 1b Kdo/Co má vliv na to, kolik dá testování práce? Architekti Úzká spolupráce mezi testovacím a vývojovým týmem Poučení Využívejte pokud možno interní testery Postavte testery na roveň ostatním profesím 17 Nebojte se metrik Metriky pomáhají plánovat testy, sledovat jejich průběh i je včas ukončit 140 120 18 100 80 60 40 20 0 Srovnání reality s modelem 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 # bug in test R-Curve S-Curve density f max = 6.5 K = 1000 (c) 2007, PDQM; LaTes 07 6
100% 80% 60% 40% 20% 0% Počet z Unit 1 2 3 4 5 6 7 8 9 10 11 12 13 Week Found In Environment AR client Balance Management BCM BE Billing blade7 C CDR CE CM CM Adapter CRM Cust Ed. CV CV, Pro data Invoice Invoice in PDF format JO LRI management console ME OFS OR OR - Pro OR, CV OR, Pro Ordering PC PC - data Pre Pro Prod Cat. Production Návrh snadno testovatelného software Příklad - data 19 R - curve C - curve We e k o f # bug in number of curve reality S-Curve S-total te s ting tes t Dens ity Dis tribution defects found var. dens ity distribution (%) 1 18 33,01 16,65 1,66% 1,50% 15,76 15,76 2 22 62,78 64,94 6,49% 4,08% 42,56 58,32 3 32 86,60 140,22 14,02% 5,46% 62,20 120,52 4 58 102,66 235,54 23,55% 4,47% 75,13 195,66 5 103 110,33 342,73 34,27% 0,73% 82,18 277,84 6 89 110,08 453,55 45,35% 2,11% 84,38 362,22 7 87 103,24 560,68 56,07% 1,62% 82,82 445,04 8 117 91,73 658,47 65,85% 2,53% 78,54 523,59 9 51 77,57 743,26 74,33% 2,66% 72,45 596,04 10 44 62,66 813,37 81,34% 1,87% 65,31 661,35 11 20 48,45 868,81 86,88% 2,84% 57,73 719,08 12 28 35,92 910,83 91,08% 0,79% 50,17 769,25 13 16 25,58 941,39 94,14% 0,96% 42,94 812,19 14 47 17,51 962,75 96,28% 2,95% 36,26 848,45 15 11,53 977,11 97,71% 30,25 878,70 16 7,31 986,39 98,64% 24,95 903,66 17 4,46 992,18 99,22% 20,37 924,03 18 2,63 995,66 99,57% 16,48 940,51 19 1,49 997,67 99,77% 13,21 953,72 20 0,81 998,79 99,88% 10,50 964,22 21 0,43 999,39 99,94% Forcas t 8,28 972,51 22 0,22 999,70 99,97% 6,49 978,99 23 0,11 999,86 99,99% 5,04 984,04 24 0,05 999,94 99,99% 3,90 987,94 25 0,02 999,97 100,00% 2,99 990,93 (s urrenes ) R 2 = 0,75 Poučení Bez metrik nikdy nejsme schopni říct, co je vhodná úroveň testování a kdy je možné testování ukončit Statické metriky pomohou předem odhadnout objem testovacích prací Vyhodnocování složitosti modulů pomůže zvolit vhodnou úroveň testování pro moduly Dynamické metriky včas ukáží na problémy při testování 20 Provažte procesy Změnové řízení musí být konzultováno s testováním Náročnost testování podobné úpravy se může řádově lišit podle toho, v kterém modulu se změna projeví Rozvoj aplikace musí sledovat potřeby testerů Některé funkce (logy, interní jazyk systému apod.) mohou být pro testování kritický a bez spolupráce s testery se na to může zapomenout Nákup řešení od třetí strany by měl být také posuzování Je řešení otestovatelné? Jsem schopni testy modulu provázat s našimi testy? 21 (c) 2007, PDQM; LaTes 07 7
Automatizuje s rozumem Automatizace může testy výrazně zlevnit ale také prodražit 22 Kdy ano: Opakované regresní testy dlouhodobě užívané a různě upravované aplikace Balík opakovaně dodávaný více zákazníkům (produkt) Kdy ne: V době rychlého vývoje (kromě využití xunit) Produkt, který po dokončení nebude upravován nebo pouze zásadními změnami (např. koupené řešení) Automatizace je víc než simulace uživatele Často je efektivnější vyvíjet nezávislé testy společně s aplikací s využitím logů, API a databáze Automatizované sanity testy kontrolují např. prostřednictvím administrátorských modulů komunikační vrstvy Odpověď č. 2 Co udělat pro to, aby testování bylo co nejjednodušší a přitom zůstalo kvalitní? Pro každou technologii používejte odpovídající nástroje a postupy Vychovejte si zkušeného test architekta (nejlépe z analytika vývojového týmu) Podporujte testování už v návrhu a při vývoji Používejte metriky před testování, při něm i po něm Poučení Testování není nudnou popelkou ale kreativní prací 23 Diskuse Prezentace je k dispozici na adrese www.pdqm.cz/download/lates07.pdf 24 Děkuji za pozornost, Štěpán P. Nadrchal nadrchal@pdqm.cz (c) 2007, PDQM; LaTes 07 8