Testování má větší váhu než vývoj...a ne naopak
Na testování se vždy kladl menší důraz, než na samotný vývoj. I přes nekonečné množství knih, workshopů, případových studií, apod, se přístup k zajištění a řízení kvality softwaru příliš nezměnil. A ruku na srdce, nijak zvlášť tomu nepomohl ani nástup agilního vývoje. Sice se mnohdy považuje jako další evoluční stupeň metodických rámců a přístupů jak efektivně uspokojovat zákaznické potřeby, ale o testování toho moc neřiká.. Pojďme se v tomto článku společně zamyslet nad tím co se stane, když se netestuje pořádně.
Zkontrolovat výsledný produkt zda odpovídá původním požadavkům je jedna z nejdůležitějších fází vývoje prakticky jakéhokoliv výrobku a nemusí se jednat pouze o počítačový program. Připravil jsem tři příklady, které stojí za to.
1. Smartphone Galaxy Note 7
Vlajková loď Samsungu Note 7 byl telefon, který měl být tou správnou volbou pro náročné zákazníky. Počáteční optimismus záhy vystřídalo zklamání v podobě problémů s baterií. Ta se u některých prodaných kusů nekontrolovaně vznítila, až nakonec explodovala. Samsung Galaxy Note se tak stal nebezpečným přístrojem, který nesměl být ani na palubě letadel. Společnost vydala prohlášení, že stahuje všechny telefonu z oběhu a současní majitelé je oproti kompenzaci měli vrátit zpět prodejcům. Je celkem logické, že pověst firmy byla poškozena, což se projevilo i na hodnotě akcií. Jejich cena se v reakci na zmíněné problémy propadla až o 14%.
Kde se stala chyba? Přičinou byl špatný návrh baterie, resp. její velikosti a umístění. Dvě tenké polymerové vrstvy pokryté elektrolyty oddělovaly pozitivní vrstvu oxidu lithia a kobaltu a negativní grafitovou vrstvu. Pokud se tyto dvě vrstvy dotkly, elektrolyty se přehřály, což způsobilo explozi. Chybu v designu se v tomto případě podařit neodhalilo, což znamená, že testování začalo až příliš pozdě.
2. Česká spořitelna
Nemusíme ale chodit daleko. I u nás v Česku je dost příkladů nedostatečného testování. V roce 2007 měla tehdy největší česká banka - Česká spořitelna - výpadek internetového bankovnictví. Klienti banky se nemohli několik dní před Vánoci přihlásit ke svému účtu z důvodu přetížení sítě. Problémem bylo evidentní poddimenzování IT systémů, které nebyly otestovány na zvýšenou zátěž předvánočního období. Tehdejší šéf Gernot Mittendorfer prohlásil, že "když mi garantujete, že náš systém bude hladce fungovat, a budete zato chtít dva milióny korun, tak je dostanete".
3. UniCredit Bank
Kromě České spořitelny jsou tu i jiné tuzemské banky. Naposled UniCredit Bank, kde klienti několik dní za sebou nemohli využívat e-banking nebo jeho část. Nešly odesílat a přjímat platby, nebyl vidět zůstatek účtu, apod.. Nasazení nového systému se nezdařilo a místo plánované víkendové odstávky systémů, se problémy protáhly na více jak týden. Jednalo se tak zatím o největší výpadek bankovnictví v historii (ve světě jsou ale zaznamenány případy i delších neplánovaných odstávek).
Zkrátka vždy se najde něco, co nebylo dostatečně otestováno a později způsobilo problémy. Čím dříve se ale na chybu přijde (v ranných fázích vývojového cyklu), tím jednodušší a levnější je podniknout kroky k její nápravě. Nejhorší scénář nastává, kdy se s problémem ozve sám zákazník (viz obrázek).
Vyplatí se začít testovat úplně od začátku. Máte před sebou požadavky na systém? Máte architekta nebo jiného experta, který navrhne strukturu aplikace, resp. platformu na které se to bude stavět? Zkuste se nad tím kriticky zamyslet, co dává smysl, co se dá udělat a co ne. A samozřejmě ještě před napsáním první řádky kódu mějte vybraný testovací framework, nástroje a napište první sadu testů. Sice zatím neprojdou, ale to nevadí. Říká se tomu Test Driven Development a dává to smysl. Mrkněte na pěknou a jednoduchou prezentaci o TDD.
V dalším článku se zaměřím na testování v rámci Agilních metodik. Jaké jsou překážky a jak to udělat, aby to alespoň trohu fungovalo :-).
