30 pytań na rozmowie kwalifikacyjnej QA – pytania i przykładowe odpowiedzi

Rozmowa kwalifikacyjna na stanowisko QA może obejmować zarówno podstawy testowania oprogramowania, jak i pytania praktyczne, techniczne oraz sytuacyjne.

Rekruter może sprawdzić między innymi:

• znajomość podstaw testowania,
• umiejętność projektowania przypadków testowych,
• sposób raportowania błędów,
• znajomość procesu tworzenia oprogramowania,
• podstawy testowania API, baz danych i aplikacji internetowych,
• umiejętność pracy w zespole,
• sposób reagowania na problemy pojawiające się w projekcie.

Poniżej znajdziesz 30 popularnych pytań, które mogą pojawić się podczas rozmowy kwalifikacyjnej na stanowisko QA, testera manualnego lub początkującego testera automatyzującego.

1. Czym zajmuje się tester oprogramowania?

Tester oprogramowania odpowiada za sprawdzanie jakości aplikacji oraz wykrywanie problemów, które mogą wpłynąć na użytkowników lub działanie systemu.

Do jego zadań może należeć:

• analiza wymagań,
• przygotowywanie przypadków testowych,
• wykonywanie testów,
• zgłaszanie błędów,
• weryfikowanie poprawek,
• wykonywanie testów regresji,
• współpraca z programistami, analitykami i właścicielami produktu.

Warto zaznaczyć, że tester nie odpowiada wyłącznie za znajdowanie błędów. Jego zadaniem jest również dostarczanie zespołowi informacji o jakości produktu i związanym z nim ryzyku.

2. Jaka jest różnica między QA a testowaniem oprogramowania?

Testowanie oprogramowania koncentruje się głównie na sprawdzaniu produktu i wykrywaniu błędów.

QA, czyli Quality Assurance, ma szerszy zakres. Obejmuje działania związane z zapewnianiem jakości w całym procesie tworzenia oprogramowania.

Przykładowe działania QA to:

• usprawnianie procesu wytwarzania oprogramowania,
• definiowanie standardów jakości,
• zapobieganie błędom,
• analizowanie ryzyka,
• wdrażanie automatyzacji,
• dbanie o jakość wymagań i dokumentacji.

Można więc powiedzieć, że testowanie jest jednym z elementów zapewniania jakości.

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

Weryfikacja odpowiada na pytanie:

Czy tworzymy produkt poprawnie?

Polega na sprawdzaniu, czy produkt jest tworzony zgodnie z wymaganiami, dokumentacją i przyjętymi standardami.

Walidacja odpowiada na pytanie:

Czy tworzymy właściwy produkt?

Jej celem jest sprawdzenie, czy gotowe rozwiązanie rzeczywiście spełnia potrzeby użytkowników i biznesu.

Przykładem weryfikacji może być przegląd wymagań, a przykładem walidacji – wykonanie testów działającej aplikacji.

4. Czym jest przypadek testowy?

Przypadek testowy opisuje warunki, kroki i dane potrzebne do sprawdzenia konkretnej funkcji systemu.

Typowy przypadek testowy może zawierać:

• identyfikator,
• nazwę,
• warunki wstępne,
• dane testowe,
• kroki testowe,
• oczekiwany rezultat,
• rzeczywisty rezultat,
• status wykonania.

Dobry przypadek testowy powinien być jasny, jednoznaczny i możliwy do wykonania przez inną osobę.

5. Czym różni się przypadek testowy od scenariusza testowego?

Scenariusz testowy jest ogólnym opisem tego, co należy sprawdzić.

Przykład scenariusza:

Sprawdzenie procesu logowania do aplikacji.

Przypadek testowy jest bardziej szczegółowy i zawiera konkretne kroki, dane oraz oczekiwany rezultat.

Przykład przypadku testowego:

Sprawdzenie logowania przy użyciu poprawnego adresu e-mail i poprawnego hasła.

Jeden scenariusz testowy może obejmować wiele różnych przypadków testowych.

6. Czym jest błąd w oprogramowaniu?

Błąd, nazywany również defektem lub bugiem, to sytuacja, w której rzeczywiste działanie aplikacji różni się od oczekiwanego.

Oczekiwane działanie może wynikać z:

• wymagań,
• dokumentacji,
• projektu graficznego,
• kryteriów akceptacji,
• standardów,
• uzgodnień biznesowych,
• rozsądnych oczekiwań użytkownika.

Błąd może dotyczyć funkcjonalności, wyglądu aplikacji, bezpieczeństwa, wydajności, dostępności lub użyteczności.

7. Jak powinno wyglądać dobre zgłoszenie błędu?

Dobre zgłoszenie błędu powinno umożliwić jego łatwe zrozumienie i odtworzenie.

Powinno zawierać:

• krótki i konkretny tytuł,
• opis środowiska,
• warunki wstępne,
• kroki umożliwiające odtworzenie błędu,
• oczekiwany rezultat,
• rzeczywisty rezultat,
• informacje o częstotliwości występowania,
• załączniki, na przykład zrzut ekranu lub nagranie,
• logi lub dane techniczne, jeżeli są potrzebne.

Zgłoszenie powinno opisywać fakty i nie powinno zawierać niepotrzebnych ocen.

8. Czym różni się priorytet błędu od jego ważności?

Ważność błędu, często określana jako severity, informuje o tym, jak duży wpływ defekt ma na działanie systemu.

Priorytet określa, jak szybko błąd powinien zostać naprawiony.

Przykładowo literówka na stronie głównej może mieć niską ważność techniczną, ale wysoki priorytet biznesowy.

Z kolei poważny błąd w rzadko używanej funkcji może mieć wysoką ważność, ale niższy priorytet naprawy.

9. Co zrobisz, jeśli programista stwierdzi, że zgłoszony problem nie jest błędem?

Najpierw ponownie sprawdzę zgłoszenie oraz upewnię się, że problem można odtworzyć.

Następnie zweryfikuję:

• wymagania,
• kryteria akceptacji,
• dokumentację,
• projekt graficzny,
• wcześniejsze ustalenia zespołu.

Jeżeli nadal uważam, że problem jest błędem, przedstawię konkretne argumenty i dowody.

W przypadku niejasnych wymagań warto skonsultować temat z analitykiem, Product Ownerem lub inną osobą odpowiedzialną za decyzje biznesowe.

Najważniejsze jest rozwiązanie problemu, a nie udowodnienie, kto ma rację.

10. Czym są testy regresji?

Testy regresji polegają na sprawdzaniu, czy wprowadzone zmiany nie spowodowały problemów w funkcjach, które wcześniej działały poprawnie.

Wykonuje się je między innymi po:

• dodaniu nowej funkcji,
• naprawieniu błędu,
• zmianie konfiguracji,
• aktualizacji zależności,
• zmianach w kodzie,
• wdrożeniu nowej wersji aplikacji.

Testy regresji często są dobrym kandydatem do automatyzacji, szczególnie gdy są regularnie powtarzane.

11. Czym różni się retest od testów regresji?

Retest polega na ponownym sprawdzeniu konkretnego błędu po jego naprawieniu.

Celem jest potwierdzenie, że zgłoszony problem został rzeczywiście usunięty.

Testy regresji sprawdzają natomiast, czy poprawka lub inna zmiana nie wpłynęła negatywnie na pozostałe funkcje systemu.

W praktyce po naprawieniu błędu można najpierw wykonać retest, a następnie odpowiednio dobrane testy regresji.

12. Czym są testy eksploracyjne?

Testy eksploracyjne polegają na jednoczesnym poznawaniu aplikacji, projektowaniu testów i ich wykonywaniu.

Tester nie działa wyłącznie na podstawie wcześniej przygotowanych przypadków testowych. Korzysta ze swojej wiedzy, doświadczenia, obserwacji i informacji zdobytych podczas testowania.

Testy eksploracyjne są szczególnie przydatne:

• gdy dokumentacja jest ograniczona,
• gdy czas na testy jest krótki,
• przy poznawaniu nowej funkcjonalności,
• podczas szukania nietypowych problemów,
• jako uzupełnienie testów skryptowych.

Nie oznacza to jednak przypadkowego klikania. Dobre testy eksploracyjne mają określony cel i zakres.

13. Czym są testy pozytywne i negatywne?

Testy pozytywne sprawdzają, czy system działa poprawnie dla prawidłowych danych i oczekiwanych działań użytkownika.

Przykład:

Użytkownik podaje prawidłowy adres e-mail i hasło, a następnie zostaje zalogowany.

Testy negatywne sprawdzają zachowanie systemu dla nieprawidłowych danych lub nietypowych sytuacji.

Przykład:

Użytkownik podaje błędne hasło, a system wyświetla odpowiedni komunikat i nie pozwala na zalogowanie.

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

Podział na klasy równoważności polega na pogrupowaniu danych wejściowych, które powinny być przetwarzane przez system w podobny sposób.

Zamiast testować wszystkie możliwe wartości, wybieramy reprezentanta każdej klasy.

Załóżmy, że system pozwala podać wiek od 18 do 65 lat.

Możemy wyodrębnić trzy klasy:

• wartości mniejsze niż 18,
• wartości od 18 do 65,
• wartości większe niż 65.

Następnie wybieramy po jednej lub kilku wartości z każdej klasy.

15. Na czym polega analiza wartości brzegowych?

Analiza wartości brzegowych koncentruje się na danych znajdujących się na granicach dozwolonych zakresów.

Jeżeli poprawny wiek wynosi od 18 do 65 lat, warto sprawdzić między innymi:

• 17,
• 18,
• 19,
• 64,
• 65,
• 
  
  1. 
     

Błędy często występują właśnie na granicach zakresów, na przykład przez niepoprawne zastosowanie operatora „większe niż” zamiast „większe lub równe”.

16. Czym jest smoke testing?

Smoke testing to podstawowy zestaw testów sprawdzających, czy najważniejsze funkcje aplikacji działają i czy wersja nadaje się do dalszego testowania.

Przykładowy smoke test może obejmować:

• uruchomienie aplikacji,
• logowanie,
• otwarcie głównego widoku,
• wykonanie kluczowej operacji,
• zapisanie danych,
• wylogowanie.

Jeżeli podstawowe funkcje nie działają, prowadzenie szczegółowych testów może nie mieć sensu.

17. Czym jest sanity testing?

Sanity testing to stosunkowo wąski zestaw testów wykonywany najczęściej po niewielkiej zmianie lub poprawce.

Jego celem jest szybkie sprawdzenie, czy zmieniona funkcja działa zgodnie z oczekiwaniami i czy dalsze testowanie ma sens.

Smoke testing sprawdza ogólną stabilność wersji, natomiast sanity testing koncentruje się zwykle na konkretnym obszarze.

18. Jak przetestować formularz logowania?

Podczas testowania formularza logowania warto sprawdzić między innymi:

• logowanie poprawnymi danymi,
• logowanie błędnym hasłem,
• logowanie nieistniejącym adresem e-mail,
• pozostawienie pustych pól,
• format adresu e-mail,
• minimalną i maksymalną długość danych,
• obsługę spacji,
• wielkość liter,
• możliwość pokazania i ukrycia hasła,
• działanie przycisku logowania,
• działanie klawisza Enter,
• komunikaty walidacyjne,
• blokadę po wielu nieudanych próbach,
• opcję przypomnienia hasła,
• zapamiętywanie sesji,
• zachowanie po wylogowaniu,
• bezpieczeństwo przesyłanych danych.

Zakres testów powinien zależeć od wymagań i ryzyka związanego z daną aplikacją.

19. Jak przetestować pole tekstowe?

W przypadku pola tekstowego można sprawdzić:

• puste pole,
• jeden znak,
• minimalną długość,
• maksymalną długość,
• przekroczenie maksymalnej długości,
• litery,
• cyfry,
• znaki specjalne,
• polskie znaki,
• emoji,
• spacje na początku i końcu,
• bardzo długi ciąg znaków,
• wklejanie tekstu,
• kopiowanie tekstu,
• niedozwolone formaty,
• komunikaty walidacyjne.

Należy również zweryfikować, czy dane są poprawnie zapisywane i wyświetlane po ponownym otwarciu formularza.

20. Jak przetestować aplikację bez dokumentacji?

Najpierw zapoznam się z aplikacją i spróbuję zrozumieć jej główne cele oraz kluczowe procesy biznesowe.

Następnie mogę:

• porozmawiać z członkami zespołu,
• przeanalizować istniejące zgłoszenia,
• sprawdzić podobne funkcje,
• wykonać testy eksploracyjne,
• zidentyfikować najbardziej ryzykowne obszary,
• przygotować podstawową dokumentację podczas testowania,
• zapisywać pytania i niejasności.

Brak dokumentacji nie oznacza, że testowanie jest niemożliwe. Zwiększa jednak ryzyko nieporozumień i wymaga większej komunikacji z zespołem.

21. Co zrobisz, jeśli masz bardzo mało czasu na testy?

W takiej sytuacji zastosuję podejście oparte na ryzyku.

W pierwszej kolejności sprawdzę:

• najważniejsze procesy biznesowe,
• funkcje najczęściej używane przez użytkowników,
• obszary objęte zmianą,
• integracje z innymi systemami,
• funkcje, których awaria może spowodować straty finansowe,
• obszary, w których wcześniej występowało dużo błędów.

Poinformuję również zespół, jaki zakres został przetestowany, czego nie udało się sprawdzić i jakie ryzyko pozostaje.

22. Czym jest testowanie oparte na ryzyku?

Testowanie oparte na ryzyku polega na dobieraniu priorytetów testów na podstawie prawdopodobieństwa wystąpienia problemu oraz jego potencjalnych konsekwencji.

Najwięcej uwagi poświęca się funkcjom, których awaria może:

• zablokować użytkowników,
• spowodować utratę danych,
• narazić firmę na straty finansowe,
• doprowadzić do problemów prawnych,
• wpłynąć na bezpieczeństwo,
• uszkodzić wizerunek produktu.

Takie podejście pomaga efektywnie wykorzystać ograniczony czas przeznaczony na testowanie.

23. Czym jest API?

API, czyli Application Programming Interface, umożliwia komunikację pomiędzy różnymi systemami lub komponentami aplikacji.

Przykładowo aplikacja internetowa może wysłać żądanie do API, aby:

• pobrać dane użytkownika,
• utworzyć zamówienie,
• zalogować użytkownika,
• zaktualizować profil,
• usunąć rekord.

Podczas testowania API sprawdzamy między innymi metody HTTP, dane wejściowe, kody odpowiedzi, strukturę odpowiedzi, nagłówki, autoryzację i czas odpowiedzi.

24. Jakie znasz metody HTTP?

Najpopularniejsze metody HTTP to:

• GET – pobieranie danych,
• POST – tworzenie nowych danych,
• PUT – pełna aktualizacja zasobu,
• PATCH – częściowa aktualizacja zasobu,
• DELETE – usuwanie zasobu.

Podczas rozmowy warto pamiętać, że rzeczywiste zastosowanie metod może zależeć od sposobu zaprojektowania konkretnego API.

25. Jakie znasz popularne kody odpowiedzi HTTP?

Przykładowe kody odpowiedzi to:

• 200 OK – żądanie zakończyło się sukcesem,
• 201 Created – zasób został utworzony,
• 204 No Content – operacja zakończyła się sukcesem, ale odpowiedź nie zawiera treści,
• 400 Bad Request – żądanie jest niepoprawne,
• 401 Unauthorized – brakuje prawidłowego uwierzytelnienia,
• 403 Forbidden – użytkownik nie ma odpowiednich uprawnień,
• 404 Not Found – zasób nie został znaleziony,
• 409 Conflict – wystąpił konflikt, na przykład próba utworzenia istniejącego zasobu,
• 500 Internal Server Error – wystąpił błąd po stronie serwera,
• 503 Service Unavailable – usługa jest chwilowo niedostępna.

Podczas testów nie należy sprawdzać wyłącznie kodu. Ważna jest również treść i struktura odpowiedzi.

26. Co można sprawdzić podczas testowania API?

Podczas testowania API warto zweryfikować:

• poprawność kodu odpowiedzi,
• strukturę odpowiedzi,
• wartości zwracanych pól,
• wymagane i opcjonalne parametry,
• obsługę błędnych danych,
• autoryzację i uprawnienia,
• nagłówki,
• czas odpowiedzi,
• działanie różnych metod HTTP,
• zapis danych w bazie,
• komunikaty błędów,
• zachowanie przy braku danych,
• odporność na wielokrotne wykonanie tej samej operacji.

Do testowania API można wykorzystać na przykład Postmana, narzędzia deweloperskie przeglądarki lub testy automatyczne.

27. Do czego testerowi potrzebny jest SQL?

SQL pozwala testerowi sprawdzać dane zapisane w bazie.

Tester może wykorzystywać SQL do:

• wyszukiwania danych testowych,
• sprawdzania, czy dane zostały poprawnie zapisane,
• porównywania danych z interfejsu z zawartością bazy,
• przygotowywania danych do testów,
• analizowania przyczyn błędów,
• sprawdzania relacji pomiędzy tabelami.

Podstawowa znajomość instrukcji SELECT, WHERE, JOIN, ORDER BY i funkcji agregujących jest często przydatna na stanowisku QA.

28. Które testy warto automatyzować?

Warto automatyzować przede wszystkim testy:

• często powtarzane,
• stabilne,
• czasochłonne do wykonania ręcznego,
• wykonywane dla wielu zestawów danych,
• należące do regresji,
• sprawdzające kluczowe procesy,
• uruchamiane na wielu środowiskach lub konfiguracjach.

Nie każdy test powinien zostać zautomatyzowany.

Automatyzacja może nie być opłacalna w przypadku jednorazowych testów, szybko zmieniającej się funkcjonalności, testów użyteczności lub obszarów wymagających subiektywnej oceny człowieka.

29. Czym jest CI/CD i jakie ma znaczenie dla QA?

CI/CD to zbiór praktyk związanych z automatycznym integrowaniem, testowaniem i dostarczaniem zmian w oprogramowaniu.

CI, czyli Continuous Integration, polega na częstym łączeniu zmian w kodzie i automatycznym sprawdzaniu ich poprawności.

CD może oznaczać Continuous Delivery lub Continuous Deployment i dotyczy automatyzacji procesu dostarczania aplikacji.

W procesie CI/CD można automatycznie uruchamiać:

• testy jednostkowe,
• testy API,
• testy interfejsu,
• testy regresji,
• analizę jakości kodu,
• testy bezpieczeństwa,
• generowanie raportów.

Dzięki temu zespół szybciej otrzymuje informację o problemach.

30. Dlaczego chcesz pracować jako QA?

Odpowiedź powinna być zgodna z Twoimi rzeczywistymi motywacjami.

Możesz wspomnieć między innymi o tym, że:

• lubisz analizować problemy,
• zwracasz uwagę na szczegóły,
• interesuje Cię sposób działania aplikacji,
• chcesz wpływać na jakość produktu,
• lubisz łączyć wiedzę techniczną z perspektywą użytkownika,
• dobrze czujesz się we współpracy z zespołem,
• chcesz rozwijać się w kierunku automatyzacji, API, bezpieczeństwa lub wydajności.

Przykładowa odpowiedź:

„Chcę pracować jako QA, ponieważ lubię analizować sposób działania aplikacji i szukać sytuacji, które mogą sprawić problem użytkownikowi. Odpowiada mi również praca wymagająca dokładności, logicznego myślenia i współpracy z różnymi osobami w zespole. W przyszłości chciałbym rozwijać się również w obszarze testowania API i automatyzacji testów”.

Jak przygotować się do rozmowy kwalifikacyjnej QA?

Samo zapamiętanie definicji może nie wystarczyć. Podczas rozmowy rekrutacyjnej często pojawiają się pytania wymagające podania konkretnego przykładu.

Przed rozmową warto:

• powtórzyć podstawowe pojęcia związane z testowaniem,
• przećwiczyć projektowanie przypadków testowych,
• przygotować przykładowe zgłoszenie błędu,
• poznać podstawy HTTP, API i SQL,
• zapoznać się z narzędziami używanymi w projekcie,
• przygotować przykłady problemów rozwiązanych podczas nauki lub pracy,
• przeanalizować wymagania zamieszczone w ogłoszeniu,
• przygotować pytania do rekrutera.

Nie ucz się odpowiedzi słowo w słowo. Rekruter może łatwo zauważyć, że kandydat powtarza wyuczoną definicję, ale nie rozumie omawianego zagadnienia.

Staraj się odpowiadać własnymi słowami i podawać przykłady.

Podsumowanie

Rozmowa kwalifikacyjna na stanowisko QA może obejmować podstawy testowania, praktyczne zadania, pytania sytuacyjne oraz zagadnienia techniczne.

Zakres pytań zależy od poziomu stanowiska. Od juniora oczekuje się przede wszystkim znajomości podstaw i logicznego myślenia. W przypadku bardziej doświadczonych kandydatów mogą pojawić się pytania o strategię testów, automatyzację, architekturę systemu, CI/CD, analizę ryzyka i usprawnianie procesu jakości.

Najważniejsze jest nie tylko udzielenie poprawnej odpowiedzi, ale również pokazanie sposobu myślenia, umiejętności analizowania problemów i otwartości na współpracę.