úterý 23. ledna 2007

Manuální testy jsou pro odpadlíky

Každý manuální test se skládá ze dvou části: manuálu a opice.

Opice vezme manuál provede test a vyhodnotí jej a zapíše někam výsledek. Protože je opice od přírody líná, tak jí nebaví vzít desetkrát banán, oloupat ho, pozřít a případně nezdechnout, protože je banán zkažený. Vezme banán, rozbalí ho a pokud vypadá "normálně" tak jej prohlásí za poživatelný.

Za naší opici si nemusíme dosadit člověka, ale zamyslet se nad tím, proč ten test není automatický. Co bychom tím získali?

  • automatický test nemá pracovní dobu
  • automatický test pracuje paralelně
  • automatický test nezkresluje výsledky
  • automatický test nepotřebuje žádnou lidskou interakci
  • na automatický test se nezapomíná

I přes nesporné výhody automatických testů stále převládá názor, že manuální testy jsou nenahraditelné. Ano, do jisté omezené míry jsou nenahraditelné nicméně většina z nich je absolutně zbytečných a lze je zautomatizovat. Velkou nevýhodou manuálních testů je jejich nízká vypovídající hodnota, která je ovlivněna chybou lidského faktoru.

Náklady

Nejpropastnější rozdíl mezi automatickými a manuálními testy je ovšem v tom nejpodstatnějším, v nákladech na zdroje. Ať vezmeme náklady v čase, ceně nebo alokaci člověkodní všude jsou manuální testy dražší. Rozdílné je také rozložení alokace zdrojů v čase.

U automatických testů jsou největší náklady v prvotní fází, kdy se test vytváří, potom jsou náklady prakticky nulové. Oproti tomu testy manuální alokují zdroje konstantně. Velká náročnost prvotní fáze vývoje automatického testu je největším, především mentálním, blokem pro psaní automatických testů.

Pokrytí

U manuálních testů je problém určit skutečné pokrytí testované funkčnosti. Manuální testy mohou otestovat nejčastější případy užití, ale jejich vypovídající hodnota o tom co všechno testují je malá. Oproti tomu automatické testy v podobě unit a integračních testů mohou poskytnout díky analytickým nástrojům takzvaný code coverage, čili pokrytí API testy. To je velice důležité při oddělení odpovědností za jednotlivé vrstvy aplikace. Test a úroveň pokrytí dokládá garantovanou funkčnost API.

Výzva

Největší výzva pro automatické testy leží v přesvědčení vývojářů a testerů o jejich nutnosti a přínosu. Pokud vývojář nezačne myslet v intencích, že z automatického testu profituje především on sám, pravděpodobně nikdy nezačne nějaký test psát.

Motivujte vývojáře k psaní automatických testů!
  • zaveďte pravidlo - test slouží jako certifikace, že kód dělá to co má, jinak je neakceptovatelný. Pomáhá udržet vnitřní pnutí mezi jednotlivými týmy, které se přou jestli kód děla to co má. Test na úrovni API umožňuje specifikovat požadovanou minimální funkčnost - trojice: veřejné rozhraní, test a implementace.
  • čas k napsání testů je garantován - pokud vývojář odhadne náklady na test, akceptujte je, ale na oplátku test požadujte
  • nechte vývojáře se učit psát testy - psaní testů nejde samo, podporujte vývojáře v sdílení informací o tom, jak psát testy
  • poskytujte podporu pro psaní testů - adoptování testovacích frameworků, pravidelné reporty o úspěšnosti, code coverage
  • osvěta - dokládejte dopad automatických testů na kvalitu produktu

Nahrazení manuálních testů jako zastaralého způsobu testování pro valnou většinu testovacích případu je jedním z největších úkolů, před kterým stojí každá softwárová firma, která se snaží zvýšit kvalitu vlastního produktů. Klíčovým faktorem je motivace a přesvědčení lidí, v těch úspěšných firmách to dokázali, pro ty ostatní odpadlíky jsou manuální testy a nejistá kvalita výsledku.

Související články

Napsali jinde