Pytanie rekrutacyjne: "Jak przetestować...?"

Kilka przykładowych odpowiedzi, jakie powinien udzielić rekrutowany:

1. "Czy jest jakaś specyfikacja?" - to odpowiedź na mistrza testowania, który pokazuje, że w testach zawsze zaczynamy od analizy wymagań, bo testowanie to sprawdzenie przedmiotu z oczekiwaniami użytkownika.
2. "Zaprojektuję zestaw testów..." - tester bez specyfikacji testowej jest jak bez ręki. Jeśli nie ma specyfikacji, to napiszę ją sobie sam; jeśli jest, to przerobię ją w przypadki testowe. 
3.  "Testuję funkcję X, funkcję Y, ... sprawdzam niezawodność." - odpowiedzą testerzy eksploracyjni, którzy nie marnują czasu na projektowanie testów tylko od razu biorą się do pracy.
4. "To dość proste, więc zastanowię się nad automatyzacją." - powinno wybrzmieć, gdy rekrutacja dotyczy stanowisk na testera automatyzującego.
5.  "Zaczynam od planowania..." - kierownik testów zawsze zaczyna od dobrego zestawu aktywności, harmonogramu oraz ryzyk.
6. "Obserwacja jak tym obiektem posługuje się [reprezentatywny] użytkownik."

Nie wyczerpuje to oczywiście wszystkich możliwych odpowiedzi. Jest przynajmniej jedna ekstra, którą nazywam "testerski mądrala", który analizując poszczególne odpowiedzi zada sobie pytania:

ad 1. naprawdę potrzebuję specyfikacji?
ad 2. czy jest sens projektować testy do jednokrotnego uruchomienia?
ad 3. na testy chyba jeszcze trochę za wcześnie?
ad 4. czy automatyzacja tu się naprawdę opłaci?
ad 5. czy moi stakeholderzy (interesariusze) naprawdę oczekują ode mnie planu?
ad 6. czy dostęp do obserwowania (monitorowania) rzeczywiście jest łatwy?

Ktoś kazał Ci przetestować urządzenie proste jak cep - więc co jest z nim nie tak (z testowanym produktem, nie pytającym)? Jako średnio rozgarniętemu użytkownikowi wystarczy Ci jakieś 30 sekund na sprawdzenie obiektu. Pierwsze pytanie wybrzmi więc "Czy jest coś specyficznego w tym obiekcie?". Odpowiedź na to pytanie powinna nakierować Cię na rozwiązanie - czy rzeczywiście niezbędne są jakieś szczególne umiejętności i wiedza do sprawdzenia tego produktu? Oczywiście już samo zadawanie pytań może być dla drugiej strony złym sygnałem. Tester powinien być przecież samodzielnym stanowiskiem i sam powinieneś sobie znaleźć odpowiedzi i od razu wziąć się do działania. to bzdura. im więcej informacji posiadamy, tym efektywniejsi jesteśmy w swoim testowaniu. dlatego też przetwarzamy zadanie w user story (historyjkę użytkownika) i ładnie prosimy o odpowiedź na kilka pytań, które pozwolą nam uzupełnić poniższy szablon:

JAKO [kim jest użytkownik], CHCĘ [co chcesz osiągnąć przez użycie obiektu], by [jaka jest motywacja użytkownika].

Jeśli do tego sformujemy formalne / nieformalne kryteria sukcesu, to już potem będziemy mogli określić czy potrzebujemy dokumentacji, testów czy automatów.

PS. Każda z powyższych odpowiedzi może być poprawna / niepoprawna w oczach rekrutera. zanim udzielimy odpowiedzi, warto najpierw zrozumieć kontekst stanowiska, o które się ubiegamy oraz organizację, do której aplikujemy. Możemy to zrobić analizując wymagania zawarte w ogłoszeniu o pracę czy w oparciu o rozmowę z samym rekruterem. Innej odpowiedzi udzielimy w przypadku, gdy staramy się o pracę automatyka, a innej w organizacji produkującej systemy o wysokiej krytyczności.