Przejdź do treści

testerembyc.pl

Czyli blog o tym, jak to jest być nie tylko testerem

Cała prawda o testach oprogramowania i czym one są

Cała prawda o testach oprogramowania Wykorzystano zdjęcie autorstwa Pixabay z Pexels

Tytuł szumny i jeśli zwrócił Twoją uwagę, to bardzo się cieszę, bo pewnie tak jak ja swego czasu nie znalazłeś odpowiedzi na pytanie, czym są testy oprogramowania? Zapewne przeglądając Wikipedię i inne szanowane źródła wiedzy dla testerów, widziałeś definicję dotyczącą testowania oprogramowania. Mówi ona m.in. że testowanie oprogramowania jest jednym z procesów zapewnienia jakości wytwarzanego oprogramowania, który ma na celu jego weryfikację (sprawdzenie zgodności ze specyfikacją) oraz walidację (sprawdzenie zgodności z oczekiwaniami użytkownika). Super definicja tylko, że nie mówi nic na temat tego, czym są testy? Dlaczego to takie ważne i co wiedza o tym może nam dać?

Wiedza o naturze testów

Odpowiedzmy sobie najpierw na drugie pytanie, czyli co wiedza o tym, czym są testy, może nam dać?

Odpowiedź jest nieoczywista i może wydawać się ciut dziwna, bo pomaga rozwiązać bardzo dużo różnych problemów, np.:

  • w przypadku kodu testów automatycznych odpowiada na pytanie, czy kod testów powinien mieć swoje oddzielne repozytorium, czy może powinien być częścią kodu aplikacji,
  • w jakim języku należy pisać testy automatyczne,
  • tester kontra programista, kto ma rację i dlaczego tak często testerzy są tak mało doceniani przez programistów.

Dlaczego większość punktów odnosi się do testów automatycznych? Bo z tym typem testów jest zawsze najwięcej problemów i jeśli my, jako tester, musimy podjąć pewne decyzje, aby wdrożyć w naszym projekcie testy automatyczne, im bardziej będziemy świadomi potencjalnych problemów i ich przyczyn, tym łatwiej będzie nam zacząć oraz lepsze będą nasze testy. Wróćmy jednak do sedna tematu.

Czym są testy?

Odpowiem, krótko i zwięźle: testy są produktem.

Pewnie pytasz teraz: ale dlaczego? Zacznijmy od początku, czyli czym w ogóle jest produkt. Według Wikipedii produktu to obiekt rynkowej wymiany i może być zarówno dobrem materialnym, usługą, miejscem, organizacją lub ideą. Widać, że w przypadku testów, możemy mówić o usłudze, a testerzy w zamian za jej dostarczenie dostają wynagrodzenie. Widać więc, że określenie testów produktem jest jak najbardziej poprawne.

Skoro już wiemy, czym są testy, to teraz zastanówmy się nad tym, kim jest klient, który kupuje usługę testowania.

Klient usługi testowania

Znów posłużę się definicją z Wikipedii, która mówi, że klient to nabywca towaru na własny użytek, a więc ostatnie ogniwo w łańcuchu ekonomicznym. Jest to ktoś, kto korzysta z towaru i nie odsprzedaje go dalej (wtedy byłby sprzedawcą lub pośrednikiem).

Zastanówmy się, kto najwięcej korzysta z produktu, jakim są testy: projekt menadżer, dział marketingu, a może programiści? Prześledźmy to po kolei, komu może na tym najbardziej zależeć.

Na pierwszy ogień weźmy menadżera projektu? Czy jemu w ogóle potrzebne są testy? Raczej nie, bo dla menadżera projektu najważniejsze jest wytworzenie oprogramowania w zadanym terminie i przy zadanym budżecie. Z tej perspektywy, testy są wręcz dodatkową przeszkodą i kosztem. Tak przynajmniej sądzi część PM-ów (choć widzę na tym polu zdecydowaną poprawę na przestrzeni ostatnich kilku lat), którzy nie rozumieją, co dają testy. A testy polepszają jakość produktu oraz potrafią uchronić od kosztownych błędów. Błędów, które mogą nadszarpnąć reputację firmy, a w niektórych przypadkach również doprowadzić do utraty życia lub zdrowia ludzi (przykładem niech będzie, błąd w oprogramowaniu samochodów marki Toyota, który odpowiadał za obsługę pedału gazu).

No to może dział marketingu? Ich zadaniem jest przedstawienie zalet sprzedawanego oprogramowania i argument o tym, że oprogramowanie zostało dobrze przetestowane, nie jest czymś, na co zwraca uwagę klient końcowy. Zastanów się, czy kiedykolwiek pytałeś sprzedawcy w sklepie AGD, czy lodówka lub pralka, którą kupujesz, została należycie przetestowana? Jako klient, wychodzisz z założenia, że kupowany produkt będzie po prostu działał poprawnie.

W takim razie może programiści? W końcu to oni piszą kod programu i jeśli będzie on miał jakieś błędy, to będą musieli je poprawić. To oni najbardziej ucierpią, gdy będą musieli poprawiać błędy kosztem implementacji nowych funkcjonalności, które powinny byś wdrożone zgodnie z harmonogramem. Również oni będą musieli się tłumaczyć, dlaczego są obsuwy w terminach itp. Wychodzi więc na to, że tak naprawdę to właśnie programiści są głównym odbiorcą produktu, jakim są testy. Niestety wciąż wielu programistów uważa, że testerze przeszkadzają im w pracy, bo ciągle zgłaszają błędy i ogólnie rzecz biorąc, “czepiają się“. Na szczęście takie podejście spotykane jest coraz rzadziej, szczególnie wtedy, gdy tworzone są interdyscyplinarne zespoły, gdzie zarówno tester, jak i programista jest członkiem tego samego zespołu, a tzw. dowiezienie implementowanej funkcjonalności zależy również od tego, czy została ona przetestowana.

Podsumowanie

Testy są produktem i to niezależnie od tego, czy są to testy automatyczne, manualne, penetracyjne, wydajnościowe czy dowolny inny ich rodzaj. Nawet testy jednostkowe (z ang. unit testy) również są produktem, choć w tym przypadku, jest on wytworem wewnętrznym zespołu programistów. Ich cel jest taki sam, czyli dostarczyć informacji na temat oprogramowania i poprawności jego implementacji.

Podejście do testów, jako produktu niesie za sobą bardzo dużo reperkusji i daje testerom, bardzo mocny argument w sporach pomiędzy testerami a programistami, którzy czasem zbyt bardzo próbują ingerować w testy (np. próbując narzucić, w jakim języku programowania należy implementować testy automatyczne). Podniesienie argumentów dotyczących tego, że to testerzy są wytwórcą testów i mają odpowiednią wiedzę oraz umiejętności do ich wytworzenia, a programiści są klientem, który może co najwyżej podpowiadać, w jakim kierunku produkt się rozwija, powinno kończyć wszelkie spory. Tak zdaję sobie sprawę, że nie do każdego takie argumenty mogą trafić oraz że narzucają na testerów odpowiedzialność za testy, ale jak to mówił pewien klasyk with great power, comes great responsibility.

Zapraszam do newslettera

Jeśli powyższy artykuł uznajesz za wartościowy oraz masz ochotę być informowany o nowościach na moim blogu, to zachęcam Cię do zapisania się do mojego newslettera. Obiecuję, że nie będę Cię spamował, a tylko od czasu do czasu wyślę Ci powiadomienie o nowym artykule lub prześlę krótkiego maila z ciekawymi informacjami.
BONUS: Dodatkowo otrzymasz mój mini poradnik: Jak zacząć automatyzować testy? Czyli 12 pytań i odpowiedzi, które w tym pomogą

Imię
Nazwisko
E-mail

Wszystkie podane przez Ciebie dane, będą przetwarzane zgodnie z polityką prywatności.

Komentarze

Comments powered by Disqus