Jak se vypořádat s nadmírou bugů – tester vs testy

code testingcode testingNedávno jsem se dostal do zajímavé diskuze, ve které se řešil nadměrný výskyt bugů související s nasazením nové verze aplikace do produkce i přes to, že se často jednalo pouze o malé úpravy kódu. Část vývojářů by tento problém řešila k mému překvapení přidáním nového článku do procesu vývoje – testera. Ten by měl za úkol ještě před samotným publikováním nové verze zkontrolovat, zdali vše funguje, jak má.

Odkud vítr fouká?

První otázka, na kterou bychom měli najít odpověď. Proč k chybám dochází?

Nejprve jsme se zaměřili na proces vývoje. Ten byl celkem standardní a zahrnoval, že každý nový kus kódu je podstoupen dalšímu vývojáři (CR – code revivew) a po schválení je nová feature testována i product managerem (QA – quality assurance). Zde problém tedy nejspíše nebude.

Jako další na řadě je samotný projekt, tedy to, jak je napsaný. Pokud máte dobře nastavený proces, bude stejně jako v našem případě háček právě tady. Nový kus kódu byl vyzkoušen před puštěním do produkce dostatečně. Problém byl ale v tom, že nový kus kódu velmi často rozbil něco, co předtím fungovalo (a ideálně ani s novou feature nijak nesouviselo). Tento problém by nenastal, kdyby byl projekt od samého začátku psán pořádně (podle pravidel čísého kódu), kde se nám strýček Bob snažil vysvětlit, jak je důležité zbavit kód závislostí. Co ale s tím, když tak projekt z jakéhokoliv důvodu napsán není?

Co s tím?

Celý projekt přepíšeme.

To asi nechcete slyšet.

Najmeme si testera, který po nás bude vše testovat.

Ne moc chytré řešení. Je to jenom člověk, stejně nikdy vše neotestuje. Vezměme si třeba případ, že na přestupný rok 29.února nepůjdou objednávky, protože někdo zapomněl, že na přestupný rok má únor i 29.den. Koho by tohle napadlo a jak by to ten chudák měl s předstihem testovat? Další problém je, že některé věci neotestuje nejspíš vůbec, protože by musel mít znalosti celého projektu a technologií, které na projektu používáte. Některé věci se prostě klikáním otestovat nedají.

Další nevýhodou je cena, protože každé spuštění testů – tedy příchod testera do práce už stojí peníze. I když není zrovna třeba co testovat.

Další nevýhodou je rychlost, protože proklikat 150 různých scénářů starého modulu na vytvoření objednávky zabere dost času.

A tak dále a tak dále…

Budeme psát testy

Dle mého názoru nejlepší řešení. Ke každému novému kusu kódu, tedy i k bugu, který opravíte, napište testy. Tím začnete pokrývat postupně projekt i zpětně. Ano, psaní testů stojí čas. Někdy dokonce více času než napsání samotného kódu. Ale není těžké si spočítat, kolik stojí něco naprogramovat a pak to pětkrát opravovat, nehledě na to, že výskyt bugu může způsobit velké škody, když například přestanou fungovat objednávky nebo celý web.

Důležité je psát testy pořádně. Psaní nečistých testů často končí tím, že se testy neudržují.

Testy také musí testovat důkladně. Psát testy jen proto, aby jste je měli, nemá smysl.

Pomocí testů se dá otestovat cokoliv.

cost of defects
Cena bugu při vývoji

Testy se dají spouštět už při vývoji. Základní manažerská poučka nám říká, že čím dříve ve vývoji zachytíme chybu, tím méně nás to bude stát.

Jaký je teda závěr?

Pište dobré testy.

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *