Testowanie to nie klikanie, czyli umiejętności nowoczesnego testera
Testowanie oprogramowania wykonywane jest w określonym celu – znaleźć jak najwięcej krytycznych błędów zanim zrobią to użytkownicy. Samo znalezienie błędów nie jest, rzecz jasna, wystarczające, ale to co się z nimi stanie to zazwyczaj już nie nasze zmartwienie…
Jak znaleźć błędy? Gdzie ich szukać? Jak testować? Często stawiamy sobie takie pytania i próbujemy zdefiniować złoty środek. Pamiętajmy, że testowanie jest zależne od kontekstu naszego projektu – specyfiki oprogramowania, wymagań użytkownika, branży, dostępności narzędzi, czy wreszcie naszych umiejętności. Jakie powinniśmy posiadać kompetencje chcąc testować efektywnie, ograniczając pracochłonność i zwiększając skuteczność? Czy faktycznie potrzebujemy konkretnych umiejętności? Przecież testować może każdy, wystarczy znać się trochę „na komputerach”, mieć pewne doświadczenia z systemami informatycznymi, wiedzieć co to mysz, klawiatura i jak się ich mniej więcej używa. I choć do dziś w wielu firmach taki pogląd jest jeszcze aktualny, to szczęśliwie dla nas wartość testowania, a co za tym idzie samych testerów jest zauważalna i doceniana.
Przedstawiam Wam kilka (moim zdaniem) najważniejszych umiejętności, które powinni dziś posiadać testerzy oprogramowania, aby sprostać wymaganiom stawianym obecnie zespołom wytwórczym i pokazać w praktyce, sobie i innym, że testowanie to nie tylko klikanie.
Po pierwsze. Podstawy programowania.
Po co to komu? Przecież programują programiści. To fakt, ale popularne w ostatnich latach zwinne metodyki wytwarzania oprogramowania, ukierunkowane przede wszystkim na wartość biznesową, skracają cykl życia produktu informatycznego i bardzo często kod źródłowy powstaje niemalże bezpośrednio na podstawie wymagań. Kiedy tester zostaje bez obszernej specyfikacji funkcjonalnej i otrzymuje dość ogólnie opisane „historie użytkownika” musi testować na podstawie doświadczenia, albo przejrzeć dziwnie wyglądające pliki napisane przez kolegę. Choćby pobieżne zapoznanie się z instrukcjami, warunkami czy pętlami na pewno pozwoli nam:
- przynajmniej zrozumieć kod źródłowy
- wstępnie go przeanalizować
- zaprojektować lepsze testy
- być może coś zautomatyzować
- efektywniej współpracować z programistami
A jeśli komuś zamarzy się podejście do egzaminu ISTQB, powyższa umiejętność może okazać się bezcenna, żeby odpowiedzieć na pytanie typu: dla podanego pseudokodu, jaka jest minimalna liczba przypadków testowych, niezbędna aby osiągnąć 100% pokrycia instrukcji oraz 100% pokrycia rozgałęzień? Bez znajomości podstaw programowania może być ciężko i nie pozostanie nic innego jak pętla na pierwszym rozgałęzieniu. Gałęzi. Na szyję.
Po drugie. Umiejętne wykorzystanie narzędzi.
Dzisiaj znalezienie gotowych rozwiązań, darmowych czy komercyjnych w internecie nie stanowi większego problemu. Łatwo także możemy sprawdzić opinie i doświadczenia kolegów po fachu na rozmaitych forach, co pozwoli zaoszczędzić nam nauki na własnych błędach. Po co narzędzia? Aby wspierać takie czynności jak:
- analiza statyczna i dynamiczna
- automatyzacja testów
- testy wydajności i niezawodności
- analiza wyników
- generowanie raportów
Po trzecie. Umiejętności analityczne.
Jeśli spotka nas zaszczyt wzięcia udziału w przeglądzie i to jeszcze specyfikacji, która faktycznie powstała, trzeba wiedzieć jak to ugryźć. Wytrawny tester wie, że poza znajdowaniem błędów istnieje też coś takiego jak zapobieganie tymże. W trakcie lektury można zatem zidentyfikować mnóstwo wieloznaczności, ogólników, pomyłek i braków, które da się wyeliminować przed implementacją kodu. Lepsze specyfikacja, to nie tylko mniej problemów w kolejnych fazach przedsięwzięcia, ale także wyższej jakości testy. Wspomniane kompetencje na pewno przydadzą się podczas:
- czytania specyfikacji
- uczestnictwa w przeglądach
- projektowania testów
Po czwarte. Wiedza na temat projektów informatycznych.
Kiedy role w projekcie są umowne, a zespół jest interdyscyplinarny, trzeba się nieco zorientować w sytuacji. Jaka jest nasza metodyka wytwarzania oprogramowania, a jaka klienta? Kto bierze udział w UAT-ach, a kto w OAT-ach? Czym różni się analityk biznesowy od systemowego i dlaczego deweloper nie zajmuje się tylko budowlanką? Im lepiej się orientujemy, tym łatwiej nam się dostosować i dlatego musimy rozumieć:
- role: kto jest kim?
- procesy „okołotestowe”
- analiza biznesowa, wymagania, zarządzanie zmianą i konfiguracją
- metodyki wytwarzania oprogramowania
- kontekst projektów
- kim są klienci, użytkownicy
Po piąte wreszcie. Umiejętności miękkie.
Zdarza się, że komunikacja testera nie ogranicza się do wymiany doświadczeń i dowcipów na temat programistów z innymi testerami. Czasem trzeba porozumieć się z analitykiem, kierownikiem projektu, produktu, czy też testerem lub deweloperem z drugiego końca świata. Nierzadko musimy sobie też coś wywalczyć: dodatkowe zasoby, więcej czasu, czy też przeciągnąć kogoś na swoją stronę. Warto także poznać podstawowe zwyczaje i zachowania naszych współpracowników, którzy reprezentują inne grupy kulturowe, aby uniknąć przykrych nieporozumień. Kolejne atrybuty nowoczesnego testera to:
- efektywna komunikacja z „udziałowcami” projektów
- umiejętne zarządzanie czasem i priorytetyzacja działań
- asertywność
- obiektywizm
- zdolności negocjacyjne
Zawód testera może być pełen wyzwań i stanowić początkowy etap atrakcyjnej ścieżki kariery w świecie IT. Możliwości rozwoju jest wiele i to od nas przede wszystkim zależy ile będziemy wymagać sami od siebie i jak będą nas postrzegać inni. Tester nowoczesny wie, że testowanie to nie tylko klikanie i potrafi to pokazać w realizacji codziennych zadań.