#6 Antywzorce w testowaniu oprogramowania: Zwracanie nadmiernej uwagi na pokrycie testami

19 lipca 2020 | Trochę teorii, Uczymy się!

Czas na szybkie omówienie szóstego antywzorca z listy z Codepipes Blog, a mianowicie zwracania nadmiernej uwagi na pokrycie testami. Coś czuję, że to ten antywzorzec będzie najbliższy mojemu sercu, bo zwykłam przewracać oczami ( choć czasami tylko w duchu) na samo wspomnienie tej metryki.

Każdy, kto miał do czynienia z testami dłuższy czas pewnie zauważył, że pokrycie testami to ulubiona metryka wśród ludzi (zwykle z menedżmentu), którzy chcą udowodnić, że interesują się jakością bardziej, niż wskazywałaby na to rzeczywistość. Wiecie, to jedno z tych magicznych pojęć-wytrychów (obok pytania „czy to jest skalowane?” oraz „jakie jest ROI?”; to drugie akurat czasem może być zasadne) które po prostu muszą pojawić się na każdym spotkaniu poświęconym planowaniu prac developerskich oraz na połowie z developmentem nie związanych. Może się tak dziać – na co zwraca też uwagę Kapelonis w swojej liście antywzorców – ponieważ metryka ta jest bardzo łatwa do zrozumienia przy jednoczesnym ilościowym charakterze. Nie wspominając już o mnogości narzędzi pozwalających bardzo łatwo wyliczyć pokrycie testami.

Według Kapelonisa – a ja się pod tym podpisuję wszystkimi kończynami – pokrycie kodu jest całkowicie bezużyteczne jako metryka, możemy mieć projekt ze stuprocentowym pokryciem kodu, a będzie on nadal zawiera błędy i problemy. Sama miałam okazję pracować przy projektach, które mogły pochwalić się wyplutą z programu metryką rzędu 90%, przy czym każdy test jednostkowy sprawdzał, czy zwracany wynik ma wartość różną od False. Inna sprawa, że takie testy były pisane właśnie po to, by uzyskać owego świętego graala jakości oprogramowania. Nie muszę chyba mówić, jakie zwykle były efekty testów UAT mimo „zielonych” testów jednostkowych.

Dość istotną sprawą jest również to, że wraz z rozrostem aplikacji i spadkiem jej trywialności- rośnie zapotrzebowanie na złożone testy. Może się okazać, że wysiłek wymagany do napisania tych testów będzie większy niż ryzyko związane z tym, że brak tych testów doprowadzi do awarii na produkcji. Poza tym, większa złożoności testy, to więcej czasu wymaganego na ich napisanie. Pamiętacie pytanie o ROI z drugiego akapitu? Właśnie w tym wypadku jest zasadne.

Swoją drogą, Kapelonis proponuje swój zestaw metryk, ale ten temat jest na tyle obszerny i ciekawy, że chciałabym o nim napisać w innym poście. A samo pokrycie testami – może być traktowane jako ciekawostka, którą chcemy się pochwalić przed menedżmentem, ale nie powinno być traktowane jako reprezentacja jakości oprogramowania.

Najnowsze wpisy

CzytanQA: Czarny Łabędź

Jak już pewnie wiecie, a jak nie wiecie, to właśnie się dowiecie, interesuję się już od dłuższego czasu błędami poznawczymi.

Biały pasek na pączkach, czyli o TQM słów kilka

Total Quality Management jako zagadnienie od dawna chciałam opisać, ponieważ właśnie ono w czasie moich studiów zapadło mi w pamięć.

Akcja rekrutacja: Kto odpowiada za jakość oprogramowania?

To pytanie bardzo często pojawia się na rozmowach kwalifikacyjnych na stanowiska związane z testowaniem oprogramowania. Sama wiele razy je zadawałam, a jeszcze częściej słyszałam - nie skłamię, jeśli napiszę, że może tylko na jednej rozmowie...

Pin It on Pinterest

Podoba Ci się wpis?

Podziel się ze znajomymi!