50 pytań rekrutacyjnych na testera QA z odpowiedziami

Jak korzystać z tej listy

Pytania ułożyłem według sylabusa ISTQB Foundation Level (v4.0), a potem dodałem tematy, które na rozmowach padają najczęściej: API, automatyzację i strategię testów. Każdy dział ma oznaczony poziom, więc łatwo wybrać, od czego zacząć.

Odpowiedzi są celowo krótkie. Na rozmowie nikt nie oczekuje recytowania definicji. Rekruter chce sprawdzić, czy rozumiesz pojęcie i potrafisz je zastosować. Dlatego przy każdej odpowiedzi warto mieć w zanadrzu jeden przykład z własnej pracy, nawet z projektu szkoleniowego.

Tam, gdzie ma to znaczenie, dopisałem wskazówkę, jak wyjść poza definicję.

Podstawy testowania

Poziom: podstawy.

1. Czym jest testowanie oprogramowania?

To zestaw działań, które mają ocenić jakość produktu i zmniejszyć ryzyko awarii po wdrożeniu. Obejmuje nie tylko uruchamianie aplikacji, ale też planowanie, analizę wymagań, projektowanie testów i raportowanie. Testowanie dostarcza informacji, na podstawie których zespół decyduje, czy produkt jest gotowy.

Wskazówka: mów o informacji i ryzyku, a nie tylko o “szukaniu błędów”. Tester, który rozumie, po co testuje, lepiej wybiera, co testować.

2. Czym różni się pomyłka, defekt i awaria?

• Pomyłka (error, mistake) to ludzkie działanie, np. programista źle zrozumiał wymaganie.
• Defekt (bug) to skutek pomyłki w kodzie lub dokumentacji.
• Awaria (failure) to sytuacja, w której defekt ujawnia się podczas działania systemu.

Nie każdy defekt prowadzi do awarii. Kod z defektem może nigdy nie zostać wykonany albo dawać poprawny wynik dla większości danych.

3. Wymień zasady testowania według ISTQB.

1. Testowanie ujawnia obecność defektów, ale nie dowodzi ich braku.
2. Testowanie gruntowne jest niemożliwe.
3. Wczesne testowanie oszczędza czas i pieniądze.
4. Defekty mają tendencję do kumulowania się.
5. Testy się zużywają (paradoks pestycydów).
6. Testowanie zależy od kontekstu.
7. Przekonanie o braku defektów jest błędem.

Wskazówka: sama lista niewiele mówi. Przygotuj przykład jednej zasady z praktyki, np. moduł płatności, w którym co sprint wychodzą błędy, to kumulacja defektów.

4. Czym różni się weryfikacja od walidacji?

Weryfikacja sprawdza, czy produkt spełnia specyfikację (“czy budujemy produkt dobrze”). Walidacja sprawdza, czy produkt spełnia potrzeby użytkownika (“czy budujemy dobry produkt”). Aplikacja może być zgodna z wymaganiami i jednocześnie nieprzydatna, jeśli wymagania były złe.

5. Czym różni się zapewnienie jakości (QA) od kontroli jakości (QC) i testowania?

• QA dotyczy procesu: jak zespół pracuje, żeby defektów było mniej (przeglądy, standardy, definicja ukończenia).
• QC dotyczy produktu: sprawdzanie, czy konkretny wynik pracy ma odpowiednią jakość.
• Testowanie to główna forma kontroli jakości.

W ogłoszeniach “QA” często oznacza po prostu testera, ale na rozmowie warto pokazać, że znasz różnicę.

6. Kiedy kończysz testowanie?

Gdy spełnione są kryteria wyjścia ustalone z zespołem, np. wszystkie zaplanowane testy wykonane, brak otwartych defektów krytycznych, osiągnięte pokrycie wymagań. W praktyce testy kończą się też wtedy, gdy kończy się czas, a ryzyko pozostałych obszarów jest akceptowalne dla biznesu.

Wskazówka: nie odpowiadaj “kiedy nie ma już błędów”. Zgodnie z zasadą 1 takiego momentu nie ma.

Testowanie w cyklu wytwarzania oprogramowania

Poziom: podstawy.

7. Jakie są poziomy testów?

• Testy modułowe (jednostkowe): pojedyncze funkcje lub klasy, zwykle pisane przez programistów.
• Testy integracji modułów: współpraca modułów w jednym systemie.
• Testy systemowe: cały system względem wymagań.
• Testy integracji systemów: współpraca z zewnętrznymi systemami, np. bramką płatności.
• Testy akceptacyjne: czy system spełnia potrzeby użytkownika i biznesu.

8. Czym różnią się testy funkcjonalne od niefunkcjonalnych?

Testy funkcjonalne sprawdzają, co system robi: czy przelew się wykonuje, czy filtr zwraca właściwe wyniki. Testy niefunkcjonalne sprawdzają, jak to robi: szybkość, bezpieczeństwo, użyteczność, dostępność, kompatybilność.

9. Czym różnią się testy czarnoskrzynkowe od białoskrzynkowych?

W testach czarnoskrzynkowych projektujesz przypadki na podstawie specyfikacji i zachowania, bez zaglądania w kod. W testach białoskrzynkowych opierasz się na strukturze kodu, np. żeby każda gałąź warunku została wykonana. Tester manualny pracuje głównie czarną skrzynką, programista przy testach jednostkowych białą.

10. Czym różni się retest od testu regresji?

Retest (test potwierdzający) sprawdza, czy konkretny naprawiony defekt rzeczywiście jest naprawiony. Test regresji sprawdza, czy zmiana nie zepsuła czegoś, co wcześniej działało. Po poprawce robisz zwykle oba: najpierw retest, potem regresję obszarów wokół zmiany.

11. Czym są testy smoke i czym różnią się od sanity?

Testy smoke to krótki zestaw sprawdzający, czy najważniejsze funkcje w ogóle działają i czy build nadaje się do dalszych testów. Testy sanity to szybkie, wąskie sprawdzenie konkretnego obszaru po zmianie. Terminy bywają używane zamiennie, więc warto zapytać, jak rozumie je dany zespół.

12. Czym są testy akceptacyjne i kto je wykonuje?

Testy akceptacyjne potwierdzają, że system spełnia potrzeby użytkownika i jest gotowy do wdrożenia. Wykonuje je często klient lub przedstawiciel biznesu (UAT), czasem przy wsparciu testerów. Do tej grupy należą też testy akceptacyjne zgodności z przepisami i testy operacyjne (np. kopie zapasowe, odtwarzanie po awarii).

Techniki projektowania testów

Poziom: podstawy i średni.

13. Na czym polega podział na klasy równoważności?

Dzielisz dane wejściowe na grupy, które system powinien traktować tak samo, i z każdej grupy bierzesz jedną wartość. Dla pola “wiek” przyjmującego 18-65 lat masz trzy klasy: poniżej 18, od 18 do 65, powyżej 65. Zamiast testować kilkadziesiąt wartości, testujesz trzy, a do tego klasy nieprawidłowe, np. tekst albo puste pole.

14. Na czym polega analiza wartości brzegowych?

Testujesz wartości na granicach klas, bo tam najczęściej są błędy (np. > zamiast >=). Dla zakresu 18-65 w wariancie dwupunktowym to 17, 18, 65 i 66. W wariancie trzypunktowym dochodzą wartości obok granicy po stronie poprawnej: 19 i 64.

Wskazówka: to pytanie często pada jako zadanie: dostajesz pole z zakresem i masz podać wartości testowe. Dobra odpowiedź ma granice, wartości tuż za nimi i klasy nieprawidłowe. Jeszcze lepsza zawiera pytanie o wymaganie: czy 65 to jeszcze “tak”?

15. Kiedy używasz tablicy decyzyjnej?

Gdy wynik zależy od kombinacji kilku warunków. Przykład: rabat zależy od tego, czy klient ma kartę stałego klienta i czy zamówienie przekracza 200 zł. Tablica pokazuje wszystkie kombinacje warunków i oczekiwany wynik dla każdej, więc łatwo zauważyć przypadek, o którym nikt nie pomyślał.

16. Czym jest testowanie przejść między stanami?

Opisujesz obiekt jako zbiór stanów i przejść między nimi, a potem testujesz poprawne i niedozwolone przejścia. Typowy przykład to zamówienie: nowe, opłacone, wysłane, dostarczone, anulowane. Pytanie testowe brzmi np.: czy można anulować zamówienie, które już wysłano?

17. Czym są testy eksploracyjne i kiedy mają sens?

To równoczesne poznawanie aplikacji, projektowanie i wykonywanie testów. Tester pracuje według celu (karty testu) i w ograniczonym czasie, a wnioski notuje na bieżąco. Sprawdzają się przy nowych funkcjach, słabej dokumentacji i jako uzupełnienie testów ze skryptem, bo znajdują błędy, których nikt nie przewidział w przypadkach testowych.

18. Czym różni się przypadek testowy, scenariusz testowy i lista kontrolna?

• Przypadek testowy: warunki wstępne, kroki, dane i oczekiwany wynik dla jednego sprawdzenia.
• Scenariusz testowy: ogólniejszy opis tego, co sprawdzić, np. “zakup jako gość”, często obejmuje kilka przypadków.
• Lista kontrolna: krótkie punkty do sprawdzenia, bez szczegółowych kroków.

Im bardziej doświadczony zespół i stabilny produkt, tym częściej wystarczają listy kontrolne.

Testy statyczne

Poziom: podstawy.

19. Czym są testy statyczne i co można nimi sprawdzić?

To testowanie bez uruchamiania kodu: przeglądy wymagań, historyjek, projektów, kodu i analiza statyczna narzędziami. Dzięki nim defekt w wymaganiu wychodzi, zanim ktoś napisze na jego podstawie kod. To najtańszy moment na znalezienie błędu.

20. Jakie znasz rodzaje przeglądów?

Według ISTQB: przegląd nieformalny, przejrzenie (walkthrough, prowadzi autor), przegląd techniczny (prowadzą eksperci, cel to konsensus techniczny) i inspekcja (najbardziej formalna, z rolami, metrykami i kryteriami wyjścia). W codziennej pracy najczęściej spotkasz przegląd nieformalny i code review w pull requeście.

Defekty i raportowanie

Poziom: podstawy i średni.

21. Co powinno zawierać dobre zgłoszenie defektu?

• tytuł opisujący objaw i miejsce;
• środowisko i wersję aplikacji;
• warunki wstępne (konto, dane, ustawienia);
• kroki do odtworzenia, od samego początku;
• wynik oczekiwany i wynik faktyczny, osobno;
• powtarzalność (np. 3 na 5 prób);
• załączniki: zrzut ekranu, nagranie, logi, żądanie i odpowiedź API;
• ważność i propozycję priorytetu.

Szerzej opisuję to w poradniku jak zgłaszać defekty.

Wskazówka: zamiast wyliczać pola z pamięci, pokaż przykład zgłoszenia, które programista odtworzy bez dopytywania.

22. Jak napisać dobry tytuł zgłoszenia?

Tytuł ma powiedzieć, gdzie i co się dzieje, bo zespół czyta go na liście bez otwierania zgłoszenia. “Błąd w koszyku” nic nie mówi. “Koszyk: kod rabatowy znika po zmianie liczby produktów” mówi wszystko, co potrzebne do triage.

23. Czym różni się priorytet od ważności (severity)?

Ważność opisuje skutek techniczny: jak poważnie defekt psuje działanie systemu. Priorytet opisuje, jak szybko trzeba go naprawić z punktu widzenia biznesu. Literówka w nazwie firmy na stronie głównej ma niską ważność i wysoki priorytet. Awaria rzadko używanego raportu może mieć wysoką ważność i niski priorytet.

Wskazówka: definicję zna prawie każdy. Przygotuj własny przykład defektu, w którym priorytet i ważność się rozjeżdżają.

24. Jak wygląda cykl życia defektu?

Typowo: nowy, przypisany, w naprawie, naprawiony, do weryfikacji, zamknięty. Do tego stany boczne: odrzucony, duplikat, odłożony, ponownie otwarty. Konkretne statusy zależą od narzędzia i zespołu, więc ważniejsze od nazw jest to, kto na którym etapie podejmuje decyzję.

25. Co robisz, gdy programista odrzuca zgłoszony defekt?

Najpierw sprawdzam, czy mam rację: wracam do wymagania i odtwarzam błąd jeszcze raz. Jeśli wymaganie jest niejasne, to nie spór testera z programistą, tylko pytanie do właściciela produktu. Rozmawiam o skutkach dla użytkownika, a nie o tym, kto ma rację, i dopisuję do zgłoszenia ustalenia.

26. Co robisz z defektem, którego nie da się odtworzyć?

Zbieram wszystko, co wiem: czas, środowisko, konto, logi z tego momentu, nagranie. Próbuję zmieniać po jednym czynniku: przeglądarkę, dane, kolejność kroków, szybkość klikania, połączenie sieciowe. Jeśli dalej się nie da, zgłaszam z informacją o powtarzalności “1 na 10” i wszystkim, co zebrałem. Takie zgłoszenie też ma wartość, zwłaszcza gdy błąd wróci.

27. Co powinien zawierać raport z testów?

Raport z testów różni się od zgłoszenia defektu: opisuje stan całego testowania, a nie jeden błąd. Zwykle zawiera:

• zakres i okres testów, wersję i środowisko;
• co przetestowano, a czego nie i dlaczego;
• wyniki: liczbę testów zaliczonych, niezaliczonych i zablokowanych;
• otwarte defekty według ważności, zwłaszcza krytyczne;
• ryzyka i odstępstwa od planu;
• rekomendację: czy wersja nadaje się do wdrożenia i pod jakimi warunkami.

Wskazówka: dobry raport kończy się wnioskiem. Kierownik projektu nie potrzebuje tabeli z liczbami, tylko odpowiedzi “wdrażamy czy nie i z jakim ryzykiem”.

API

Poziom: średni.

28. Czym jest REST API i jak je testujesz?

REST API to interfejs, w którym zasoby (np. /orders) obsługuje się standardowymi metodami HTTP, a dane przesyła zwykle w JSON. Testując API, wysyłam żądania z poprawnymi i niepoprawnymi danymi i sprawdzam kod odpowiedzi, treść, schemat, nagłówki i czas odpowiedzi. Narzędzia to np. Postman przy testach ręcznych oraz RestAssured lub Playwright w automatyzacji.

29. Jakie znasz metody HTTP i do czego służą?

• GET pobiera zasób;
• POST tworzy nowy zasób lub wywołuje operację;
• PUT zastępuje cały zasób;
• PATCH zmienia część zasobu;
• DELETE usuwa zasób.

Rzadziej spotkasz HEAD (same nagłówki) i OPTIONS (dostępne metody, używane m.in. przez CORS).

30. Jakie są grupy kodów odpowiedzi HTTP?

• 1xx informacyjne;
• 2xx sukces;
• 3xx przekierowania;
• 4xx błąd po stronie klienta, czyli żądanie jest niepoprawne;
• 5xx błąd po stronie serwera.

Zasada przy testach: niepoprawne dane od klienta powinny dawać 4xx. Jeśli wysyłasz zły format daty i dostajesz 500, to defekt, bo serwer nie obsłużył błędu użytkownika.

31. Omów najważniejsze kody odpowiedzi.

Wskazówka: często pada pytanie o różnicę między 401 a 403. 401 znaczy “nie wiem, kim jesteś”, 403 znaczy “wiem, kim jesteś, ale nie masz dostępu”. Drugie częste pytanie: kiedy 400, a kiedy 422. Tu nie ma jednej odpowiedzi, ważne, żeby zespół umówił się na jedną konwencję i się jej trzymał.

32. Co sprawdzasz w odpowiedzi API poza kodem statusu?

• treść: czy dane są poprawne, a nie tylko czy są;
• schemat: typy pól, pola wymagane, formaty dat;
• nagłówki, np. Content-Type, nagłówki cache i bezpieczeństwa;
• komunikat błędu: czy jest zrozumiały i nie zdradza szczegółów technicznych (np. stack trace);
• czas odpowiedzi;
• skutki uboczne: czy rekord naprawdę zapisał się w bazie albo czy poszedł e-mail.

O sprawdzaniu schematu piszę więcej w poradniku o testach kontraktowych API.

33. Czym jest idempotentność?

Operacja jest idempotentna, jeśli wykonana kilka razy daje ten sam efekt co wykonana raz. GET, PUT i DELETE powinny być idempotentne, POST zwykle nie jest. W praktyce testuję to, wysyłając to samo żądanie dwa razy, np. przy płatnościach: podwójne kliknięcie nie może pobrać pieniędzy dwa razy.

34. Jak testujesz uwierzytelnianie i uprawnienia w API?

Sprawdzam każdy endpoint bez tokena, z wygasłym tokenem, z tokenem innego użytkownika i z rolą bez uprawnień. Najczęstszy poważny błąd to dostęp do cudzych danych po podmianie identyfikatora w adresie, np. /orders/1001 zamiast /orders/1000. Takich testów nie widać w interfejsie, dlatego robi się je na poziomie API.

Automatyzacja

Poziom: średni.

35. Jakie testy warto automatyzować, a jakich nie?

Warto automatyzować testy powtarzalne, stabilne i często uruchamiane: regresję, smoke, testy API, testy na wielu danych. Nie warto automatyzować funkcji, które często się zmieniają, jednorazowych sprawdzeń, oceny wyglądu i użyteczności. Automatyzacja zwraca się po wielu uruchomieniach, więc liczy się, jak często test będzie uruchamiany.

36. Jakie są rodzaje czekania (waitów) w Selenium?

• Implicit wait: globalny czas, przez jaki sterownik ponawia szukanie elementu, zanim zgłosi błąd. Ustawiany raz dla całej sesji.
• Explicit wait: WebDriverWait z warunkiem, np. element jest widoczny albo klikalny. Czeka na konkretny stan konkretnego elementu.
• Fluent wait: explicit wait z ustawianym interwałem sprawdzania i listą wyjątków do pominięcia.

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement button = wait.until(ExpectedConditions.elementToBeClickable(By.id("submit")));

Dokumentacja Selenium odradza mieszanie implicit i explicit wait, bo czasy czekania stają się nieprzewidywalne.

Wskazówka: przygotuj się na pytanie, co jest złego w Thread.sleep(5000). Stała pauza spowalnia testy, gdy aplikacja jest szybka, i nie wystarcza, gdy jest wolna.

37. Jak czekanie działa w Playwright?

Playwright czeka automatycznie: przed kliknięciem sprawdza, czy element jest widoczny, stabilny, włączony i przyjmuje zdarzenia. Asercje typu await expect(locator).toBeVisible() ponawiają sprawdzenie do skutku albo do limitu czasu. Dzięki temu ręczne waity są potrzebne rzadko, a testy są stabilniejsze niż w Selenium. Przykłady znajdziesz w poradniku o automatyzacji regresji w Playwright.

38. Jak dobierasz lokatory?

Najlepiej po tym, co widzi użytkownik albo co jest przeznaczone do testów: rola i nazwa dostępna (getByRole), etykieta pola, atrybut data-testid. Najgorsze są długie ścieżki XPath i klasy CSS od stylów, bo psują się przy każdej zmianie wyglądu. Jeśli brakuje dobrych lokatorów, warto poprosić programistów o data-testid, to kilka minut ich pracy.

39. Czym jest wzorzec Page Object?

To sposób organizacji kodu testów: każda strona lub komponent ma klasę z lokatorami i akcjami (np. LoginPage.login(user, password)), a testy korzystają z tych metod. Gdy zmieni się interfejs, poprawiasz jedno miejsce zamiast dziesięciu testów. Wadą jest dodatkowa warstwa kodu, więc przy kilku testach bywa przesadą.

40. Co robisz z niestabilnymi (flaky) testami?

Najpierw ustalam przyczynę: czekanie na element, zależność między testami, wspólne dane, środowisko, faktyczny błąd w aplikacji, który występuje losowo. Niestabilny test oznaczam i przenoszę do kwarantanny, żeby nie blokował zespołu, ale z terminem naprawy. Ponawianie testów bez szukania przyczyny ukrywa problem, a czasem prawdziwy błąd.

Wydajność i testy niefunkcjonalne

Poziom: średni.

41. Jakie znasz rodzaje testów wydajności?

• Obciążeniowe: zachowanie przy spodziewanym ruchu.
• Przeciążeniowe (stress): co się dzieje powyżej przewidywanego ruchu i gdzie jest punkt załamania.
• Testy skoków (spike): nagły wzrost ruchu, np. start promocji.
• Testy długotrwałe (soak, endurance): stały ruch przez wiele godzin, wykrywają np. wycieki pamięci.

42. Na jakie metryki patrzysz w testach wydajności?

Czas odpowiedzi jako percentyle (p95, p99), a nie tylko średnią, bo średnia ukrywa wolne żądania. Do tego przepustowość (żądania na sekundę), odsetek błędów i zużycie zasobów serwera: procesor, pamięć, połączenia z bazą. Wynik ma sens tylko w porównaniu z celem, np. “p95 poniżej 800 ms przy 200 użytkownikach”. Przykład konfiguracji opisuję w poradniku o testach wydajności w JMeter.

43. Co sprawdzisz w ramach podstawowych testów bezpieczeństwa?

Tester bez specjalizacji w bezpieczeństwie może sprawdzić sporo: dostęp do cudzych danych po zmianie identyfikatora, uprawnienia ról, walidację danych wejściowych (np. skrypt w polu tekstowym), wygasanie sesji po wylogowaniu, komunikaty błędów zdradzające szczegóły systemu, limity prób logowania. Pełny test penetracyjny to osobna specjalizacja i warto to powiedzieć wprost.

Strategia i proces

Poziom: zaawansowany.

44. Dołączasz do projektu, w którym nikt nie testował. Od czego zaczynasz?

Od zrozumienia produktu i ryzyka: rozmowa z właścicielem produktu i programistami, przegląd zgłoszeń z produkcji, najważniejsze ścieżki użytkownika. Potem szybkie testy eksploracyjne najważniejszych obszarów i krótki zestaw smoke przed każdym wdrożeniem. Proces i automatyzację buduję stopniowo, zaczynając od miejsc, gdzie błędy kosztują najwięcej. Od tego zaczynam też audyt QA.

Wskazówka: zacznij odpowiedź od pytań, a nie od narzędzia. “Wdrożę Selenium” w pierwszym zdaniu to zła kolejność.

45. Na czym polega testowanie oparte na ryzyku?

Oceniasz każdy obszar według prawdopodobieństwa awarii i jej skutku, a potem przydzielasz testy według tego iloczynu. Płatności i logowanie dostają najwięcej uwagi, strona “O firmie” najmniej. Dzięki temu przy ograniczonym czasie wiesz, czego nie testujesz, i możesz to świadomie zakomunikować.

46. Czym jest piramida testów?

To model proporcji: dużo szybkich testów jednostkowych na dole, mniej testów integracyjnych i API w środku, najmniej testów przez interfejs na górze. Testy przez UI są najwolniejsze i najbardziej kruche, więc nie powinny być główną siatką bezpieczeństwa. Odwrócona piramida (prawie wszystko przez UI) to częsty problem w zespołach, które zaczęły automatyzację od Selenium.

47. Jakimi metrykami mierzysz jakość i pracę testów?

Przydatne są: liczba defektów znalezionych na produkcji w porównaniu z tymi sprzed wdrożenia, czas od zgłoszenia do naprawy defektów krytycznych, czas trwania regresji, pokrycie wymagań lub ryzyk testami. Liczba zgłoszonych błędów na testera albo liczba przypadków testowych to złe metryki, bo nagradzają ilość, a nie skutek.

Wskazówka: pokaż, że wiesz, jakie zachowania wywoła dana metryka. Każda metryka, która staje się celem, zaczyna być “optymalizowana”.

48. Jak wbudowujesz testy w CI/CD?

Krótki zestaw smoke uruchamia się przy każdym pull requeście, pełna regresja nocą albo przed wydaniem. Wynik musi być szybki i wiarygodny, inaczej zespół zacznie go omijać. Do tego raporty z testów dostępne w pipeline i jasna zasada, co robimy, gdy test nie przejdzie. Szczegóły opisuję w poradniku o regresji w CI.

49. Jak testujesz, gdy nie ma wymagań?

Wymagania istnieją zawsze, tylko nie są zapisane. Szukam ich w rozmowach z właścicielem produktu, w działającej wersji, u konkurencji, w zgłoszeniach od użytkowników i w przepisach. Testy eksploracyjne pomagają poznać zachowanie systemu, a każde wątpliwe zachowanie zapisuję jako pytanie. Odpowiedzi na te pytania stają się zaczątkiem dokumentacji.

Zadania praktyczne

Poziom: każdy.

50. Jak przetestujesz formularz logowania?

To pytanie sprawdza sposób myślenia, nie znajomość definicji. Dobra odpowiedź obejmuje kilka warstw:

• funkcjonalne: poprawne dane, błędne hasło, nieistniejący użytkownik, puste pola, wielkość liter w e-mailu, spacje na początku i końcu;
• bezpieczeństwo: blokada po kilku nieudanych próbach, ten sam komunikat dla złego loginu i złego hasła, hasło niewidoczne w adresie i logach, wygasanie sesji;
• użyteczność i dostępność: obsługa klawiaturą, Enter wysyła formularz, menedżer haseł działa, komunikaty są zrozumiałe;
• inne: “zapamiętaj mnie”, reset hasła, logowanie na kilku urządzeniach, zachowanie przy wolnym połączeniu, różne przeglądarki i telefony.

Wskazówka: zanim zaczniesz wymieniać testy, zadaj pytania: kto się loguje, czy jest logowanie przez Google, czy jest weryfikacja dwuetapowa. Podobnie z klasycznym “przetestuj długopis”: nie chodzi o długopis, tylko o to, czy zapytasz, do czego ma służyć.

Na koniec

Na rozmowie bardziej niż definicje liczy się to, czy umiesz pokazać, jak myślisz: zadajesz pytania, oceniasz ryzyko i opisujesz problem tak, żeby inni mogli go naprawić. Jeśli przygotowujesz się do pierwszej pracy, zacznij od działów oznaczonych jako podstawy i przy każdym pytaniu dopisz własny przykład. Tematy z tej listy omawiam szerzej w serii “Testowanie od podstaw”, która zaczyna się od wpisu czym zajmuje się tester i jak zacząć.

Jeśli prowadzisz zespół i potrzebujesz doświadczonego testera do projektu albo chcesz uporządkować testy, napisz do mnie.