„Proszę powiedzieć, jak przetestowałby Pan ołówek?” Uff. Umiem! Wiem! Znam! „Jasne, czy są jakieś konkretne wymagania dla tego ołówka? Może dowiem się, jakie funkcje powinien mieć?” – Odpowiadasz wyuczony. Rekruter uśmiecha się, a Ty wiesz, że jest dobrze. „Na koniec przygotowaliśmy jeszcze jedno zadanie dla Pana” – mówi i podaje Ci laptopa. Na ekranie widzisz formularz. „Proszę przetestować naszą aplikację do zakupu biletów” – dodaje. I co teraz?
Cześć! Dzisiaj wpis właśnie o tym konkretnym zadaniu praktycznym, które zdarzyć się może na rekrutacji na testera oprogramowania. Temat rozmów rekrutacyjnych, pytań na rozmowach rekrutacyjnych i tego, jakie są etapy rekrutacji, przerabiałem na blogu już kilkukrotnie. Zachęcam do zapoznania się ze wszystkimi wpisami, jeśli jesteś na etapie nauki testowania i przygotowujesz się do ewentualnych rozmów.
Jednym z zadań praktycznych, które zdarzają się na rozmowie kwalifikacyjnej, jest przetestowanie na żywo w obecności rekrutera fragmentu jakiejś aplikacji. Jeśli trafisz na rozmowę ze mną, to takie zadanie zapewne dostaniesz.
Najczęstszym błędem jest chaos.
Z moich obserwacji wynika, że kandydaci najczęściej natychmiast przystępują do testów i jakby nie patrzeć po prostu klikają we wszystko. Działania te są chaotyczne i nieprzemyślane. Polegają bardziej na wpadaniu na błąd niż go znalezieniu.
Obserwując sposób podejścia kandydata do zadania praktycznego, można zobaczyć brak umiejętności przeniesienia pytania „przetestuj ołówek” na realia praktycznego zadania. Co za tym idzie brak wiedzy praktycznej.
Teraz pewnie drapiesz się po głowie, zadając sobie pytanie „Skąd Ci się Waldek wzięło porównanie zadania praktycznego do testowania ołówka?”. Już objaśniam. Uogólniając pytanie o przetestowanie ołówka, które często jest wyśmiewane, ma na celu wydobycie przede wszystkim odpowiedzi kandydata „Czy jest jakaś specyfikacja?”.
Podczas wykonywania zadania praktycznego często zapomina się o tym, by dobrze poprowadzić swoje testy. To znaczy, żeby w pierwszej kolejności skupić się na tym, co jest napisane w specyfikacji.
Jak podejść do zadania praktycznego?
Zapytaj, czy jest dla aplikacji napisana specyfikacja. Jeśli jest, to zapoznaj się z nią. Prawda jest taka, że naprawdę dobrze przygotowanych procesów rekrutacyjnych jest mało. Jednym słowem, jeżeli trafisz na zadanie praktyczne, to prawdopodobnie będzie miało ono bardzo prostą specyfikację. Zapoznaj się z nią, następnie przystąp do testów.
W większości wypadków aplikacja będzie miała łatwe do znalezienia błędy. Znajdziesz zatem literówki i może jakieś drobne błędy funkcjonalne (ale czasami się trafia, że nawet tych nie ma).
Jeśli aplikacja nie ma specyfikacji, to zadaj pytania. Zapytaj o formularz, na który patrzysz, o walidacje i o to na przykład czy są jakieś ograniczenia (przykładowo osoba poniżej 18 roku życia nie może dokonać zakupu). Następnie przystąp do testów.
Poproś o kartkę i coś do pisania. Zawsze radzę swoim kursantom, by robili notatki. Jako rekruter nie obrażę się, jeżeli poświęcisz pięć minut i sobie rozpiszesz pomysły co sprawdzić w aplikacji. Więcej, byłoby idealnie, jakbyś umiał opowiadać o tym, co planujesz przetestować w trakcie rozpisywania, ale cudów nie wymagam ;). Kartka, długopis i notatki to już dużo.
Jako osoba biorąca udział w niejednej rekrutacji uważam, że sprawdzane „na pałę” po raz setny tych samych rzeczy w byle jaki sposób jest niepoprawne. Trzeba wiedzieć jak według twórcy/klienta ma aplikacja działać, bo to, co w większości aplikacji jest ok, nie musi być ok w tej konkretnej. Z moich obserwacji wynika, że większość kandydatów najczęściej nastawia się na intuicyjną walidację danych w kolejnych polach.
Bywają jednak wyjątki od reguły.
Co zrobić, jeżeli trafi Ci się jednak całkiem fajna aplikacja do przetestowania z całkiem pokaźną specyfikacją? Kiedyś przechodziłem rekrutację pod okiem Pauliny, którą kilka lat temu przedstawiłem na blogu.
Aplikacja miała przygotowaną specyfikację, w dodatku moim zdaniem napisana była na dobrym poziomie (jak na potrzeby rekrutacji) i zawierała naprawdę fajne przykłady realne. Przykłady te jednocześnie w mojej ocenie mogły podczas samej weryfikacji kandydata pomóc w ocenie jego doświadczenia.
Przykład
W specyfikacji przyciski „Zarejestruj/Zaloguj” były umieszczone w bardzo nietypowym dla siebie miejscu. W samej aplikacji znajdowały się one tam, gdzie przeważnie możesz je spotkać, w prawym górnym rogu. Jako kandydat mógłbym zgłosić defekt w aplikacji, natomiast w tym konkretnym wypadku zgłosiłbym błąd w dokumentacji. Uzasadniłbym to tym, że standardy rynkowe są takie, a nie inne. Moje zgłoszenie powinno być rozważone przed potencjalną decyzją o przekazaniu defektu do poprawy, ponieważ możemy uznać, że z powodów użyteczności nie ma sensu tego ruszać.
Dzięki! Bardzo treściwy i przydatny wpis.