Testování softwaru

Ekonomické principy testování – proč testovat, co a jak dlouho

2011-04-18T22:43:00.002+02:00

Tento týden mi přišel email, ve kterém dotyčný položil následující otázky:

Jak se vlastně přesně určuje kritičnost a nekritičnost funkčností? Na základě vazby na nějaké obchodní obraty?
Vezměme situaci cca. 40 systémů, cca. 800 rozhraní, a násobky x1000 funkčností.
Jak lze v takovémto množství efektivně řešit kritičnost jednotlivých funkčností a jejich vazeb? Existují na to nějaké závislostní algoritmy?
Lze definovat ukončení testů na základě kritérií, že pokud klesne počet chyb za den pod nějaký práh, tak lze přejít do produkce, nebo se do produkce musí přejít až s počtem chyb 0 na všechny komponenty?

Jelikož všechny tyto otázky se točí okolo ekonomického pochopení testování, uvědomila jsem si, že jsem se zde ještě nevěnovala vysvětlení základních principů.

Testujeme, dokud se nám to finančně vyplatí

V byznysu každý krok, který děláme, děláme s vidinou budoucího zisku. Pokud nabízíme zaměstnancům různé výhody, děláme to proto, abychom nalákali kvalitnější zaměstnance a snížili náklady způsobené jejich fluktuací. Pokud investujeme do kvalitnějších výrobků, děláme to proto, že navýšení kvality je pro nás finančně výhodné. Ať už díky tomu, že nebudeme muset vynakládat vysoké částky na nápravu chyb objevených zákazníky, nebo proto, že nám to přinese více spokojených zákazníků.

To souvisí i s tím, že testujeme tak dlouho, dokud se nám to finančně vyplatí. Pokud jsou náklady na objevení a opravu chyby v dané fázi větší, než jaké jsou předpokládané náklady plynoucí z neopravení chyb, nemá smysl pokračovat. Rovněž se může manažer dostat do situace, kdy je aplikace vysoce chybová, testování je velmi efektivní a bylo by dobré ještě dva tři měsíce v něm pokračovat a opravovat chyby, ale z jistých, například právních důvodů, je přesto finančně výhodnější nasadit aplikaci do provozu.

Za znalost celkové situace a rozhodnutí o nasazení je zodpovědný zákazník, typicky manažer té části podniku, která aplikaci požadovala a bude ji využívat. Test manažer je zodpovědný za to, aby mu poskytl dostatek informací pro toto rozhodování, zejména ho seznámil s riziky, která ještě nebyly odstraněny. Pokud spolehlivě funguje pouze 20 % funkcí, 10 % je natolik chybových, že je není možné využívat, a zbytek aplikace není ještě otestovaný, jaké jsou konkrétně rizika nasazení?

Tester tedy nestanovuje kritéria a nerozhoduje o tom, kdy může aplikace přejít do produkce. O tom rozhoduje vždy zákazník a je na něm, jaké množství chyb a jaké závažnosti bude tolerovat, nebo zda rozhodujícím kritériem pro něj nebude naopak vnější vliv, například situace na trhu.

Sledujeme efektivitu testování, co se týče počtu objevených chyb

Jak již výše uvádím, testujeme tak dlouho, dokud se nám to finančně vyplatí. Co to znamená? Že je potřeba s testováním přestat v okamžiku, kdy by nalezení a oprava chyb objevených dalším testováním byla už dražší, než netestovat a riskovat jejich objevení a opravu v budoucnu. Určení takového okamžiku ale není triviální. Nehledě na to, že je třeba pracovat s pravděpodobností, je také nutné mít dostatečně podrobné informace o nákladech, které většina firem na této úrovni nesleduje a nemá je tedy ani k dispozici.

Méně přesnou, ale zato jednoduchou a rozumnou alternativou je sledování počtu nalezených chyb v čase. Následující obrázek ukazuje typický příklad počtu objevených chyb za určitou dobu testování.

Zpočátku testovací tým nachází velké množství chyb. Postupem času je objevováno stále méně chyb a zdá se, že další testování už nemůže přinést žádná překvapení. V tomto bodě nezkušený test manažer ukončí testování s tím, že produkt je již připraven. Zkušený test manažer pokračuje, protože ví, že testování běžně popadne druhý dech a počet objevených chyb opět začne růst. Zda se jedná o růst skokový nebo postupný, jak ukazuje křivka trendu, ovlivňuje zejména to, zda test manažer podpoří růst počtu chyb obměnou testů. Nicméně i bez této obměny se navýšení dá očekávat. Ukončení testování je pak vhodné až v druhé nebo třetí prohlubni (lokálním minimu).

Testování je investice. Peníze je třeba dát tam, kde to bude mít největší efekt

Vhodné zaměření úsilí je důvodem pro určování kritičnosti nebo priorit při testování. Co je jak důležité pro byznys určuje opět zákazník. Většinou bývá v rámci složitých systémů kritičnost aplikací a byznys procesů dobře známa a pro její zjištění se stačí obrátit na manažera spravujícího rizika a krizové plány. Pokud takovéto rozdělení v podniku ještě není provedeno, je možné při určení důležitosti aplikace vycházet z toho, jaké dopady by měla její nedostupnost či špatné fungování. Například se odhadnou ztráty z jednodenní nedostupnosti aplikace, vytvoří se rozmezí ztrát a ty se přiřadí jednotlivým označením důležitosti.

Co se týká přidělení důležitosti jednotlivým testům, zde se čerpá zejména z důležitosti uživatelských případů (use-casů). Zákazník určuje své priority již ve fázi sběru požadavků a specifikaci. Při určení priorit je možné vycházet z toho, kolik lidí danou funkci využívá, zda pracuje s kritickými zdroji (penězi, osobními údaji, atd.) nebo jak podstatné jsou byznys procesy, které funkce zpracovává.

Často však zákazník zejména u menších projektů určuje důležitost spíše pocitově a na přání dodavatele určí např. 20% nejdůležitějších funkčností. Oblíbené a pro zákazníka dobře pochopitelné je přiřazení tří stupňů důležitosti:

Critical to quality (Kritické pro kvalitu produktu) – Bez funkcí, kterým je přiděleno toto označení, by produkt nebyl použitelný a nesplnil by ani ty nejzákladnější potřeby zákazníka.

Good enough quality (Dostatečná kvalita) – Funkce s tímto označením zaručují potřebné, ale ne nezbytné činnosti.

Nice to have (Bylo by hezké toto mít) – Funkce, které jsou třešničkou na dortu, mohou usnadňovat práci uživatelům nebo být další možností, kterou by někdo mohl v budoucnu potřebovat.

Odpovědí na všechny tyto tři otázky je: „zeptejte se zákazníka, co by si on přál“. Protože on je ten, kdo investuje a on je ten, kdo bude hodnotit návratnost své investice.

Jak je důležité umět prezentovat své nápady

2011-03-23T21:06:00.000+01:00

Před dvěma týdny jsem se účastnila konference CzechTest a byla to úžasná zkušenost, jelikož mezi přednášejícími byla řada zahraničních odborníků s 10 a často i 20 lety zkušeností v oblasti testování softwaru. Takových lidí je u nás žalostný nedostatek, nemám pravdu? Největší dojem na mě ale udělal Lloyd Roden, konzultant z Velké Británie, který mimo jiné přednáší taky na konferencích, jako jsou STARWest, STAREast, AsiaSTAR and EuroSTAR.

Čím se tento muž lišil od ostatních řečníků, nebyly jeho myšlenky a obsah jeho prezentací, jelikož jsem potkala řadu chytrých a zkušených lidí, ale jeho komunikační a prezentační dovednosti. Po jeho příspěvku, nejen opravdu přemýšlíte nad tématem, ale hlavně se cítíte nabytí energií a těšíte se, až tyto myšlenky vyzkoušíte v praxi. To, že Lloyd umí lidi kolem sebe přesvědčit a nadchnout je pravděpodobně i jedna z věcí, které ho dělají výborným test manažerem. Protože testování a zejména test management je především o komunikaci.

Rik Marselis, jeden z dalších řečníků, nám položil otázku, zda je testování technický obor nebo spíše humanitní. Já zastávám názor, že je to obojí, jelikož technické znalosti se zde snoubí s komunikačními dovednostmi, asertivitou a diplomacií.

Existují dobří testeři, kteří si rozumí více s počítači než s lidmi, a to je v pořádku, ale pouze do té doby, pokud jsou v týmu s testery, kteří mají velmi dobré komunikační schopnosti a rozumí potřebám stakeholdrů (= uživatelům a ostatním osobám na projektu).
Schopnost efektivní komunikace je nejdůležitější vlastností manažerů a všech osob, které si přejí být vyslyšeny. A já ještě nepotkala testera, který by si nepřál být vyslyšen a nesnažil se prosazovat kvalitu ve své organizaci.

Tester je nejlepší přítel programátora.

Já učím svoje studenty, že tester je nejlepší přítel programátora. Skeptici jistě nesouhlasí: jak může být někdo, kdo neustále nachází chyby v něčí práci jeho nejlepší přítel?
Jedině díky taktu, respektu k programátorovi a poskytování informací, které programátorovi ulehčují jeho práci.
Ale moment! Tohle je přesně to, co znamená být dobrým testerem. Tester poskytuje informace. Není to skvělé?!

Programátor je pouze další osobou, které pomáháme poskytováním potřebných informací. Pokud se dobře staráme o programátory a pomáháme jim rychle nacházet a opravovat problémy poskytováním relevantních informací, často se stáváme dobrými přáteli.
Programátoři nám neposkytují službu opravování chyb, my jim poskytujeme službu dodávání potřebných informací. Samozřejmě nejsou jediní, komu tuto služby poskytujeme, ale jsou skupinou, kterou často zanedbáváme. Pokud někomu nevěnujeme pozornost, kterou si zaslouží, nebo i hůř na něj nadáváme, není se co divit, že pak vztahy nejsou ideální. Špatný vztah mezi testery a programátory je pak znakem špatných testerů a managementu, který problém ignoruje.

Tester poskytuje informace. Dobrý tester poskytuje ty správné informace.

Z tohoto důvodu bych Vás všechny chtěla vyzvat: Běžte za programátory. Seznamte se. Zjistěte, jak by jste jim mohli pomoct. Zeptejte se jich, jaké informace by chtěli mít v reportu chyby, co jim na reportech vadí. Zeptejte se na jejich další problémy s kvalitou a žádejte je o zpětnou vazbu pravidelně.
Toto je dovednost, kterou musíme neustále pilovat: jak poskytovat ty správné informace a jak je správně komunikovat.

A pokud byste chtěli se hned do toho pustit, zde je pár tipů, jak začít.

Tipy:

Zlepšete své reporty chyb: crash course on reporting bugs
Zlepšete svoje přesvědčovací schopnosti: coaching testera how to email and influance stakeholders
Zlepšete své prezentační schopnosti: Pokud můžete, zaplaťte si soukromé lekce a pokud ne, přečtěte si pár základních tipů pro dobrou prezentaci (Presentation Magazine) a podívejte se na pár tutoriálů na Youtube (Effective Presentation Skills)
Cvičte své schopnosti, kdykoli máte příležitost: uTest bug battle

Studie o testování softwaru

2010-09-28T16:52:00.005+02:00

V rámci grantu VŠE jsme spustili dotazníkovou studii o testování softwaru v České republice. Prosím ty z Vás, kteří přijdou v práci do styku s testováním, jste se zůčastnili a vyplnili dotazník na stránce studiekvality.vse.cz
Přispějete k tím k analýze situace v testování softwaru v České republice a k jejímu rozvoji.
Děkuji.

------ Nyní k dispozici výsledky!!! --------

Výsledky naleznete na stránkách: studiekvality.vse.cz
Článek ke studii vyjde v odborném časopise Systémová integrace.

Proč bychom měli testovat?

2009-12-03T13:45:00.011+01:00

Tento příspěvek je určen nejen testerům, ale i managerům, které zajímá, co by jim testování softwaru mohlo přinést a možná nepřináší. Proto začnu definicí dvou pojmů, které dále často používám:

Zajišťování kvality (Quality Assurance) – plánované a systematické procesy jejichž cílem je zajištění vhodnosti produktu k jeho zamýšlenému účelu.

Testování - proces sběru a třídění informací získaných skrze zkoumání produktu, součást obecněji pojatého zajištění kvality.

Pokud máme pocit, že testování a zajišťování kvality není věnován dostatek pozornosti a společnosti tuto stránku vývoje softwaru podceňují, možná za to do jisté míry může i to, že se nám nedaří přesvědčit ostatní o důležitosti testování a jeho odborného řízení.

Jaké jsou tedy přínosy testování softwaru a zajišťování kvality? Které body bychom měli zmínit při prezentaci přínosů?

Proces zajišťování kvality ovlivňuje tři manažersky významné oblasti:
- Marketing
- Risk management
- Snižování nákladů

Marketing

To, že kvalitní produkt dodaný zákazníkovi má pozitivní vliv na pověst firmy, zatímco vysoce chybový nespolehlivý software pověst ničí, je jednoduchý logický závěr. Těžší je už odhadnout nebo si jen uvědomit míru tohoto vlivu. Vliv nekvalitního produktu na pověst firmy totiž přichází ve vlnách. Některé z nich jsou okamžité a rychle mizí, některé negativně ovlivňují firmu i po několik let.

První vlnou odezvy je reakce bezprostředního zákazníka, který na základě spokojenosti rozhoduje o následné spolupráci.

Druhou vlnou je reakce konečných zákazníků. Ti v případě nepříznivého přijetí produktu mohou způsobit řadu nepříjemností. Jejich neustálé stížnosti a reportování chyb může způsobit neočekávané prodražení projektu, takže z původně ziskového projektu se stane projekt prodělečný. Dále jejich nepříznivé přijetí produktu může změnit názor managementu zákazníka na dodavatele, nebo se dostat mezi širokou veřejnost prostřednictvím novinového a televizního zpravodajství.

Třetí vlnou je reakce současných zaměstnanců a dalších lidí z oboru výroby IT. Kvůli neustálé fluktuaci zaměstnanců se pověst softwarové firmy šíří dále a po mnoho let přetrvává. Schopní zaměstnanci firmu, která nedokáže dodat kvalitní software, opouštějí, protože nechtějí být spojováni s dalším neúspěchem nebo protože je jednoduše nemotivuje se zlepšovat. Tam, kde chybí objektivní měřítka kvality, tam je vždy nedostatek snahy o zlepšení. Ze stejných důvodů se firmě vyhýbají potencionální schopní zaměstnanci. Slyšeli o ní negativní věci ze strany bývalých či současných zaměstnanců.

Čtvrtou vlnou, která ovlivňuje softwarovou firmu s největším zpožděním, je neochota dalších zákazníků nebo jiných softwarových firem s ní spolupracovat. Před zaměstnanci firmy nelze zatajit nedostatek snahy o zajištění kvality a špatné nastavení procesů. Pokud tito zaměstnanci jsou přesvědčeni o tom, že by si sami svojí firmě nikdy nedali zakázku na vývoj softwaru, pak této firmě nebudou ochotni dát zakázku ani za několik let, kdy budou takováto rozhodnutí dělat z pozice manažerů a ředitelů. Stejně se zachovají i všichni, kteří se o špatně nastavených procesech dověděli od svých nových kolegů či kamarádů.

V těchto čtyřech vlnách působí každý projekt dle své kvality a dopadů v pozitivním či negativním směru na marketing.

Risk management

Testování je nástrojem k získání objektivních informací o stavu vyvíjeného softwaru. Tyto informace jsou pak nejdůležitějším vstupem pro řízení rizik spojených s vývojem softwaru. Testování se prolíná celým procesem vývoje. Už od samého počátku tedy kontroluje soulad vývoje s představami zákazníka, srozumitelnost, jednoznačnost a logiku výstupů. Včasným informováním o nedostatcích a chybách zabraňuje nedorozuměním a zbytečnému plýtvání zdrojů na špatné verze. Řízení kvality pak navíc definuje a hlídá postupy vývoje z hlediska zajištění jednoduchosti, srozumitelnosti, správnosti, přesnosti, rychlosti a dalších kvalitativních měřítek. Díky tomu dochází jak k výraznému snížení pravděpodobnosti vzniku problémů s kvalitou během i po vývoji, tak k omezení dopadů při vzniku problémů.

Testování výrazně předchází problémům s zákeřnými chybami. U softwaru z finančního, lékařského nebo jinak kritického sektoru, mohou ztráty způsobené dopadem jedné jediné zákeřné chyby několikanásobně převyšovat celý rozpočet na vývoj tohoto softwaru.

Bez testování zůstávají firmě jen dvě nepříjemné možnosti, jak s omezit riziko spojené s vývojem softwaru:
- zajistit si subdodavatele, který riziko do jisté míry převezme za ně
- pokud to jde, pojistit se proti některým typům problémů

Snižování nákladů

Přestože jednou z nejčastějších manažerských chyb je při snižování nákladů obětování kvality, právě efektivně nastavené zajišťování kvality přináší největší úspory. Z ekonomického hlediska by testování mělo trvat tak dlouho, dokud předpokládaná průměrná cena nalezení a opravy chyby objevené v příštím cyklu testů je menší než průměrné náklady na chybu objevenou zákazníkem vynásobené pravděpodobností objevu chyby. Zjednodušeně, testovat by se mělo tak dlouho, dokud je to finančně výhodnější než netestovat. Zajišťování kvality se navíc snaží nastavit procesy tak, aby docházelo k co nejmenšímu počtu chyb a ty byly co nejlevněji odstranitelné. Zajištění kvality je investice a je tedy vhodné sledovat její návratnost.

Problém je v tom, že je velmi obtížné zvládat řízení kvality tak, aby bylo maximálně efektivní a aby minimalizovalo náklady. Takový úkol vyžaduje zkušenosti, cit a výborné znalosti zkušeného odborníka. Proto, když už testujeme, je třeba to dělat dobře.

Jak začít?

Nastavit efektivně proces testování není jednorázová věc, ale vzniká neustálým dolaďováním na základě různých rozumně zvolených měřítek, které varují, pokud není vše v pořádku a na kterých lze sledovat zhoršení či zlepšení efektivity.

Pochopení klíčové role řízení kvality při vývoji softwaru, stanovení měřítek, procesu řízení kvality a vyhledání vynikajících odborníků s praxí přímo v testování dává dohromady dobrý základ pro každé oddělení řízení kvality softwaru.

Problémy s pokrytím kódu

2009-10-05T07:31:00.011+02:00

Jednou z důležitých technik je sledování nakolik je aplikace pokryta testy. Můžeme sledovat kolik případů užití máme porytých, kolik zákazníkových požadavků, ale nejpřesnější alespoň co se týče pokrytí funkčnosti je pokrytí kódu.
Při zjišťování pokrytí kódu se zaznamenává, jaký kód byl při testování spuštěn a jaký naopak otestován ještě nebyl.

Nejjednodušší ale zároveň nedostačující a zavádějící je pokrytí příkazů - řádků.

To pouze kontroluje, zda daný příkaz, řádek, byl proveden v průběhu testování, pro pokrytí podmínky tak může stačit její libovolné vyhodnocení.

Formálně: T splňuje kritérium pokrytí příkazů pro daný kód K, jestliže pro každý příkaz p náležící kódu K existuje test t z množiny T, že při provedení t bude spuštěn příkaz p.

Pro testera nebo programátora není problém dosáhnout velmi vysokého (i 100 %) pokrytí příkazů programu plného chyb aniž by jediný test selhal, aniž by byla objevena jediná chyba. Přesto, že tato metrika je takto zavádějící, pro svou jednoduchost je i tak oblíbená.

O stupeň pokročilejší je pokrytí hran – rozhodnutí.

Formálně: Představme si graf, kdy příkazy tvoří uzly a možné přechody mezi nimi hrany. Pak za sebou provedené příkazy tvoří hranu a podmínka uzel, ze kterého vedou dvě hrany, jedna pro true a jedna pro false hodnotu. Pak množina testů T splňuje kritérium pokrytí hran pro daný kód K, jestliže pro každou hranu h výše popsaného grafu existuje test t z množiny T, že při provedení t projde výpočet hranou h.

Jednoduše řečeno u pokrytí hran je každá podmínka uzlem, ze kterého vedou dvě hrany.

Například:

Máme kód se třemi podmínkami, z nichž jedna je vnořená.

Graf pokrytí hran pak vypadá následovně:

Přitom modré kolečka představují podmínky, zelená ostatní příkazy.

Při jakýchkoli složitějších podmínkách je ale i toto pokrytí nedostatečné.

Další stupeň představuje pokrytí podmínek.

Formálně: Množina testů T splňuje kritérium pokrytí podmínek pro daný kód K, jestliže splňuje kritérium pokrytí hran a pro každou složenou podmínku platí, že pro každou její část p existují testy t, u z množiny T, že při provedení t se p vyhodnotí kladně a při provedení u záporně.

Pokud se vynechá část, že pokrytí podmínek musí splňovat pokrytí hran, tak k nepokrytí hran a pokrytí podmínek dochází v případě, že pro všechny možné vstupy je vždy celá podmínka vyhodnocena jako pravdivá nebo nepravdivá.

Vylepšení pokrytí podmínek spočívá v tom, že se berou v úvahu všechny možná vyhodnocení podmínky, nejen to, zda je pravdivá, či nikoli.

Například:

Mějme složenou podmínku if (a>0 || b>0).
K pokrytí hran by stačili tyto testy: {a = 5; b = -2}, {a = 0; b = 0}
K pokrytí podmínek by tyto testy nestačili, protože část b > 0 je v obou případech nepravdivá. Pokrytí podmínek lze však dosáhnout jinými dvěma testy: {a = 5; b = 2}, {a = 0; b = 0}

U této verze je už těžší najít chybu, kterou bychom plným pokrytím podmínek neodhalili, i když jisté typy chyb stále budou i v plně pokrytém kódu zůstávat.

Nejvyšší stupeň pokrytí je pokrytí cest, které sleduje všechny možné průchody kódem a proto představuje opravdu podrobné otestování.

Formálně: Množina testů T splňuje kritérium pokrytí cest pro daný kód K, jestliže splňuje kritérium pokrytí podmínek a pro každou cestu C v grafu kódu spojující vstupní a výstupní uzel grafu a obsahující nejvýše n cyklů existuje test t z množiny T, že při provedení t projde výpočet cestou C.

I když ne všechny chyby jdou odhalit pouze z kódu, pokrytí cest poskytuje jistotu, že byly otestovány všechny možnosti běhu. Problémem je praktická nepoužitelnost tohoto pokrytí, jelikož jeho složitost způsobuje exponenciální růst počtu testů.

Otázka 1: Kolik testů (průchodů kódem) je potřeba, aby měla metoda code_coverage pokryty příkazy; hrany; podmínky; cesty?

Otázka 2: Kolik testů (průchodů kódem) je potřeba, aby měla metoda code_coverage2 pokryty příkazy; hrany; podmínky; cesty?

Murphyho zákony. Proč jsou pravdivé?

2009-09-06T22:11:00.003+02:00

Program je dobrý, když je bezchybný – což je nemožné.

Jsou lidé, kteří nevěří v existenci bezchybného softwaru a lidé, kteří si myslí, že testování bezchybnost zaručí. (Jsou i jiné skupiny lidí, z nichž nejhorší jsou ti, které kvalita nezajímá. Ale ty teď ponechme stranou.)
Bezchybné programy existují, ale pouze ty triviální. Například pokud jediné, co daný program má umět, je vypsat na obrazovku "Ahoj světe!" a skončit.
Čím je program složitější, tím těžší je i zkontrolovat jeho bezchybnost.
Nakonec i jednoduchý program o pár řádcích může mít tolik různých cest kódem, že bychom je všechny neotestovali ani za deset let.
Proto u jakéhokoli netriviálního programu, tím spíš složitých aplikací a systémů, je nutné počítat s tím, že ať na testování věnujeme sebevíc času, vždy bude obsahovat chyby.

Neviditelných chyb je nekonečné množství, oproti viditelným chybám, kterých je už z definice konečné množství.

Tento zákon je pouhým důsledkem Dijkstrova axiomu, že testování je vhodné k dokázání přítomnosti chyb, ale nevhodné k prokázání jejich nepřítomnosti.

Každý program obsahuje jeden chybný řádek.
Každý program jde zkrátit o jeden řádek.
Z toho plyne, že každý program jde zkrátit na jeden řádek, který je chybný.

K tomu téměř není co dodat. Snad jen, že je to jako sebenaplňující se proroctví. Čím více do kódu člověk zasahuje, tím je větší pravděpodobnost, že do něj zanese chybu.

Fungující program má pouze neobjevené chyby.

Tento zákon by ve skutečnosti měl znít, že software, na který si nikdo nestěžuje, má pouze neobjevené chyby a to proto, že ho nikdo nepoužívá.
Tak to funguje ve skutečnosti. Cílem testování je dosáhnout určitého (nejlépe vysokého) stupně kvality, ne dosáhnout toho, aby zákazník nenahlásil jedinou chybu.

Stačí, když zákazník bude mít z produktu dobrý pocit, protože nebude narážet na chyby často a ty nebudou mít žádné vážné důsledky. A ty chyby, na které narazí, budou rychle vyřešeny

Počet chyb vždy překročí počet řádek v programu.

Toto je spíše zobecněné pozorování. Často je tento zákon pravdivý, protože během životního cyklu vývoje dojde k tolika změnám v programu, že i když konečný program má x řádek, programátoři jich napsali mnohonásobně více.

Šance, že program dělá to, co má, je nepřímo úměrná počtu řádek v programu.

To je snadné pochopit. Čím je program složitější, tím je těžší se v něm vyznat, na něco nezapomenout a neudělat chybu.

Nehledě na to, kolik zdrojů máš, nikdy to není dost.

Netriviální program nemůžeme nikdy kompletně otestovat a nemůžeme zjistit, kolik dosud neobjevených chyb obsahuje. Je tedy možné testovat do nekonečna.
Důležité je dokázat s přidělenými zdroji co největšího efektu. Což je pravé umění nejschopnějších manažerů. Pokud objevení chyby a její oprava stojí více než kdyby jí objevil až zákazník, pak je na čase testování ukončit.

Patch je kus softwaru, který nahrazuje starou chybu novou.

I když je patch relativně malý kus softwaru, je nutné ho otestovat. Spoléhat na to, že vše poběží, jak má, aniž by to někdo opravdu vyzkoušel, je spolehlivým receptem na katastrofu.

Chyby se objeví v jedné části fungujícího softwaru, pokud další zdánlivě nesouvisející část je modifikována.

Jsou dva důvody, proč i když je změna pouze v jedné části programu, se mohou najednou objevit chyby tam, kde předtím žádné nebyly.
První důvod je, že tyto části spolu nějakým způsobem souvisí, ale nikdo si to neuvědomil.
Například jedna část volá funkci, ve které se nachází nadbytečné volání jiné funkce, která byla touto změnou zrušena.
Druhý důvod je, že přestože obě části softwaru spolu nesouvisejí, používají stejné zdroje. Může se tak projevit chyba, která v softwaru byla už nějakou dobu. Například špatně ošetřené sdílení paměti nebo ukazatel, který ukazuje na náhodné data.

Ty nejpřehlédnutelnější chyby způsobí ty největší problémy.

Malé a nenápadné chyby mají buď malé nebo žádné dopady (například logo je pixel posunuté mimo určenou pozici) nebo velmi závažné důsledky (V jednom ze sta případů dojde ke špatnému zaokrouhlení částky, což může mít za následek ztráty několikanásobně větší, než byla cena softwaru). Pokud chyba je nápadná, uživatel si jí hned všimne a pokud její dopady jsou závažné, tak je možné hned situaci napravit, aby se už neopakovala. Pokud ale chyba uniká pozornosti, její důsledky se hromadí, až se lavina protrhne a může dojít k velmi vážným problémům.

Softwarové chyby je nemožné detekovat kýmkoli kromě koncového uživatele.

Přestože testeři při testování odhalí velké množství různých chyb, některé chyby je těžké odhalit pro kohokoli než koncového uživatele. To proto, že i když se tester snaží na software dívat z pohledu uživatele, tak běžným uživatelem není, a chybí mu znalost chování uživatele.
Jediný způsob, jak zjistit reakce uživatelů na software, je vidět je s ním pracovat.

Jakoukoli chybu nehledě na její složitost, lze objevit pouhým pohledem.
Důsledek: Otravující kolemjdoucí s nevítanými radami ji spatří okamžitě.

Pokud už tester vyčerpal všechny nápady a objevil svým trénovaným okem všechny chyby, je potřeba k nalezení dalších chyb změnit přístup nebo i třeba zkusit větší odstup.

Chození po vodě a vývoj softwaru podle specifikace je snadné pouze pokud je obojí zamrzlé.

Každá změna specifikace přináší do vývoje rizika:
• O změně se nedozvědí všichni, kdo o ní potřebují vědět
• Změna bude nejasná a špatně pochopena
• Je třeba zahodit už otestovanou část a napsat novou, která je potenciálně plná chyb
• Složitost toho, co si vývojář musí pamatovat, se zvyšuje a je lehčí udělat chybu
• ...

Nejlepší způsob, jak obejít bezpečnostní prvek, je posadit za počítač třináctiletého.

Ve snaze zabezpečit software před nevítanými vetřelci mají lidé občas tendenci se soustředit na nejčastější a nejznámější způsoby průniku a budování sofistikované obrany proti nim. Přitom mohou přehlédnout nepřímou ale jednoduchou cestu dovnitř. Dalo by se říct, že tento zákon je důsledkem toho, když někdo přes samé stromy nevidí les.

Murphyho zákony byly převzaty z Murphy's computers laws, přeloženy a popřípadě mírně upraveny.

Základy testování

2009-08-11T19:05:00.006+02:00

Protože literatury ohledně testování je v češtine velmi málo, rozhodla jsem se zveřejnit část svojí příručky o testování, která vznikla v rámci diplomové práce a která se zabývá základy testování.
Doufám, že se Vám bude líbit.

Tuto příručku a další materiály naleznete v sekci ke stažení.

Zamyšlení nad testovací misí

2009-08-05T17:17:00.001+02:00

Manažer by měl ...

... být vůdčí osobností

... jasně vysvětlit ostatním členům týmu projektovou misi a cíle

... umět nadchnout pro úkol

... podpořit přijetí projektových cílů zaměstnanci za své

... podporovat spolupráci a aktivitu

... motivovat ke zlepšování

S takovýmto přístupem jsem se setkala v přednáškách o managementu škole, v moudrých knihách jako je např. Měření v systémech managementu jakosti od Jaroslava Nenadála a bohužel poněkud méně často v praxi.

Atmosféra spolupráce, nadšení a odpovědnosti za dosažení cílů je jistě v mnoha oblastech plus, ale v testování softwaru je přímo magickou ingrediencí.

Definice cílů a snaha o jejich dosažení je oním počátkem cesty, jak se stát z průměrného testera, který jen sleduje scénáře a návody opravdovým expertem na testování.

Test manager nebo projektový manager definicí testovacích misí a nadchnutím testerů pro jejich dosažení vytváří prostředí, které testery inspiruje ke zlepšování a řada z nich pak začne růst ve vynikající odborníky.

Je to ale cesta, kterou neujdete po pár hodinách nebo dnech. Je to cesta, po které můžete jít tak dlouho, dokud vám vydrží motivace.

Protože dokud budete mít důvod se chtít zlepšovat, prostor ke zlepšení vždy najdete.

Mise testování určuje, co je momentálním cílem testerovy práce, a definuje kritéria, která hodnotí, zda a nakolik misi splnil. Je tak možné lépe řídit práci testera, je-li mu řečeno, jakých cílů má testování dosáhnout, s jakým záměrem má testovat.

Cíle testovací mise mohou být různé: odhadnout chybovost jednotlivých modulů aplikace, připravit reprodukovatelné testy, odhalit co nejvíce chyb, nebo třeba jen rychle odhalit závažné chyby, bránící nasazení aplikace.

Často testování sleduje více záměrů zároveň a mise tak má více cílů.

Smyslem definice misí, je uvědomit si záměr testování a schopnost posuzovat jejich výsledky.

Splnili jsme svou misi? Nakolik? Proč jsme selhali? Existuje prostor pro zlepšení? Co jsme se naučili? Je možné dosáhnout jiným přístupem lepších výsledků?

Definice konkrétních cílů dané iterace testování je mocným nástrojem. Manažerům umožňuje efektivní řízení zdrojů, testery vede pak k tomu, jak dělat svou práci co nejlépe.

Nejužitečnější cíle jsou definované tak, aby byly měřitelné.

Dvě skupiny otestují stejný produkt, jak rozhodnout, která je lepší?

Pokud nevíme, nakolik jsme dobří a nakolik splňujeme naše cíle, chybí prostor pro zlepšování. Chybí dostatek motivace a firma místo odborníků a efektivního testování bude mít jen samé průměrné klikače a ne moc dobré ale za to drahé testy.