Wczesne testowanie oszczędza czas i pieniądze, tak brzmi jedna z siedmiu zasad testowania oprogramowania. Przy okazji jest to jedna z moich dwóch ulubionych zasad testowania. Dzisiaj właśnie o niej, czyli o tym, jak wczesne testowanie jest ważne w codziennej pracy testera.
Przygotowałem wersję mp3 tego wpisu. Nie jest to słowo w słowo czytanie a opowiedzenie tego samego tematu.
Jako tester zarabiasz, bo podnosisz jakość projektu.
Zacznijmy od podstaw, możesz sobie nie zdawać z tego sprawy, bo nie jest to takie oczywiste jak w innych branżach. Przykładowo sprzedawca ma wyznaczone miesięczne normy tego, ile ma sprzedać produktów, by zarobić na siebie lub by otrzymać premię do podstawowej pensji. Jako tester pracujesz na jakość projektu, to znaczy tak naprawdę ją mierzysz, ale podczas tych działań znajdujesz błędy, które potem są poprawiane i jakość rośnie (o ile znalezione usterki zostały poprawione). Przeważnie więc klient płaci za stanowisko, w które jest wliczona Twoja pensja i jakieś rzeczy dodatkowe, którymi mogą być narzędzia (licencje na nie), ale także marża dostawcy za to, że znalazł takiego klikacza/klepacza kodu jak Ty.
Dlaczego o tym mówię? Co ma wczesne testowanie do Twojej pensji?
O tym dowiesz się za chwilę, teraz chcę zaznaczyć to, że projekt ma zawsze swój budżet, są liczone koszta. Do kosztów zaliczamy pensje, licencje na narzędzia. Kosztem jest też poprawa błędów. Ważne byś zrozumiał, że im wcześniej błąd zostanie znaleziony, tym mniejszy będzie koszt jego naprawy zatem i koszty projektu mniejsze. A im mniejsze koszta, tym większy budżet na coś innego.
Naprawa błędów wcześnie wykrytych jest tańsza
W większości przypadków z testami jest tak, że im wcześniej zaczniesz testować, tym fajniejszy efekt możesz uzyskać. Jestem osobiście fanem testów już na etapie specyfikacji lub też koncepcji w przypadku metodyk zwinnych (nie zawsze mamy specyfikację). Dlaczego tak wcześnie? Niejednokrotnie w trakcie takich testów zauważyłem, że jakieś wymagania aplikacji gryzą się ze sobą. Jeśli aplikacja była na etapie specyfikacji, naprawa błędu najczęściej polegała na rozmowie, wyjaśnieniu z klientem jak aplikacja ma działać, a następnie spędzeniu kilku minut poprawiając dokumenty w Wordzie.
Jednakże możemy nie weryfikować specyfikacji, co się wtedy dzieje?
Taka specyfikacja trafia do developera, który może zauważyć, że coś jest nie tak, lub może tego nie zauważyć. Jeśli nie zauważy błędu, to spędzi kilka godzin na implementacji czegoś, co od początku nie ma prawa działać. Wersję z tak zaimplementowanym kodem dostanie na testy tester, który najpierw straci czas na przygotowanie środowiska pod testy, następnie rozpocznie testy i, tak czy siak, znajdzie dziurę w SPECYFIKACJI!
Tester musi zgłosić błąd w Bugtrakerze, następnie analityk i tak musi zrobić robotę z początku opowieści, natomiast programista musi przepisać to, co zrobił lub poprawić, a my musimy wykonać kolejną partię testów.
Ta sytuacja pokazuje, że im później zaczynamy testy, tym koszt jest większy.
Niektóre firmy decydują się na rezygnację z działu testów czy też z testerów w zespołach. W takich wypadkach często błędy znajdywane są dopiero na produkcji. Naprawa „na żywym” organizmie nie jest prosta. Czasami wymusza na nas presję czasu, jeżeli błąd był poważny, ponadto powoduje zakłócenia w płynnym i nieustannym działaniu aplikacji (przeważnie aplikacja ma na czas wgrywania nowej wersji włączony tak zwany maintenance).
Dlatego też dbaj o to, żeby testować jak najwcześniej, ponieważ wczesne testowanie naprawdę daje efekty. Przykładem wczesnych testów są testy jednostkowe, które stanowią podstawę piramidy testów.
Na koniec pamiętaj też, że nie Ty jeden powinieneś myśleć o jakości i o jak najwcześniejszych testach a cały zespół.
