Podstawy, zarówno procesu wytwarzania oprogramowania jak i samego testowania - jest to chyba najważniejsza część, bez której nie ma sensu przeprowadzać dalszych etapów rozmowy. Braki wiedzy w tym zakresie mogą być źródłem wielu nieporozumień i problemów podczas przyszłej współpracy kandydata z pozostałymi członkami zespołu. Dlaczego? Ponieważ, niejednokrotnie, niezrozumienie cyklu wytwarzania oprogramowania powoduje zażarte dyskusje na temat etapów prac, sensu pewnych procedur, spotkań, etc. Warto tutaj zaznaczyć, że w przypadku, gdy w obecnym/poprzednim miejscu pracy cały proces wydawał nam się sensowny i się do niego przyzwyczailiśmy, to nie oznacza, że jest jedynym słusznym.

Inaczej wytwarza się oprogramowanie krytyczne z punktu widzenia bezpieczeństwa czy niezawodności – grożące śmiercią bądź kalectwem ludzi – a zupełnie inaczej wytwarza się aplikacje rozrywkowe. Inaczej wytwarza się program budując go od podstaw – a jeszcze inaczej można zarządzać projektem rozwijającym już istniejący produkt, poprawiającym powstałe błędy i usprawniającym przestarzałe rozwiązania.

Jest to (chyba) wystarczający powód, dlaczego rekruter zechce dowiedzieć się, jakie jest Wasze doświadczenie, z jakimi metodologiami mieliście styczność w pracy zawodowej. Natomiast, przypuszczam, iż najczęściej skupi się na podejściu obowiązującym w danej firmie, tudzież w potencjalnym projekcie, do którego możesz trafić.

I. Modele i metodyki wytwarzania oprogramowania

Jako przysłowiowy MUST-HAVE można potraktować metodologie opisane między innymi w ISTQB foundation level:

• model V (z podziałem na poziomy testowania)
• modele iteracyjno-przyrostowe (zebrane w krótsze cykle, gdzie różne poziomy testowania mogą odbywać się w ciągu jednej iteracji)

Jako dodatkowe rozróżnienie można posiłkować się sylabusem z poziomu zaawansowanego, który rozróżnia:

• modele sekwencyjne (np. model kaskadowy (Waterfall), model V, model W)
• modele iteracyjne i/lub przyrostowe (np. RAD, RUP)
• metodyki zwinne (np. SCRUM, Extreme Programming (XP) czy Kanban)
• model spiralny (związany z eksperymentowaniem i prototypami)

Jak wspomniałem – warto znać przynajmniej podstawy i kiedy wykorzystuje się określony model/metodykę. Natomiast w przypadku potencjalnego projektu – warto poszerzyć swoją wiedzę i potrafić wskazać wady i zalety w stosunku do innych (głównych) metod.

II. Podstawy podstaw

Druga pula pytań może (i powinna) dotyczyć samych podstaw testowania, a zatem znajdą się tutaj takie pytania jak:

• czym jest testowanie?
• jakie są jego cele?
• jakie są poziomy testowania?
• jakie są fazy testowania?

Czym jest testowanie? Każdy to może rozumieć na swój sposób, aczkolwiek warto pamiętać, iż jest to proces, w którym samo wykonywanie testów na działającym oprogramowaniu jest tylko wierzchołkiem góry lodowej.
Idąc za sylabusem ISTQB, warto pamiętać, iż:

Czynności testowania występują zarówno przed, jak i po wykonywaniu testów. Należą do nich:
• planowanie i nadzór,
• wybór warunków testowych,
• projektowanie i wykonywanie przypadków testowych,
• sprawdzanie wyników, ocena spełnienia kryteriów zakończenia,
• raportowanie procesu testowania i testowanego systemu
• kończenie i zamykanie testów (po zakończeniu fazy testów).

Do testowania zalicza się także przeglądy dokumentacji i kodu źródłowego oraz analizę statyczną.

Główne cele testowania, to:
• znajdowanie usterek
• nabieranie zaufania do poziomu jakości
• dostarczanie informacji potrzebnych do podejmowania decyzji
• zapobieganie defektom

Poziomy testowania (poruszane m.in. przy V-modelu) można natomiast podzielić na:
• testy modułowe (wykonywane w izolacji od reszty systemu, mogą to być np. unit testy)
• testy integracyjne (czyli komunikacja pomiędzy modułami, interakcje z innymi elementami systemu (np. bazą danych, sprzętem, etc.)
• testy systemowe (przeprowadzane na środowisku możliwie zbliżonym do produkcyjnego; mogą zawierać testy zarówno funkcjonalne jak i niefunkcjonalne)
• testy akceptacyjne (przeprowadzane często przez klienta lub potencjalnych użytkowników; często oceniają gotowość do wdrożenia, choć nie muszą stanowić ostatniego etapu testów!)

Fazy testowania można podzielić np.:

1. Analiza wymagań
2. Planowanie testów
3. Projektowanie testów
4. Przygotowywania środowiska
5. Wykonywanie testów
6. Raportowanie
7. Czynności zamykające

III. Organizacja pracy

Do trzeciej grupy pytań zaliczyłbym wszystko, co jest związane z podejściem do testowania i przygotowywania przypadków testowych:
• Typy testów (funkcjonalne, niefunkcjonalne, strukturalne, retesty/regresja)
• Techniki testowania (statyczne i dynamiczne)
• Proces przeglądu (formalne, nieformalne), jego etapy (planowanie, rozpoczęcie, przygotowanie, spotkanie, poprawki, zakończenie),role i odpowiedzialności (kierownik, moderator, autor, przeglądający i protokólant) oraz cele.
• Techniki projektowania testów (oparte na specyfikacji - czarnoskrzynkowe, oparte na strukturze - białoskrzynkowe, oparte na doświadczeniu)
• Techniki czarnoskrzynkowe (klasy równoważności, analiza wartości brzegowych, tablica decyzyjna, przejścia między stanami, przypadki użycia) – warto tutaj zaznaczyć, iż dobrego rekrutera nie interesuje definicja, a raczej poprawny przykład użycia w praktyce!
• Techniki białoskrzynkowe (pokrycie instrukcji, pokrycie decyzji, pokrycie warunków itp.) – są to bardziej techniczne sposoby, więc nie zdziwiłbym się, gdyby rekruter przygotował kawałek kodu, a na jego podstawie poprosił o zaproponowanie przypadków testowych!
• Techniki oparte na doświadczeniu (zgadywanie błędów i testy eksploracyjne) – warto wiedzieć kiedy warto takie techniki stosować oraz w jaki sposób je systematyzować
• Czynniki wpływające na wybór technik do projektowania testów (typ systemu, regulacje prawne, wymagania klienta, poziom ryzyka, typ ryzyka, cel testów, dokumentacja, wiedze i doświadczenie testerów, czas/budżet, cykl/etap rozwoju itp.)

IV. Bugi, taski, Test Case'y

Czwarta grupa pytań, którą wydzieliłbym z pośród podstawowych zagadnień, dotyczyłaby zarządzania ticketami (bugami, taskami, test caseami itp.). Bardzo praktyczna część, aczkolwiek warto się do niej przygotować i zawczasu odpowiedzieć na kilka zasadniczych pytań:
• Jaki jest workflow poszczególnych ticketów (z jakimi przepływami się spotkałeś/spotkałaś – czego brakowało, co można by pominąć, etc.)
• Czym jest PRIORITY a czym SEVERITY – generalnie bardzo dużo osób „wykłada się” na tym dość prostym pytaniu
• Jakie pola powinny zostać uzupełnione podczas zgłaszania nowego buga (ewentualnie w Test Case’ie), czy są obowiązkowe, czy są możliwe odstępstwa, czy warto coś zmienić/dodać/usunąć itp. pytania mające na celu sprawdzenie kandydata pod względem obycia z danym zagadnieniem
• Standardy (IEE 829) w kwestii zarządzania defektami

V. Role i odpowiedzialności

Ostatnią grupę pytań z zakresu podstawowego zamknąłbym zagadnieniami związanymi z rolami w projekcie oraz podziałem obowiązków pomiędzy poszczególnymi członkami zespołu.
• Warto wziąć pod uwagę poszczególnych członków zespołu i potrafić wyjaśnić ich rolę/zakres obowiązków (np. Product Owner, Business Analyst, Project Manager, Scrum Master, Tech Leader, Developer, Tester itd.)
• Warto rozważyć jaki rodzaj problemu jest zgłaszany do konkretnej osoby, na jakim etapie, jakie mogą być tego skutki/sposoby rozwiązania – wszystko co może pokazać Wasze dotychczasowe doświadczenie, zrozumienie podziału obowiązków, etc. – czasem w kontekście używanej metody wytwarzania oprogramowania.
• W przypadku firm współpracujących z klientami zza oceanu (USA) – mogą się też pojawić pytania rozgraniczające role pomiędzy QA a QC i tutaj również warto się zawczasu przygotować, aby potrafić wskazać różnice w obowiązkach itp.

Wydaje mi się, iż to by było na tyle, jeżeli chodzi o podstawy testowania… w kolejnej części opiszę zagadnienia bardziej zaawansowane (planowanie, estymacja, zarządzanie ryzykiem itd.).
CDN…