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.:
- Analiza wymagań
- Planowanie testów
- Projektowanie testów
- Przygotowywania środowiska
- Wykonywanie testów
- Raportowanie
- 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…