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ń.

Wojciech Pająk