Upozornění pro čtenáře a uživatele této knihy

Všechna práva vyhrazena. Žádná část této tištěné či elektronické knihy nesmí být reprodukována ani šířena v papírové, elektronické či jiné podobě bez předchozího písemného souhlasu nakladatele. Neoprávněné užití této knihy bude trestně stíháno.

Miroslav Bureš, Miroslav Renda, Michal Doležel, Peter Svoboda, Zdeněk Grössl, Martin Komárek, Ondřej Macek, Radoslav Mlynář

Efektivní testování softwaru

Klíčové otázky pro efektivitu testovacího procesu

Vydala Grada Publishing, a.s.

U Průhonu 22, Praha 7

obchod@grada.cz, www.grada.cz

tel.: +420 234 264 401, fax: +420 234 264 400

jako svou 6339. publikaci

Recenzovali:

doc. Ing. Valentino Vranić, Ph.D.

doc. RNDr. Jiří Barnat, Ph.D.

doc. Ing. Branislav Lacko, CSc.

Odpovědný redaktor Petr Somogyi

Sazba Jan Šístek

Formát ePub Štěpán Böhm

Fotografie na obálce fotobanka Allphoto

Počet stran 232

První vydání, Praha 2016

Vytiskly Tiskárny Havlíčkův Brod, a. s.

© Grada Publishing, a.s., 2016

Cover Design © Grada Publishing, a. s., 2016

Názvy produktů, firem apod. použité v knize mohou být ochrannými známkami nebo registrovanými ochrannými známkami příslušných vlastníků.

ISBN 978-80-271-9390-5 (ePub)

ISBN 978-80-271-9389-9 (pdf)

ISBN 978-80-247-5594-6 (print)

Úvod

Držíte v rukou knihu, která se zabývá vybranými tématy z oblasti testování softwaru. Věříme, že vám informace a zkušenosti obsažené na následujících stránkách pomohou zefektivnit práci, nastavit nový úhel pohledu na věc nebo vyvolat následnou diskuzi.

Testování představuje průměrně 20 % až 40 % pracnosti v projektech vývoje softwaru. Pro vývoj řídicího softwaru s vysokými požadavky na spolehlivost může pracnost testování často přesáhnout pracnost vývoje. Pokud má být testování efektivní, musíme k němu přistupovat jako k samostatné odborné disciplíně – stejné, jako je analýza, návrh, architektura, vývoj nebo projektové řízení. Klíčem k úspěchu je vyvážená kombinace metodiky a praktických zkušeností.

Proč jsme se rozhodli o testování softwaru napsat další knihu? Na toto téma je k dispozici řada odborných publikací v anglickém jazyce, ale v češtině jich je pomálu. A právě místní kontext je podle našeho názoru podstatný – praktické zkušenosti a rady, které najdete na dalších stránkách, jsou pochopitelně ovlivněné projekty, z nichž pocházejí. Autoři jednotlivých kapitol sice pracovali na řadě zahraničních nebo mezinárodních projektů, ale velká část našich zkušeností pochází z českého prostředí.

Kniha poskytuje průřez oblastí, které jsou podle našeho názoru na současných testovacích projektech problematické, nebo představují rezervu z hlediska efektivity testování. Kniha ani zdaleka nepokrývá kompletní životní cyklus testování. Vědomě zanedbáváme zejména témata týkající se analýzy testování. Ta byla rámcově pokryta v knize [1] a jejich detailní popis by vydal na samostatnou publikaci.

Pro jaké typy projektů a domény se kniha hodí?

Testování softwaru je velmi různorodá disciplína. Jedno ze sedmi základních pravidel testování prezentovaných ve standardu ISTQB [2] říká, že testování je závislé na kontextu. Mobilní aplikaci elektronického bankovnictví vyvíjenou agilním způsobem budeme testovat podstatně jinak než řídicí software dopravního letadla.

Tato kniha je do jisté míry ovlivněna doménovými znalostmi a zkušenostmi jejích autorů. Většina projektů, na kterých jsme pracovali, byla řízena stylem vývoje typu vodopád (waterfall). Agilnímu testování se proto v knize systematicky nevěnujeme. Téma je pokryté v řadě jiných publikací, např. [3]. Nejvíce zkušeností máme z oblasti vývoje webových nebo desktopových aplikací. Projekty, které ovlivnily naše zkušenosti, byly realizované zejména v oblastech bankovnictví, pojišťovnictví a telekomunikačních služeb. Méně zkušeností máme v oblasti testování vestavěných systémů (embedded systems) a softwaru, kde jsou kladené vysoké požadavky na spolehlivost. Pro tyto oblasti nemusí všechny popsané metody stoprocentně odpovídat.

Jak je kniha strukturovaná

Kniha je uspořádána do 13 kapitol, každá z nich se snaží pokrýt jednu tematickou oblast bez větších závislostí na jiné kapitole. Můžete tedy pracovat s jednotlivými kapitolami „na přeskáčku“ tak, jak se vyskytne potřeba pro rozšíření znalostí konkrétní problematiky. Jedinou výjimkou je kapitola 2, Role testování ve firmě a v projektu, která vysvětluje základní pojmy o testování, z nichž vychází výklad v ostatních kapitolách. Tuto kapitolu doporučujeme přečíst vždy.

Každá kapitola obsahuje závěrečné shrnutí, které rekapituluje nejdůležitější informace k danému tématu. Pokud byste nenašli čas na přečtení všech kapitol, doporučujeme prolistovat knihou a přečíst alespoň tato shrnutí.

Dílčí kapitoly jsou psané různými autory, kteří jsou experty na probíranou oblast. Nevýhodou tohoto „sborníkového přístupu“ může být mírně odlišný jazykový styl jednotlivých kapitol. Věříme, že kvalita informací tuto nevýhodu výrazně převáží.

Komu je kniha určená?

Knihu jsme psali pro začínající manažery testování, nebo pro zkušené testery či analytiky testování, kteří by se časem chtěli do role manažera testování profilovat. Kromě toho samozřejmě doufáme, že nové poznatky nebo nové úhly pohledu na jednotlivé problémy najdou v knize i zkušenější manažeři testování. Pro získání základního přehledu knihu doporučujeme i projektovým manažerům.

Použitá terminologie

Při psaní knihy jsme se snažili používat odborné termíny ve překladu použitém v glosáři ISTQB [4]. V několika málo případech jsme se od tohoto zdroje uchýlili, protože jsme buď považovali za vhodnější termín ustálený v testerské praxi, nebo glosář daný termín neobsahuje.

O autorech

Miroslav Bureš

Testováním softwaru se zabývá již přes deset let. V současné době působí na katedře počítačů ČVUT FEL, kde se zabývá výzkumem a inovacemi v oblasti testovacích metodik, efektivní automatizace testování a automatizace návrhu testovacích scénářů. Zde také vyučuje předměty týkající se testování softwaru a vede řadu experimentálních projektů s cílem zvýšit efektivitu současných testovacích metod. V předchozím období vedl testovací oddělení české a slovenské pobočky Capgemini, spolupracoval s tvůrci testovací metodiky TMAP a působil v řadě projektů z oblasti financí jako manažer testování a projektový manažer.

Miroslav Renda

Od roku 1995 prošel většinou projektových rolí v oblasti dodávky softwaru. Nejdéle působil v roli projektového manažera. Je držitelem mezinárodních certifikátů ISTQB, Prince 2, ITIL a dalších. V poslední době vedl testovací oddělení v konzultační společnosti Capgemini, v součanosti řídí testování nebo dodávky IT projektů klientům ve finanční sféře. Několikrát přednášel na mezinárodní konferenci CzechTest. Ve volném čase se věnuje rodině, sportu a práci viceprezidenta odborné neziskové organizace CaSTB.

Michal Doležel

Má za sebou více než desetiletou technicko-manažerskou praxi v oblasti testování softwaru, především z odvětví telekomunikací a finančnictví. Dnes pracuje v pražském IT hubu farmaceutické společnosti Merck Sharp & Dohme, kde vede Testing Center of Excellence pro region EMEA. Rovněž spolupracuje s katedrou informačních technologií VŠE FIS, kde vyučuje v magisterském studiu a zabývá se výzkumem. Je autorem několika příspěvků publikovaných v odborných časopisech a na zahraničních konferencích. Mimo testování jsou předmětem jeho zájmu organizační koncepty pro vývoj informačních systémů a mezioborová problematika sociálních a kulturních faktorů v IT.

Zdeněk Grössl

Téměř patnáct let testuje software, prošel pozicemi od testera až po manažera testování, převážně v oblasti financí a utilit. Jeho hlavní doménou je oblast analýzy testování, což podporuje i fakt, že je jedním z nemnoha českých držitelů certifikátu ISTQB CTAL Test Analyst. V současné době vede testovací oddělení ve společnosti Ness Czech a současně přednáší na VŠE analýzu testování. Pravidelně také vede tutoriály o analýze testování na mezinárodní konferenci CzechTest a účastní se zájmových setkání proTest.

Martin Komárek

Specialista v oblasti business analýzy a specifikace požadavků na software. V současnosti pracuje ve firmě Cactoo Software, kde působí především jako lektor a konzultant. Kariéru začínal jako analytik bezpečnostně-kritických aplikací v AŽD. Od roku 2007 přednáší na ČVUT FEL tématiku softwarového inženýrství.

Ondřej Macek

Jako konzultant a školitel se podílí na řadě projektů z oblasti business analýzy a procesního řízení IT. Působil na ČVUT FEL, kde kromě realizace softwarových projektů vyučoval i předměty spojené s objektovým návrhem kódu a s řízením vývoje softwaru.

Radoslav Mlynář

V oblasti informačních technologií pracuje od roku 2001. Na začátku kariéry se zabýval implementací a administrací nástrojů pro řízení testů. Tři a půl roku strávil na projektech, kde měl na starosti implementaci technických požadavků od jejich analýzy, přes testování až po nasazení. Pět let vedl tým řízení kvality softwaru v České spořitelně. V současné době se v České spořitelně podílí na budování nové organizační jednotky – profesionálního testovacího centra v oblasti řízení testovacích prostředí a v oblasti řízení testů souhrnných celobankovních releasů.

Peter Svoboda

Testováním softwaru se zabývá od roku 2006, jeho specialitou je ekonomika testů a business pohled na testování. V minulosti působil v testovacím oddělení společnosti AVG a jako manažer testování a test konzultant ve společnosti Capgemini. V současné době buduje slovenskou větev společnosti tesena a věnuje se rozšiřování povědomí o nových trendech v testování na slovenském a českém trhu. Zároveň působí v roli manažera testování na IT projektech, především ve finančních institucích.

Poděkování

Na tvorbě knihy se podílela nejen osmička autorů. Na konečnou kvalitu díla měla velký vliv řada expertů z oblasti testování, kteří revidovali dílčí kapitoly. Za podnětné připomínky a náměty bychom chtěli poděkovat (v abecedním pořadí): Ladislavu Doubkovi, Karlovi Frajtákovi, Karolu Frühaufovi, Antonínu Gabrielovi, Anně Havlíčkové, Davidu Janotovi, Davidu Kristlovi, Štěpánu Květenskému, Tomáši Lisému, Martinovi Mičkalovi, Lubomíru Michalčákovi, Petru Neugebauerovi, Štěpánu Pelcovi, Slavoji Pískovi, Gáboru Puhallovi, Blance Rabhi, Zdeňkovi Samuelovi, Jaroslavu Strharskému, Pavlu Strnadovi, Milanovi Šterbovi, Romanu Štroblovi, Ivo Zelenkovi a Janě Zientkové. V neposlední řadě pak děkujeme recenzentům knihy doc. Ing. Valentinu Vranićovi, Ph.D., doc. RNDr. Jiřímu Barnatovi, Ph.D. a doc. Ing. Branislavu Lackovi, CSc.

1Businessová hodnota testování

Peter Svoboda

Téměř každý IT projekt doprovází diskuze mezi sponzorem, businessovým vlastníkem zaváděného řešení, dodavatelem a manažerem testování o tom, jaká hloubka testování a potažmo jako množství vynaložených prostředků je žádoucí, potřebné a možné.

Cílem této kapitoly je poskytnout čtenáři argumentaci k obhájení potřeb testování vypočtených pomocí metod v kapitole 5, Odhadování pracnosti testovacích aktivit. Vysvětlíme si termín cena za kvalitu, podíváme se na její výpočet a postupně projdeme jednotlivými fázemi přípravy a použití argumentace nákladů na testování. Celý výklad bude proložen modelovými situacemi, které mohou manažerovi testování pomoci najít inspiraci při prosazení potřeb testování v organizaci.

1.1Kam mohou vyšplhat náklady za nedostatečnou kvalitu

V této kapitole se nebudeme podrobně věnovat odhadování pracnosti testů, protože detaily k tomuto tématu najdete v kapitole 5, Odhadování pracnosti testovacích aktivit. Předpokládejme tedy, že pracnost stanovit umíme a dokážeme si tuto pracnost obhájit i před experty z oblasti testování. V praxi často narážíme na problém při obhajování ceny za testování u sponzora projektu a potažmo u dalších organizačních složek zapojených do projektu (business). Otázka, se kterou se každý manažer testování v takové chvíli potýká nejčastěji, zní: „Proč máme tolik platit za testování? Cena za testy je příliš vysoká!“ Vezměme si pro další výklad na pomoc událost, která se před nějakým časem skutečně stala.

V květnu 2015 vydal americký Úřad pro letectví (FAA) bezpečnostní bulletin pro všechny modifikace Boeingu 787 Dreamliner.[1] Bulletin se týkal softwarového problému v řídicí jednotce generátorů palubního napětí, ve kterém dojde po 248 dnech nepřetržitého běhu řídicí jednotky k přetečení rozsahu datového typu a následnému pádu softwaru do nouzového režimu. V praxi by to pak znamenalo okamžité vypnutí obou hlavních palubních generátorů a ztrátu napětí, což by znamenalo ohrožení bezpečnosti letu. Největší nebezpečí hrozí ve fázích vzletu a přistání, kdy by automaticky spuštěná náporová turbína díky nízké rychlosti letounu nezačala vyrábět dostatečné množství energie do šesti sekund od vypnutí generátorů, po kterou budou energii dodávat palubní baterie.

Bezesporu se jedná o závažný defekt. K dubnu 2015 je v provozu 269 letadel typu Boeing 787 všech variant.

Podívejme se na detaily vnitřní implementace této funkcionality:

■V řídicím softwaru generátorů je jednoduché počítadlo, které narůstá každou setinu sekundy o 1.

■Počítadlo se vynuluje při vypnutí řídicí jednotky.

■Pro počítadlo byl použit datový typ o šířce 31 bitů. Rozsah počítadla je tedy 2^31 milisekund.

To znamená, že po cca 248 dnech dojde k přetečení rozsahu počítadla a chybě v softwaru. V komerčním letectví je běžné, že se systémy letadla pří zastavení úplně nevypínají (hlavně ty, které mají na starost napájení, což je i tento případ). K úplné odstávce dochází zpravidla při servisních zásazích. Čas běhu 248 dnů je sice nepravděpodobný, nikoliv však vyloučený. Z tohoto důvodu FAA vydala nařízení k okamžitému restartu všech jednotek ve všech variantách modelu Boeing 787, aby se čas na odstranění defektu v softwaru prodloužil o (minimálně) 248 dnů.

Co to znamená z pohledu ekonomiky (ne)testování?

Nařízení FAA je pro aerolinky (minimálně americké) závazné, tudíž jej musí provést všechny, jež provozují daný typ stroje. Jeden restart byl vyčíslen na jednu pracovní hodinu technika hodnocenou 85 USD, takže pouhá aplikace tohoto „workaroundu“ stála americké provozovatele aerolinek 22 865 USD.

Nepřímé finanční dopady, zejména nutnost stáhnout letadlo kvůli zásahu z provozu a ztráta reputace díky popularitě této zprávy v médiích, mohou být o řád až dva vyšší.

Vyřešení defektu bude nejspíše spočívat ve hloubkové analýze kódu a nahrazení všech nenulovaných proměnných s datovým typem integer 32 bit proměnnou typu integer 64 bit. Následovat budou rozsáhlé regresní testy, zátěžové testy a simulované testy dlouhodobého provozu (pokus o znovunalezení defektu). Jelikož systémy Dreamlineru obsahují přibližně 110 milionů řádků kódu, tyto náklady se pravděpodobně vyšplhají na několik milionů dolarů.

Zavedení testování dlouhodobé odolnosti (soak testing) ve vhodný okamžik přitom při podobně rozsáhlých projektech představuje náklady ve výši několika desítek tisíc USD. Jinými slovy – investicí desítek tisíc USD do vhodného typu testu bylo možné předejít ztrátě několika milionů USD vyvolané defektem.

Tabulka 1.1: Typické přímé náklady na opravu defektu v závislosti na fázi, ve které byla nalezena (zdroj: Capgemini)

I v případě, že aktuálně nepracujete na projektu vývoje softwaru pro letectví, základní principy jsou obecně platné napříč odvětvími. Před několika lety provedla společnost Capgemini průzkum ceny za opravu defektů v různých fázích projektu,[2] zahrnující několik stovek integračních projektů z celé Evropy.

Přímé náklady na defekt, který je nalezen až v produkci, jsou tedy podle tohoto průzkumu v průměru 12,5× vyšší než náklady na odstranění defektu nalezeného v průběhu vývojářských testů. Pokud do testování zapojíme např. revize analytických dokumentů, můžeme opravu části chyb zlevnit až 50×.

1.2Výpočet ceny za kvalitu

Větší IT projekty jsou ve většině případů financované z peněz, nad nimiž mají kontrolu výkonní manažeři společnosti. Mnozí manažeři testování a manažeři projektů si stěžují, že komunikace a jednání s výkonnými manažery je složité. V těchto stížnostech zaznívá, že výkonní manažeři nechtějí slyšet argumentaci a jediné, co je zajímá, je co nejnižší cena. To nemusí být pravda. Je nutné si uvědomit, že manažeři testování a manažeři IT projektů jsou většinou technicky uvažující lidé, upřednostňující rozdílnou argumentaci a vyznávající jiné profesní hodnoty než lidé ve výkonném managementu. Výkonný management často neslyší na argumenty typu „testování sníží rizika“, „testování ušetří peníze“ (něco nedělat je přeci 100% sleva) nebo na obsáhlou argumentaci popisující technickou složitost řešení a z toho plynoucí technické komplikace. Je třeba argumentovat jinak. Výkonný management zajímá hodnota, kterou za své peníze dostanou.

Kolik tedy má sponzor zaplatit za testy? Tato otázka je v principu špatně položená. Lepší je ptát se, co chceme pomocí testů dosáhnout? Jaká je hodnota, kterou testy přinesou?

Odpověď na tuto otázku bude dána namapováním produktů testování na businessové cíle při zohlednění fází životního cyklu produktu. Toto mapování je přehledně zobrazené na obrázku 1.1. Zkratka MŽP znamená minimální životaschopný produkt (angl. minimal viable product).

Obrázek 1.1: Mapování produktů testování na businessové cíle při zohlednění fází projektu

V praxi se osvědčil při přípravě strategie testování následující postup:

1.Diskuze očekávané hodnoty testování se sponzory – tato aktivita by měla proběhnout jako první, jelikož očekávaná hodnota testování do určité míry definuje cíle testování.

2.Odhad pracnosti testování – jako vstup pro odhadování pracnosti jsou kromě jiného použity výstupy diskuze se sponzorem o hodnotě testování.

3.Validace odhadů se sponzorem – zde už můžete použít pro argumentaci výstupy z úvodní schůzky. Tedy domluvené businessové cíle a náklady na produkty testování, jež je pomáhají naplnit.

A jak můžeme popsat a kvantifikovat cenu za kvalitu (angl. Cost of Quality, COQ), zmíněnou v úvodu? Podle standardu ISTQB vstupují do ceny za kvalitu (či přesněji „ceny za nekvalitu“) následující kategorie nákladů:

■Náklady využití na prevenci defektů – sem patří např. školení vývojářů, náklady na zavedení kódovacích standardů.

■Náklady na nalezení defektů – zahrnují veškeré testovací aktivity od plánování testů, přípravy testovacích případů, revize specifikací, přípravu testovacích prostředí, jejich vykonávání až po reporting.

■Náklady vyvolané řešením defektů v době testování (angl. cost of internal failure) – sem patří náklady na opravu defektů ve specifikacích, opravy defektů v kódu a na ně nabalené náklady dalších rolí (nasazování do prostředí, přetestování atd.).

■Náklady vyvolané selháními v produkčním prostředí (angl. cost of external failure) – zahrnují nejen přímé náklady na veškeré aktivity související s opravou případných produkčních defektů a distribucí opraveného systému uživatelům. Velkou položkou v této škatulce mohou být náklady na sankce (např. smluvní pokuta účtovaná odběratelem), náklady na ztrátu reputace atd.

Náklady na zajištění kvality před nasazením do produkčního prostředí jsou dané součtem první tří položek:

Cena zajištění kvality = Náklady na prevenci + Náklady na nalezení defektů + Náklady na opravu

Přínos těchto investic do kvality před uvedením systému do produkčního provozu vůči možným nákladům, které by bylo nutné vynaložit, kdybychom tyto investice/aktivity nerealizovali, pak ukazuje cena za kvalitu:

Cena za kvalitu = Náklady vyvolané možným produkčním selháním – Cena zajištění kvality

Pro argumentaci opodstatnění investic do aktivit pro zajištění kvality je tedy pochopitelně nutné, aby byla cena za kvalitu kladným číslem. Zjednodušeně řečeno: má smysl testovat jen do té míry, pokud jsou náklady na testování nižší než náklady na řešení případných produkčních incidentů.

1.3Prostředky pro argumentaci hodnoty testování z praxe

Pro lepší ilustraci výše uvedeného uvádíme smyšlený příklad inspirovaný příběhem prezentovaným v úvodu kapitoly.

Projekt: Vývoj softwaru řídicí jednotky generátorů proudu v novém typu letounu.

1.3.1Fáze získání informací

Při diskuzi s architektem řešení, vedoucím vývoje a analytickým týmem se snažíme získat co nejvíce podrobností o technickém řešení, způsobu vývoje a případných specifikách. Z těchto diskuzí získáme následující výstupy:

Očekávané parametry vývoje:

■4,3 milionu řádků kódu,

■vývoj formou „Cleanroom Development“,[3]

■statistická chybovost 3 defekty na 1000 řádků kódu (zohledňuje způsob vývoje a zkušenosti z minula),

■odhad počtu chyb přítomných v softwaru řídicí jednotky: 12 900,

■celkové množství kódu ve všech systémech: 110 milionů řádků,

■odhad celkového počtu chyb přítomných v softwaru letounu: 330 000.

Další podklady:

■průměrný nálet na stroj: 25 000 hodin za 10 let.

Při prvotní diskuzi se sponzory procházíme business cíle projektu a vyjasníme si případné nedorozumění, abychom byli schopni správně uchopit cíle. Z diskuze získáme následující výstupy:

Business cíle:

■ROI po 1000 prodaných letadlech daného typu,

■splnění regulace DO-178B, DO-178C,

■dodání 3000 strojů do deseti let.

1.3.2Fáze přípravy argumentace

Argumentaci postavíme na požadavcích regulátora na maximální počty selhání dílčích závažností na letovou hodinu, které jsou prezentované v druhém sloupci tabulky 1.2.

Při zohlednění vstupních informací získaných v úvodní fázi dostáváme, že v prvních 10 letech bude souhrnný nálet 75 000 000 hodin. Po vynásobení maximálních regulátorem stanovených přípustných počtů selhání v důsledku dílčích závažností defektů získáváme maximální počty defektů uvedené ve třetím sloupci tabulky. Protože vyvíjíme pouze kód pro řídicí jednotku, je třeba násobit maximální počty přípustných defektů poměrem mezi řádky zdrojového kódu řídicí jednotky (4,3 milionů) a celkovými řádky zdrojového kódu (110 milionů). Tato výsledná hodnota je pak uvedena v posledním sloupci.

Tabulka 1.2: Maximální počty přípustných defektů podle požadavků regulátora

Závažnost defektu

Max. počet selhání za letovou hodinu

Max. počet přípustných defektů pro celé letadlo

Max. počet přípustných defektů pro řídicí jednotku

Katastrofické defekty

0,000000001

0,075

0,00293

Nebezpečné defekty

0,0000001

7,500

0,29318

Závažné defekty

0,00001

750,000

29,31818

Drobné defekty

0,001

75000,000

2931,81818

Z podobných historických projektů známe statistické rozložení pravděpodobnosti výskytu defektů pro jednotlivé závažnosti. Tato hodnota je uvedena v druhém sloupci tabulky 1.3. Prostým součinem očekávaného procenta defektů dílčí závažnosti s celkovým počtem odhadovaných defektů v řídicí jednotce (12 900) získáme hodnoty uvedené ve třetím sloupci. Pro kategorii katastrofických a nebezpečných defektů nám předchozí tabulka ukazuje, že v softwaru řídicí jednotky nesmí být žádný defekt (čtvrtý sloupec). Nižší závažnosti připouští nenulový počet defektů. Ve čtvrtém sloupci tabulky 1.3 tedy vypočítáme, kolik defektů musíme odhalit pro dílčí závažnosti, abychom splnili požadavky regulátora.

Tabulka 1.3: Odhady defektů v řídicí jednotce

Závažnost defektu

Statistické rozložení chyb podle závažnosti

Odhad počtu defektů

Procento defektů, které je nutné odhalit

Katastrofické defekty

3 %

387

100,00 %

Nebezpečné defekty

6 %

774

100,00 %

Závažné defekty

30 %

3870

99,24 %

Drobné defekty

61 %

7869

62,74 %

K dosažení této úrovně detekce jsme ocenili důkladné testy s pomocí techniky TMaP TOSM (Test Object Size Metter) popsané v kapitole 5, Odhadování pracnosti testovacích aktivit, s celkovými náklady přibližně 18 000 MD na přípravu a exekuci testů.

1.3.3Fáze použití argumentace

Při představení řešení testování sponzorům vždy představujeme hodnotu (produkty) testování napojenou na business cíle. Při prezentaci se snažíme používat business jazyk, technické detaily máme připravené, ale držíme je v záloze. Pár tipů pro efektivní argumentaci:

■Nenechte utopit sponzory v detailech.

■Buďte věcní, struční a konzistentní.

■Rozdělte pracnost testovacích aktivit na menší celky s přímou vazbou na cíle.

■Postupujte v prezentaci podle pořadí (priorit) business cílů, ne podle striktní logiky testování.

V případě extrémních pracností potřebných k naplnění původních business cílů sponzora nebo pracností, kde cítíte rozpor s očekáváním sponzora, připravte alternativní varianty návrhu testů. Vždy ale tyto varianty komunikujte společně s dopadem na původní business cíle. Pokud alternativní varianty nesou zvýšená rizika, tlumočte je řečí peněz (kolik nás bude stát případný projev a jaká je pravděpodobnost, že to nastane).

V praxi může často pomoci i získání souhlasu klíčových osob už před schvalovací schůzkou. Sponzor obvykle nedokáže adekvátnost ceny sám posoudit. Vyžádá si tedy názor přímých podřízených, kterým důvěřuje. Rozhodnutí pak založí na základě jejich odborného posouzeni a doporučení. S těmito zainteresovanými osobami by měl manažer testování návrh předem prodiskutovat. Měl by jim vysvětlit logiku, na níž je odhad založen, a měl by při zapracování do konečného návrhu vzít v potaz jejich zpětnou vazbu. V ideálním případě pak bude schvalovací schůzka už jen formalitou.

V případě, že naopak vidíme riziko, že někdo ze zúčastněných náš návrh nepodpoří, je dobré o tom se sponzorem jednat již před schůzkou (dobrý způsob je neformální jednání). Je zbytečné ztrácet čas sponzora projednáváním detailů návrhů, které stejně nemají podporu jeho expertního týmu (ať už je to díky velkému množství otevřených bodů, nebo kvůli nedostatečnému pochopení myšlenek stojících za návrhem). Je výhodné, pokud máme dobré (byť i nepřímé) spojení na sponzora, abychom měli možnost nejasnosti předem vyjasnit.

V neposlední řadě je důležitý aspekt důvěry. Pokud je vztah se sponzorem založen na důvěře, zvyšuje se v jeho očích váš kredit a sponzor je otevřenější argumentaci. A nemusí to být pouze argumentace pomocí tvrdých dat a faktů. Otevírá se možnost argumentovat formou „expertní rady“. Sponzor vás považuje v dané oblasti za odbornou a morální autoritu a má tendence přiklonit se k vašemu návrhu, protože „vy víte, co děláte, a jste tady expert“.

1.4Shrnutí

Kvalita softwaru a její garance má svojí cenu. Někdy je ale manažer testování ve složité situaci a je obtížné získat podporu a prostředky potřebné pro naplnění očekávání zadavatele. Je proto nutné tuto cenu vysvětlit a spárovat s argumenty a motivátory, kterým zadavatel (nebo sponzor) rozumí. Při argumentaci buďte transparentní, používejte příklady srozumitelné zadavateli, vždy klaďte důraz na hodnotu, kterou testování zákazníkovi přinese. Při argumentaci můžete využít vzorec určující cenu za kvalitu:

Cena za kvalitu = Náklady vyvolané možným produkčním selháním – Cena zajištění kvality

Cena za kvalitu tedy prezentuje fiktivní úspory prostředků, kterých jsme „dosáhli“ realizací opatření pro zajištění kvality. Hodnota investic do kvality (prevence + testování) musí být nižší než dopady případného předání nekvalitního produktu k užívání zákazníkovi.

Když přijde řada na argumentaci se zadavatelem, nepodceňujte přípravnou fázi, a to jak získávání informací (o technických detailech testovacího projektu, business motivátorech, obavách a motivaci sponzorů), tak i jejich přetavení do samotných argumentů.

Na schůzku přijďte připraveni, včas a v psychické pohodě. Vyslechněte si protistranu a v případě ostřejší výměny názorů se zdržte invektiv. Reagujte věcně, stručně a jazykem srozumitelným protistraně (pokud je protistrana z businessu, neutopte ji v přílišném množství technických detailů). V případě, že nedosáhnete shody, navrhněte další schůzku, kde proberete otevřené detaily (možná i v jiném složení). V případě shody nezapomeňte na písemnou rekapitulaci a odsouhlasení závěrů. Interpretace hodnoty testování sponzorům projektu nebo dalším business účastníkům projektu není raketová věda, je však nutné zohlednit rozdílný způsob uvažování a komunikace, než jaký používají lidé z IT oblasti.

[1] FAA: Bulletin 2015-NM-058-AD, 2015 Dostupné také zde: http://rgl.faa.gov/Regulatory_and_Guidance_Library/rgAD.nsf/0/584c7ee3b270fa3086257e38004d0f3e/$FILE/2015-09-07.pdf.

[2] Capgemini Europe: Cena za opravu defektů podle fáze, ve které jsou nalezeny, 2010. Dostupné na: http://www.capgemini.com.

[3] Cobb & Mills: Engineering Software Under Statistical QualityControl,Science Alliance, 1990.

2Role testování ve firmě avprojektu

Michal Doležel

Software neměli testovat jen jeho tvůrci, tvrdí jeden zklasických principů teorie testování. Lze se setkat isnázorem, že ani organizace vyvíjející software by neměla testovat své vlastní programy [1]. Zmíněné myšlenky vám patrně znějí povědomě arozhodně je nelze označit za novátorské. Právě naopak– ideje nezávislého testování lze sledovat již od konce 50. let 20. století (první testovací tým ustavený Geraldem M. Weinbergem[4]). Je možná až trochu paradoxní, že spostupem času lze opět pozorovat zvýšený zájem otyto principy. Jde však ozájem tak trochu jiný. Zmíněné principy jsou dnes zpochybňovány, především vsouvislosti srostoucí popularitou agilního vývoje ascelotýmovým přístupem kvývoji softwaru [2]. Jak to tedy je se skutečnou implementací teoretických principů vpraxi? Vpraxi vše závisí na kontextu, vněmž se testování odehrává, anahodnotách, které organizace vyznává.

Tématem této kapitoly je řízení testování aztoho vyplývající organizační problémy. Odpovíme si na otázku, jaké je místo testování vživotním cyklu projektu vývoje softwaru avrámci celé organizace, jaké jsou klíčové odlišnosti testování prováděného ve vodopádových aagilních projektech azda kpráci manažera testování stačí znalost procesů atzv. tvrdých technik.

2.1Testování neprobíhá ve vzduchoprázdnu

Osoby snedostatkem relevantních zkušeností ve vývoji softwaru vidí vtestování jenom klikání, avšak pragmatici ho považují za inženýrskou disciplínu azároveň za činnost utvářenou asilně ovlivňovanou kontextem, ve kterém se provádí. Tímto kontextem je nejčastěji konkrétní projekt realizovaný vkonkrétní organizaci. Každá organizace funguje vurčitém odvětví lidské činnosti, které předurčuje řadu charakteristik pro vývoj softwaru.

Zvažte tyto základní rozdíly:

■Firma zabývající se produktovým vývojem typového aplikačního softwaru (angl. commercial off-the-shelf, COTS software, neformálně známý také jako „krabicový software“).

■Vývoj individuálního softwaru vrámci projektu.

Jinak řečeno: Testujeme software pro tisíce zákazníků, nebo pro jednoho jedinečného?

Anebo se zamyslete nad nutností přistupovat kvývoji softwaru jako kplánované astrukturované činnosti:

■Špatně otestovaný software má zásadní vliv na bezpečnost, zdraví lidí; může ohrozit velké materiální hodnoty (angl. life critical, mission critical).

■Rozsáhlé testování není vnímáno jako ten nejdůležitější faktor, protože buď:

-není vdaném případě efektivní, nebo

-je třeba produkt rychle uvést na trh vminimální životaschopné formě (angl. minimal viable product).

Přeneseně řečeno: Stavíme most přes záliv, nebo kůlnu na uhlí, které nám pozítří přivezou? [3]

Tato adalší specifika spoluvytvářejí určitou filosofii testování, kterou organizace vyznává. Podívejme se na některá specifika blíže.

Představte si situaci, že jako noví zaměstnanci– profesionálové voblasti testování– právě nastupujete do vysněné firmy. Obvykle první, po čem budete pátrat, je dozvědět se, jak se vlastně unich testuje. Mnoho lidí se nejdříve bude ptát na metodiku testování. Další se budou ptát na nástroje používané ktestování ajeho automatizaci. Nic proti tomu. Ale možná by bylo jednodušší si nejprve položit otázku trošku obecnější: „Jak se uvás vyvíjí software?“ Pamatujte– testování bývalo dříve často chápáno vsouvislosti svývojem softwaru jako činnost prováděná „úplně na konci“ (což je nevhodný přístup, vedoucí kpoměrně velké neefektivitě) adosud se ztoho tak trochu vzpamatovává. Moderní přístupy ktestování však sází na provázanost sdalšími činnostmi prováděnými vývojovými týmy.

Na testování tedy nenahlížejte jako na izolovanou aktivitu asvé výsostné království. Je důležité si uvědomit, že za některé věci jste zodpovědní vy, specialisté voblasti testování, amnoho lidí vám do nich mluvit nebude. Ale mnoho věcí závisí na jiných členech organizace– např. na projektových manažerech, oddělení řízení rizik, vedoucím vývoje. Vy je musíte vzít jako dané, či alespoň jako aktuální realitu, kterou se můžete později pokusit změnit. Jak se sostatními domluvit akde vůbec začít?

Začněte třeba usjednocení vašich očekávání týkajících se způsobu softwarového vývoje. Ptejte se, jaký model či metodika se používá vživotním cyklu vývoje systémů či softwaru,[5] vangličtině nazývaném systems/software development life cycle (SDLC). Životní cyklus zahrnuje časový úsek od nasazení systému až po jeho vyřazení zprovozu [4, 5]. Použitá metodika (či metodiky) uvnitř tohoto životního cyklu představují jeden znejdůležitějších faktorů, který předurčuje filosofii testování právě ve vaší organizaci.

Můžete dostat velice zajímavé odpovědi, jako třeba:

■„Je to víceméně vodopád“, což si můžete přeložit jako „vedení věří na disciplínu, ale my nižší manažeři nemáme sílu ji vymáhat“, popřípadě „všichni mají času dost ahrají si na svém písečku, pouze testování na konci se většinou tak trochu nestihne.“

■„My fungujeme agilně, jen oddělení testování nám to kazí“, což můžete chápat jako vymezení očekávání vůči vám, jako novým manažerům testování či testerům, azároveň jako indikaci, že se určitě oryzí agilní přístup zahrnující společné anedělitelné odpovědnosti vtomto případě nejedná.

■„Fungujeme tak, jak to chce daný ‚projekťák‘, většinou tak něco mezi.“ Může to ukazovat, že projektová kancelář má patrně poměrně silné slovo ivoblasti vývoje softwaru amanažeři vývoje se možná „tak trochu vezou“.

Ať tak či tak, je užitečné si začít kreslit apřemýšlet, jak se vdané firmě software tedy vlastně vyvíjí, zda jsou jednotlivé fáze oddělené akdo přesně je za ně odpovědný. Zároveň je nutné ptát se po tom, zda to vdané organizaci takto skutečně funguje, či zda jde jen oteorii. Zpraktických zkušeností totiž vyplývá, že pokud není sladěn formalizovaný životní cyklus vývoje softwaru sorganizační realitou, musí nutně dojít kproblémům [6].

Jedna zmožností, jak oproblematice uvažovat vobecné rovině, je zobrazena na obrázku 2.1 formou modelu obecného životního cyklu vývoje systémů zasazeného do organizačního kontextu.

Obrázek 2.1: Příklad znázornění SDLC – model průběžného rozvoje systému vkontextu konkrétní organizace

Obrázek 2.1 znázorňuje obecný sled činností vykonávaných vsouvislosti svývojem aprovozem určitého softwarového systému. Formou znázornění jednotlivých etap (fází) jsou vjeho pravé části zachyceny zásadní aktivity zahrnující vše od sběru požadavků, konceptuálního návrhu systému, vývoje (nebo nákupu) atestování systému až po nasazení systému do produkčníhoprovozu. Na tyto aktivity se přitom lze dívat různými způsoby. Obrázek 2.1 konkrétně znázorňuje situaci, kdy osoftwarovém systému uvažujeme zpohledu určité organizace jako odlouhodobé aktivitě. Systém vnímáme jako řešení, které např. svlastními zaměstnanci vymyslíme, navrhneme apak určitým způsobem realizujeme. To typicky bude mít podobu:

■zapojení oddělení vývoje, ve kterém jsou zaměstnáni programátoři,

■využití dodavatelské firmy,

■pouhého nákupu apřípadné úpravy hotového řešení (software typu COTS), pokud je kdispozici.

Následně řešení nasadíme do provozu (obvykle opět vlastními zaměstnanci) apak vprovozu dlouhodobě udržujeme. Rovněž toto řešení průběžně rozvíjíme, buď interními prostředky, či svyužitím dodavatelů. Tento pohled tedy jasně zdůrazňuje dlouhodobou perspektivu vkontextu konkrétní organizace včetně následné údržby systému, nikoliv projektový pohled. Pohříchu však bývá tento dlouhodobý pohled často opomíjen, snad právě pod tlakem projektového pohledu na věc.

Pro střední avelké organizace schéma uvedené na obrázku 2.1 představuje dobrý způsob, jak vysvětlit dělbu odpovědností zprojektového hlediska. Pro jednoduchost neuvažujeme možnost svěření těchto činností dodavateli. Odpovědnosti bývají rozděleny takto:

■Za sběr azákladní analýzu požadavků odpovídá typicky business analytik zněkterého oddělení businessu (typický zadavatel vývoje IT systémů firmy).

■Za návrh nového systému či ověření technických parametrů hotového řešení (technickou analýzu) zodpovídá analytik IT vývoje.

■Za vývoj systému zodpovídá manažer IT vývoje, za testování systému zodpovídá manažer testování.

■Za nasazení apodporu systému zodpovídá manažer provozu IT systémů.

Jednotlivé odpovědnosti se předávají více či méně formalizovaným procesem spolu sodpovídajícími artefakty (specifikace požadavků, technická dokumentace, vlastní aplikace atd.). Za zmínku stojí zejména často velmi formální předávání odpovědností mezi odděleními vývoje aprovozu. To je typicky spojené mimo jiné snároky na správnost související dokumentace používané pro podporu provozu. Během celého trvání bývají výše uvedené aktivity řízeny projektovým manažerem, případně dvěma projektovými manažery (za IT abusiness). Zcela jsme pominuli roli business aIT architektů, kteří mají do procesu možnost vstupovat, pokud jsou tyto složky ve větších organizacích zřízeny.

Nevýhodou schématu uvedeného na obrázku 2.1 je, že znázornění jednotlivých fází testování vtomto životním cyklu je velmi zběžné. Obrázek je tak použitelný především pro diskuzi na konceptuální úrovni sjednotlivými funkčními oblastmi vorganizaci– business, oddělení vývoje, oddělení provozu atd. Pro diskuze otestování je vhodné znázornění jiné, ke kterému dojdeme níže. Nejprve si však popíšeme faktory, jež mají zásadní vliv na způsob, jak tento sled činností realizujeme.

2.2Faktory ovlivňující průběh aformu životního cyklu

Vlevé části obrázku 2.1 jsou znázorněny jednotlivé faktory, které zásadním způsobem vstupují do naznačeného idealizovaného modelu. Tyto faktory je možné rozdělit na externí (nacházející se mimo danou organizaci) ainterní (mající původ vdané organizaci).

Externí faktory:

■Obchodní aspekty atlak konkurence jsou faktorem zcela zásadním. Vdnešní době platí, že se tempo uvádění nových produktů na trh neustále zvyšuje. Rovněž platí, že mnoho dříve stabilních odvětví je zasaženo digitální transformací a„znepokojivým“ (zhlediska původních subjektů) vstupem nových digitálních hráčů [7]. (Zvažte například současnou situaci voblasti poskytování taxislužeb.) Vliv digitální transformace na testování je zásadní [8]. Pro mnoho organizací tvoří softwarové systémy klíčovou část jejich produktů. Software tedy nemůže zůstat pozadu amusí se přizpůsobit tak, aby co nejlépe podporoval hlavní obchodní procesy organizace, na něž je navázán. Pochopitelně to ovlivňuje čas, který je kdispozici na jeho vývoj atestování (angl. time to market).

■Požadavky zákonů, regulatorních orgánů aauditu lze chápat jako faktor působící zcela opačným směrem, tzn. jako inhibitor inovace. Většinou směřuje kbezpečnosti (ve smyslu anglického slova safety) aspolehlivosti systémů anacházíme ho zejména vodvětvích jako lékařství, farmacie, letecký průmysl adoprava obecně, finančnictví atd. Cílem je stabilita apředvídatelnost chování IT systémů. Pro oblast testování softwaru je tento faktor zcela zásadní.

■Tradice, znalosti azkušenosti dostupné vexterním prostředí jsou faktorem doplňkovým. Mnoho organizací se logicky řídí tím, co vnímá jako dobré praktiky odpozorované odjinud. Tím není myšlena jen odborná literatura, konference, certifikace apod., ale ivliv konzultantských firem aakademické sféry. Všechny tyto složky utvářejí vnímání ideálního přístupu křízení testování softwaru, např. zda je jím přístup ktestování podle ISTQB[6], či škola context-driven [9]. České prostředí je přitom tak trochu unikátní. Například již vroce 2004 upozorňoval Branislav Lacko, že vČeské republice panuje určitá nechuť kformálním metodám tvorby softwaru aprocesně orientovaným manažerským konceptům [10]. Lze říci, že tato nechuť mnohde přetrvala do současnosti. Přesto však všechny organizace používají pro svůj životní cyklus systémů vědomě či nevědomě určitý model vývoje, byť nejednou zcela neformalizovaný. Velmi často podobný model vychází zpředstav chápajících vývoj softwaru jako logický sled aktivit (vodopádový model). Naopak mnoho organizací dnes zavádí agilní vývoj (viz dále). Občas však spíše proto, že je to módní [11, 12] a„dělá se to všude“, než proto, že by věřily vzákladní filozofii agilního hnutí.[7]

Zjednodušeně lze říci, že mezi externími ainterními faktory existuje jednosměrná závislost. Externí ovlivňují ty interní. Navíc se pochopitelně mohou interní ovlivňovat inavzájem.

Mezi interní faktory patří:

■Způsob řízení požadavků. Komunikuje business požadavky na poslední chvíli? Mění často zadaní bez ohledu na důsledky? Ignoruje obecně plánování vývojových kapacit azaštiťuje se přitom osobou generálního ředitele jako původce tohoto „zla“ („Generální rozhodl, že to musí být vtomto releasu“)? Všechny tyto možné scénáře mají bezprostřední vliv na kvalitu vyvíjeného softwaru, potažmo na podmínky, vnichž testovací tým musí pracovat. Pátrejte po nich. Zamyslete se přitom nad souvislostí tohoto faktoru sexterním faktorem označeným jako Obchodní aspekty atlak konkurence.

■Organizační kulturu obecně nelze pominout. Zaměřit se voblasti vývoje atestování softwarových systémů pouze na technickou či nástrojovou stránku věci je častou chybou. Právě organizační kultura totiž zásadně předurčuje úspěšnost mnoha vašich kroků [13]. Zamyslete se nad souvislostí tohoto faktoru avlivu regulatorních požadavků. Je vaše organizační kultura formována tlakem zvnějšku, nebo jde ohistorický vývoj organizace?

■Nákladové aspekty mohou vtomto souhrnu vypadat nepatřičně. Faktem však je, že pro organizace je finanční stránka jejich fungování kritická. Proto je mnoho organizací neustále pod tlakem různých iniciativ vedoucích kpotenciálním úsporám, které často zasahují iIT. Nekončící debaty opodílu outsourcingu ainsourcingu (viz kapitolu 13, Outsourcing adalší strategie dodávky testování), tvrdším přístupu kdodavatelům, snižování alokace prostředků dostupných na rozvoj softwarových systémů aminimalizace provozních nákladů IT oddělení patří ke koloritu mnoha firem. Pochopitelně mají zásadní dopad ina testování, které je často vnímáno jako „příliš drahé“. Zamyslete se nad vztahem tohoto faktoru např. vzhledem kodvětví, vněmž působí vaše organizace– vregulovaných odvětvích bude snaha ušetřit na testování patrně oněco nižší.

■Konkrétní metodiky vývoje aprovozu jsou pochopitelně pro oblast testování zcela zásadním faktorem. Souvisí nejen sorganizační kulturou, ale velmi často je její volba předurčena buď hodnotami, které organizace vyznává, nebo jednoduše „pokynem daným shora“. Ten bývá často formován právě aktuálními „módními trendy“ atzv. „hype křivkou“ [12] (viz diskuzi výše).

Poslední faktor je pro práci profesionálů voblasti testování natolik zásadní, že se na něj vdalším textu zaměříme podrobněji.

2.3Metodiky vývoje, testování aprovozu

Vsouvislosti svývojem, provozem, projektovým řízením atestováním často mluvíme ometodikách. Vobecném smyslu jde opostupy avodítka, které nám mají být nápomocné křešení určité situace. Ometodikách toho můžeme nalézt vliteratuře mnohé, včeštině je např. dostupná kniha srovnávající různé metodiky používané pro tvorbu informačních systémů [14]. Formální definici metodiky naleznete vrámečku níže.

Metodika je souhrn vodítek aprincipů, které mohou být přizpůsobeny aaplikovány na řešení určité situace. Může jít jak ojednoduchý soupis akcí, které se mají vykonat, tak ospecifický přístup, šablony, formuláře, popřípadě kontrolní seznamy. [15]

Pro účely tohoto textu ometodice uvažujeme jako okonkrétním návodu, jak realizovat určité činnosti vprůběhu životního cyklu systému. Vtomto významu bude metodika interním dokumentem organizace, který je připravován právě sohledem na její specifické potřeby. Obecně však může vycházet třeba zvodopádového či jiného modelu vývoje softwaru nebo ze sady praktik pro řízení IT služeb (angl. IT Service Management). Voblasti řízení projektu může vycházet třeba zmetodikyPMBOK od Project Management Institutu či zPRINCE2.[8]

Voblasti organizace testování softwaru se často mluví ofiremní metodice testování. Té mohou být podřízeny všechny testovací činnosti vykonávané na různých projektech vrámci téže organizace scílem zajistit podobný přístup ktestování softwaru napříč celou organizací. Dokumenty politika testování (angl. test policy) astrategie testování[9] (angl. test strategy) podle terminologie ISTQB mohou tvořit základ této firemní metodiky testování.

Středobodem mnoha firemních metodik (astrategií) testování je V-model. Je to model životního cyklu zdůrazňující oblast testování. Níže se na něj podíváme.

2.3.1Vmodel aW model: totéž, jen jinak?

V-model byl definovaný vdruhé polovině osmdesátých let 20. století [16]. Je to model životního cyklu, který je testerům poměrně blízký avelmi často vštěpovaný. Strochou nadsázky můžeme dokonce říci, že V-model byl vminulosti hybatelem jedné zprvních revolucí testerů. Zdůraznění testování jako aktivity srovnatelně velkého významu snávrhem aprogramováním systému totiž nepochybně ovlivnilo chápání úlohy testování již před 30 lety apřetrvalo do dnešních dnů (viz syllabus ISTQB).

Vprincipu však jde vpřípadě V-modelu pouze ovariaci všeobecně známého vodopádového modelu. Aprávě způsob rozšíření vodopádového modelu (doplnění do tvaru písmene V) dal V-modelu jméno. Jedna zjednodušších variant V-modelu (vycházející způvodního návrhu Rooka [16]) je znázorněna na obrázku 2.2.

Obrázek 2.2: V-model

V-model tvoří několik dvojic aktivit (specifikace požadavků– uživatelské akceptační testy, hrubý návrh– systémové testy, detailní návrh– integrační testy, programování– jednotkové testy). Na levé straně se přitom nacházejí aktivity související se specifikací anávrhem, na pravé aktivity testování (dynamického = nad spuštěnou aplikací). Tím je zdůrazněna úloha testování ve vazbě na odpovídající analytické aktivity asouvisející artefakty. Naznačená varianta V-modelu nezapomíná ani na to, že ne všechny požadavky bývají explicitně specifikované. Vpraxi se mnoho požadavků mlčky předpokládá (např. „systém bude stabilní“, „uživatelské rozhraní bude intuitivní“)– viz druhý horní box na levé straně V-modelu. Naznačené oddělení odpovědnosti odběratele adodavatele (popisek úplně vpravo) je typické, nikoliv však jediné možné.

Vsouhrnu nám V-model říká, že nestačí systém pouze správně navrhnout (analyzovat) arealizovat (naprogramovat), ale vurčitých časových okamžicích je třeba zařadit testování jako nástroj pro ověření návrhu arealizace. Těmto časovým úsekům se později začalo říkat úrovně testování (angl. test levels). Podle slovníku ISTQB je úroveň testování definována jako „skupina testovacích aktivit, které jsou společně organizovány ařízeny“.

Vsoučasnosti se ooddělených úrovních testování uvažuje nejčastěji jako ojednom zkritérií vyspělosti procesů testování vurčité organizaci či na určitém projektu. Rex Black, klasik voblasti řízení testování [6], na základě své osobní zkušenosti dokonce tvrdí, že nejúspěšnější projekty jsou ty, jež mají jasně oddělené úrovně testování astím svázané odlišné cíle aodpovědnosti.[10] Rovněž model pro zlepšování procesů testování TMMi[11] chápe jako vyspělejší organizace, ve kterých jsou sledovány na různých úrovních testování odlišné cíle (úroveň 2 vtomto modelu). Achápání testování jako specifické profese vrámci určité organizace je vtomto modelu dokonce jednou zpodmínek posunutí na úroveň vyspělosti 3. Avšak vžádném případě to neznamená, že bychom měli snižovat důležitost testování prováděného programátory. Je tomu právě naopak. Úloha programátorů na nižších úrovních testování je nedocenitelná. Ve zdravě fungujících organizacích programátoři nacházejí většinu svých vlastních chyb– adělají to levněji než později testeři [17].

Realita je však často komplikovanější než jakýkoliv model. Značně idealizovaný V-model místo pozvolného sestupu anásledného výšlapu často vreálných organizacích končí jako „sjezdovka následovaná útesem“ [6]. Na pravou část V-modelu tak občas vůbec nedojde, protože všechny úrovně testování přicházejí ke slovu zrůzných důvodů až svelkým zpožděním, ato vposledních dnech vyčleněných projektovým plánem na uživatelské akceptační testy. Nejde však vždy nutně oproblém V-modelu, ale spíše ozpůsob uvažování mnoha manažerů či vývojářů. Ukrajovat častestování se dá poměrně jednoduše azdánlivě bez viditelných následků. Je to však pochopitelně nesmysl avelké množství chyb nalezených až vzávěru projektu nás ztakového omylu vyvede.

Se znázorněnímV-modelu jsou svázané idva další nedostatky.[12] Prvním je přílišná idealizace jednoznačnosti vztahu mezi jednotlivými úrovněmi návrhu atestování. Vrealitě jen málokdy vystačíme např. vúrovni systémového testování sjedním druhem specifikace. Také nemůžeme anechceme abstrahovat od reálných ačasto explicitně nespecifikovaných potřeb koncového uživatele. Amnohdy musíme řešit itechnické problémy, které by formálně náležely na zcela jinou úroveň testování. Druhý nedostatek je spojený snedoceňováním potenciálního přínosu testerů. Testeři se do hry vmnoha organizacích dostávají zbytečně pozdě aidealizovaný nákres V-modelu tento pohled podporuje, ač to tak původně vůbec nebylo zamýšleno [16]. Organizace tak zhusta pomíjejí důležitost včasných revizí specifikací (statického testování– viz kapitoly 7, Ověřování požadavků, a6, Statické testování) prováděných kritickým anezávislým pohledem testera [18]. Jak ztoho ven?

Možnou odpovědí na tyto nedostatky V-modelu je méně známý W-model, zobrazený na obrázku 2.3. Toto chápání životního cyklu vývoje systémů zdůrazňuje především důležitost včasného zapojení testerů již vraných fázích vývoje (levá strana W-modelu) adává do přímé souvislosti vývojové atestovací aktivity (pravá strana W-modelu). Model tak zásadně rozšiřuje úzké chápání pojetí testování ve smyslu zkoumání softwaru při jeho běhu. Testery tak upozorňuje, že se mají zapojovat jako aktivní ovlivňovatelé dění již mnohem dříve než vúrovních integračního či systémového testování. Se systémem musí žít takříkajíc hned od počátku– od high-level business požadavků přes statické testování jednotlivých fází návrhu až po kontrolu nad průběhem jednotlivých úrovní dynamických testů. Protože testování funkcionalit je jen jednou zmnoha činností, jsou ve W-modelu úplně vpravo zmíněny iněkteré další obvyklé typy testů. Ty nejsou vztažené kjedné konkrétní úrovni testování– např. průzkumné testování bude využito typicky ve všech úrovních.

Obrázek 2.3: W-model

Možná se budete trochu divit ařeknete si, co je vlastně na W-modelu tak objevného. Vždyť tyto principy jsou přece každému alespoň teoreticky známé amožná jste se je dokonce pokusili ve své organizaci aplikovat. Pokud ano, je možné, že jste uspěli. Většině se to však zrůzných důvodů nedaří. Pokud stouto problematikou dosud osobní zkušenost nemáte, buďte připraveni na to, že ne každý manažer vývoje či projektu bude mít pro podobné metody pochopení. Někdo bude argumentovat náklady, někdo nedostatkem času, udalších zase narazíte, protožechápou testery jako „podřadnější“ členy týmu, kterým nemá smysl požadavky podrobně vysvětlovat. Vše toto je nepochybně špatně. Ale vmnoha organizacích je potom problém ještě fundamentálnější– požadavky jsou záměrně zadávány mlhavě, spoukazem na domnělou flexibilitu [19]. Tam je pak každá rada drahá.

Také byste měli vědět, že mnoho teoretiků (ale ipraktiků) nemusí nutně chápat revize jako aktivitu testerům přirozeně náležející. Testování mohou chápat pouze vúzkém pojetí tohoto slova– spouštění aprověřování činnosti systémů během jejich běhu (tedy dynamické testování). Ze zkušeností však vyplývá, že testeři bývají kzastávání rolí voblasti statického testování velmi dobře vybaveni aměli by kní být cíleně směrováni [18]. Tento přístup arozšíření úlohy testerů lze dnes doporučit,[13] ačkoliv původně byly pojmy asouvisející odpovědnosti vtestování, verifikace avalidace striktně oddělovány [16].

Pojmy verifikace, validace atestování jsou chápány odlišně nejen vpraxi, ale ivteorii softwarového inženýrství. My se vtéto knize držíme významu podle definic zglosáře ISTQB.

Verifikace je potvrzení získané zkoumáním adoložením objektivních důkazů, že specifikované požadavky byly naplněny.

Validace je potvrzení získané zkoumáním adoložením objektivních důkazů, že skutečné požadavky pro určité zamýšlené použití či nasazení byly naplněny.

Vtomto významu se vymezení verifikace avalidace částečně překrývá spojmy statické adynamické testování.

Podrobnější vysvětlení odlišnosti pojmů testování, verifikace avalidace:

Klasický přístup kvysvětlení rozdílů mezi verifikací avalidací souvisí spoložením dvou otázek [16, 20]. Zatímco verifikace znamená ptát se: „Vytváříme produkt správně?“, validace pátrá po odpovědi na otázku: „Vytváříme správný produkt?“ Co to přesně znamená? Verifikace souvisí sověřováním formálních aspektů vývoje softwarového systému, např. snaplněním očekávání na formalizované výstupy definovaného procesu vrámci určité etapy či shody písemné specifikace požadavků sreálně vytvořeným systémem („Je náš postup správný?“). Validace se zaměřuje na dokázání toho, že systém je připraven sohledem na reálné požadavky uživatele, na jakousi očekávanou „provozní misi“ systému. „Dostali jsme opravdu to, co jsme chtěli?“– tak se můžeme zeptat sohledem na zcela pozapomenuté či jen špatně formulované písemné požadavky.

Validace byla tradičně (avšak nedostatečně) chápána jako činnost nacházející se až na konci celého vývojového procesu. Příkladem typické techniky je dynamické testování vúrovni uživatelských akceptačních testů. Protože kvývoji kvalitních softwarových systémů je zapotřebí souhra jak verifikace, tak validace, atyto aktivity se rovněž překrývají stestováním, často se tyto techniky souhrnně označují jako „verifikace avalidace“ (verification & validation, V&V), bez bližšího rozlišování. Oblast testování lze pak vširokém významu chápat jako nadřazenou procesům verifikace avalidace. Ktématu lze doporučit kapitolu „Revize jako testovací aktivita“ vpublikaci [18], která nabízí rozsáhlou polemiku, proč je podobné chápání užitečné.

Dopad na praxi: Dynamické testování prováděné programátory při vývoji či integraci má často charakter verifikace– testuje se oproti písemné specifikaci požadavků, rozhraní apod. Pro testery business oddělení vúrovni uživatelských akceptačních tesů či pro zkušené asebevědomé testery vúrovni systémových testů naproti tomu bude psaná specifikace pouze „zeď, která se dá zbourat“. A„bourání“ je třeba zahájit co nejdříve. Provádějí totiž validaci. Velká přidaná hodnota W-modelu spočívá právě vrozpoznání nutnosti rozšíření apřesunutí těžiště technik validace zkonce vývojového cyklu na jeho začátek, tzn. včasném zapojení těchto skupin např. do procesu revize požadavků (viz kapitolu 7, Ověřování požadavků).

2.3.2Agilní přístup

Ačkoliv je snámi agilní přístup již více než patnáct let, do mnoha středních avelkých organizací dorazil relativně nedávno. Za bibli agilního přístupu se považuje Agilní manifest.[14] Ten se vroce 2001 stal prostředkem kvyjádření nespokojenosti stradičními metodami vývoje softwaru asvazováním vývojářské kreativity byrokratickými procesními koncepty apřemírou dokumentace. Obdobně brojí protiupozadění reálných potřeb koncového uživatele jako klíčového činitele vprocesu vývoje softwaru. Dalším základním tématem je připravenost na změnu. Mění se požadavky, lidé vprojektu, používané technologie. Proto ani vývojový proces nemůže zůstat statický, ale pomocí krátkých smyček zpětné vazby musí docházet kjeho přizpůsobení [21].

Vodvětví existuje velké množství agilních metodik arámců, které mohou jednotlivé organizace používat. Nebudeme se zde zabývat ani jejich přehledem, ani detaily týkajícími se výhod anevýhod agilního vývoje. Tyto informace jsou poměrně snadno dostupné včeské [14] izahraniční literatuře [21]. Jedno téma je však nutné zmínit: velkou změnu procesu testování, ato ze samé podstaty agilních metodik. Problémem však je, že ani Agilní manifest, ani jednotlivé metodiky nenabízejí na otázky týkající se „agilního testování“[15] explicitní odpovědi. Ty nám často poskytuje až praxe, případně kniha průkopnic „agilního testování“ Lisy Crispin aJanet Gregory [2]. Níže je tak jen stručně naznačeno, sjakými problémy se lze vpraxi setkat.

Jedna ze zásadních změn se vagilním prostředí děje voblasti vztahů mezi vývojáři atestery. Kvalita se stává středobodem zájmu celého týmu, tudíž ispolečně sdílenou odpovědností. To by pochopitelně mělo mít dopad na vzorce chování vtýmu, na zájem všech členů otestování apodobně, na dělbu odpovědností mezi vývojáři atestery. Zmíněný posun sekundárně ovlivňuje náborovou praxi aideální profil uchazečů opozice „agilního testera“. Organizace obvykle volí cestu testerů-univerzalistů, kteří jsou pro tým průvodci nejen votázkách automatizace, ale musí zvládat imnoho úloh dříve zastávaných manažerem testování.

Zprocesního hlediska je jasné, že agilní praktiky jdou proti samotné podstatě standardizace procesů formou metodik. Proto je tvorba konkrétní anapříč organizací standardizované „metodiky agilního testování“ do značné míry záležitost značně iluzorní. Snad lépe než ometodice agilního testování je vhodnější přemýšlet osdílení znalostí, zkušeností adovedností formou tzv. komunit testerů (angl. community of testers, community of practice for testing) [2]. To vše pochopitelně způsobuje, že pro mnoho středních avelkých organizací se agilní vývoj stává něčím obtížně uchopitelným. Ze své podstaty vnich totiž musí nutně měnit některé zažité vzorce odpovědností. Těžiště moci se vorganizacích posouvá daleko blíže kagilním týmům [21]. Ana to není každá organizace připravena. Ostatně, rozhodnutí onasazení agilních metod ovlivňuje způsob fungování celé organizace. Myšlenka, že lze vybudovat dlouhodobě funkční agilní tým jen jako izolovaný ostrov uvnitř organizace klasického hierarchického typu, je poměrně kontroverzní.

Tabulka 2.1 poskytuje stručný souhrn základních charakteristik projektů řízených tradiční metodikou (založenou často na vodopádovém životním cyklu) aagilní metodikou.

Tabulka 2.1: Srovnání některých aspektů tradičních aagilních metodik

Tradiční metodiky

Agilní metodiky

Logika fungování vývojového týmu

Předem pevně definovaná

Empirická (ad-hoc modifikovatelná)

Stupeň formalizace procesů

Vysoký

Nízký

Zdroj procesního know-how

Standardizace

Dobré praktiky vodvětví jako celku

Každý tým si najde nejlépe vyhovující individuální přístup

Neformální sdílení napříč týmy vorganizaci

Profesní tradice

Inženýrství

Řemeslo

Použití

Zejména komplexní projekty adistribuované týmy

Zejména malé týmy nacházející se na jednom místě

Metafora

Stavba kancelářské budovy svyužitím několika dodavatelských firem

Stavba rekreační chaty svépomocí [16]

Klíčové sociální faktory

Plánování akontrola

Zmocňování ( empowerment) adůvěra

Obecná rétorika

Plán, proces, trasovatelnost (požadavků aj.), standardizace, bezpečnost

Improvizace, inovace, hodnota pro uživatele, rychlost, spolupráce

Typický pohled na časovou stálost

Projekt = časově ohraničený úsek

Produkt = dlouhodobý rozvoj

Požadavky uživatelů

Předem pevně dané (vpřípadě změn podléhající složitému změnovému řízení)

Modifikovatelné před každou iterací

Zapojení uživatelů

Začátek akonec vývojového procesu  → nároky na promyšlenost hned od počátku

Průběžné, např. po každé iteraci  → nároky na čas uživatelů apřijetí osobní odpovědnosti za rozhodování (!)

Zásadní riziko

Vyvíjíme něco, co uživatel vůbec nechce, azjistíme to příliš pozdě

Zbrklý přístup může vkomplexním prostředí způsobit nákladnost řešení anesoulad spodnikovou architekturou

Organizace vývoje atestování

Hierarchická

Samoorganizující se tým

Organizační filosofie

Management

Leadership každého člena + podpůrná úloha „pastýře/ů“ (např. role Scrum Mastera)

Úloha testerů

„Strážci brány– ochránci uživatelů“

„Průvodci programátorů vdžungli kvality“

Specializace testerů

Specialisté (manažer testování, analytik testování, tester, vývojář automatizovaných testů…)

Univerzalisté nazývaní např. inženýři testování/kvality

Externí vlivy posilující pozici

Tradice

Zákonné regulace aaudit (motivovány požadavky na bezpečnost aspolehlivost)

Úloha softwaru ve společnosti 21. století– nutnost rychle reagovat na jednání konkurence

2.3.3DevOps jako spojení vývoje aprovozu

Svět provozu IT systémů představuje oproti světu vývoje jinou realitu. Ale této realitě mohou málokdy specialisté na testování zcela uniknout, třeba když budou muset vysvětlit: „Co je to vlastně ten agilní vývoj“ a„Proč není tolik testovací dokumentace, jak bývalo dřív“. Následující krátká zmínka by vám měla pomoci najít „ve světě provozu“ pár záchytných bodů…

Minimálně ve středních avelkých organizacích se tradičně používají pro řízení provozních apodpůrných činností přístupy, které nevycházejí zmetodik vývoje softwarových systémů. Jde buď ojiž zmíněné formálně sepsané interní metodiky, nebo oneformální chápání, unás nejčastěji těžící zrámců (konceptů):

■ITIL (Information Technology Infrastructure Library)– velmi populární,

■COBIT (Control Objectives for Information and Related Technology)– populární zejména ve finanční sféře kvůli regulatorním požadavkům,

■MBI (Management of Business Informatics[17])– méně známý český rámec cílený na malé astřední firmy [22, 23].

Tyto rámce historicky vzešly ze zcela jiných tradic než vývoj softwarových systémů, aproto „mluví jiným jazykem“, podobně jako lidé pohybující se vprovozu IT systémů. Ostatně, možná si uvědomujete, že ooddělení provozu ve vaší firmě jakožto profesionálové voblasti testování obecně mnoho nevíte.

Ale měli byste vědět. Překlenutí výše zmíněné propasti mezi oběma světy je obecně velmi žádoucí. Vté souvislosti se mluví oDevOps: jde osloženinu slov Development (vývoj) aOperations (provoz). Jde oprofesní akulturní hnutí zdůrazňující nutnost odstranění všech bariér mezi odděleními vývoje, provozu atestování. Vlastně se jedná jen opřirozené rozšíření konceptu agilního vývoje na oblast provozu systémů. Zásadní elementy při transformaci organizace směrem ktomuto konceptu jsou shrnuty akronymem CAMS (Culture– Automation– Measurement– Sharing). Cílená změna organizační kultury, maximální automatizace (mimo jiné voblasti vývojových, testovacích aprovozních prostředí), důraz na průběžná měření (zavedení systému metrik) avneposlední řadě důraz na sdílení odpovědnosti iproblémů [24]. Přestože lze DevOps chápat jako komplexní fenomén aočekávaný trend ovlivňující mnoho oblastí testování, jsou bohužel naše možnosti věnovat se tomuto konceptu vtéto knize zprostorových důvodů značně omezené. Další odkaz na koncept DevOps, tentokrát zpohledu organizace testovacího prostředí, najdete vkapitole 8, Testovací prostředí.

Výše jsme otevřeli důležitý problém, totiž vztah různých oddělení vrámci organizace asouvisející vliv na vaši práci. Klíčové však vtéto souvislosti je, jak je uvnitř firmy organizováno samotné oddělení testování, jaké má pravomoci aodpovědnosti. Otom si řekneme více nyní.

2.4Jak zapadá oddělení testování do organizace jako takové?

Předně je si nutné odpovědět na otázku: Jaké vlastně jsou pravomoci aposlání oddělení testování/kvality vorganizaci, pro niž pracuji či dodávám? Patří mezi ně imožnost:

■Přijímat složitá rozhodnutí včetně zastavení dodávky?

■Být šampiónem aadvokátem kvality nejen pro testery, ale ipro vývojáře?

■Zlepšovat softwarové procesy nejen vrámci testování, ale ive vývoji?

■Definovat nástroje, které budou používány vprocesu vývoje?

Vrealitě se je možné setkat se třemi běžnými způsoby fungování oddělení testování, které můžeme charakterizovat následujícími názvy [17]:

2.5Role manažera testování

■Interpersonální role– manažer jako ceremoniář, lídr aspojka.

2.5.1Interpersonální role

2.5.2Informační role

2.5.3Rozhodovací role

2.6Shrnutí

Table of Contents

Úvod

Pro jaké typy projektů a domény se kniha hodí?

Jak je kniha strukturovaná

Komu je kniha určená?

Použitá terminologie

O autorech

Poděkování

1 Businessová hodnota testování

1.1 Kam mohou vyšplhat náklady za nedostatečnou kvalitu

1.2 Výpočet ceny za kvalitu

1.3 Prostředky pro argumentaci hodnoty testování z praxe

1.3.1 Fáze získání informací

1.3.2 Fáze přípravy argumentace

1.3.3 Fáze použití argumentace

1.4 Shrnutí

2 Role testování ve firmě a v projektu

2.1 Testování neprobíhá ve vzduchoprázdnu

2.2 Faktory ovlivňující průběh a formu životního cyklu

2.3 Metodiky vývoje, testování a provozu

2.3.1 V model a W model: totéž, jen jinak?

2.3.2 Agilní přístup

2.3.3 DevOps jako spojení vývoje a provozu

2.4 Jak zapadá oddělení testování do organizace jako takové?

2.5 Role manažera testování

2.5.1 Interpersonální role

2.5.2 Informační role

2.5.3 Rozhodovací role

2.6 Shrnutí