Pytania rekrutacyjne dla junior testera

Jak zostać testerem

 758 

Pytania rekrutacyjne dla junior testera – manualnego. Obserwując uważnie różne grupy facebookowe dla testerów, profile na Linkedinie czy inne strony poświęcone testom, stale widzę pytania na temat pierwszej pracy.

Zazwyczaj padają pytania:

a) o co mogą pytać na rozmowie rekrutacyjnej;
b) czy ISTQB wystarczy;
c) jak wyróżnić się wśród pozostałego grona kandydatów;
d) nie mam doświadczenia, gdzie mam je zdobyć;

W niniejszym wpisie będą przykładowe pytania dla testerów (głównie manualnych), jednakże będą one poszerzone o dodatkowe wątki które mogą czasami pomóc w podjęciu decyzji w przypadku posiadania dwóch kandydatów będących na podobnym poziomie doświadczenia. Inne aspekty jak wyróżnienie na tle pozostałych osób, zdobywaniu doświadczenia będzie w innych wpisach w dziale jak zostać testerem. 

UWAGA Pytania zawarte w niniejszym wpisie stanowią zbiór pytań i odpowiedzi dostępnych w różnych serwisach (w tym zagranicznych), są też pytaniami które tworzyłem w ramach rekrutacji. Zapewne w trakcie pracy twórczej, stworzę jeszcze inne które będą znajdować się w niniejszym poście.

Kontynuując, czy wiedza z ISTQB wystarczy? Moim zdaniem nie, pisząc więcej – jest to wiedza która powinien posiadać tester, jednak w związku z dużą ilością osób zainteresowanych tą tematyką będziesz musiał/a wykazać się czymś więcej. Często widać, że jest przesyt rynku osobami na poziomie juniorskim czy chcących uzyskać pierwszą pracę. 
Ruszajmy do pytań, w innych postach będą poruszane inne tematy związane z rekrutacją.


Jakie są poziomy testów

a) testy modułowe (jednostkowe);
b) testy integracyjne;
c )testy systemowe;
d) testy akceptacyjne.

Jakie są cele testowania?

Do celów testowania zalicza się:
– zapobieganie defektom
– nabieranie zaufania do poziomu jakości
– znajdowanie usterek
– dostarczanie interesariuszom informacji potrzebnych do podejmowania decyzji

Proszę omówić testy systemowe

Testy systemowe są pierwszymi testami w pełni zintegrowanego systemu. Głównym celem tych testów jest uzyskanie wiedzy, czy zbudowany system spełnia określone wymagania. Wiedza potrzebna testerowi przy przeprowadzeniu testów systemowych to, w jaki sposób powinien zachowywać się system. Testy systemowe powinny być przeprowadzane na środowiskach najbardziej zbliżonych produkcyjnym. W ramach tego poziomu testów możemy badać aspekty funkcjonalnych, jak i niefunkcjonalnych atrybutów systemu. Przykładowo w ramach testów funkcjonalnych przeprowadzamy testy w oparciu o wymagania, a w testach niefunkcjonalnych badamy użyteczność czy wydajność zbudowanej aplikacji. Testy systemowe najlepiej, gdy są przeprowadzane przez osoby doświadczone, mające wiedzę, jak powinien działać testowany system.

Czym charakteryzują się testy dymne?

Smoke Testy to zestaw przypadków testowych, których wykonanie pozwala na weryfikację, czy podstawowa funkcjonalność modułu / systemu działa prawidłowo. Testy te nie mają za cel dogłębne zweryfikowanie funkcjonalności, a jedynie ogólny przegląd systemu / modułu. Dobrą praktyką jest posiadanie zautomatyzowanych przypadków testowych obejmujących zakres testów dymnych.

Omów testy modułowe (jednostkowe)

Testy modułowe, nazywane także testami jednostkowymi lub testami komponentów, są pierwszymi testami wykonywanymi w trakcie procesu testowania. Są to testy na najniższym poziomie, w trakcie których testujemy pojedyncze fragmenty kodu (klasy, metody itp.) w oderwaniu od reszty aplikacji. Testy jednostkowe pozwalają na weryfikację właściwości niefunkcjonalnych, takich jak wydajność. Zazwyczaj testy modułowe przeprowadzane są przez programistę, ponieważ najlepiej zna kod systemu i ma ku temu odpowiednie kompetencje. Jedną z technik przeprowadzania testów jednostkowych jest metodologia pochodzącą z XP jak TDD (Test Driven Development), w której to najpierw piszemy testy, a w kolejnym etapie dopiero kod samej aplikacji.

Co to są retesty?

Re-Test jest to powtórne wykonanie testu, którego wcześniejsze wykonanie zakończyło się negatywnym rezultatem i konieczna była ingerencja programisty, aby wprowadzić poprawki do systemu.

Opisz testy regresji

Testy regresyjne, czasem nazywane zwyczajowo regresją, mają na celu ponowne przetestowanie funkcjonalności systemu po wprowadzeniu w nim zmian lub dodaniu nowej funkcjonalności. Skupiamy się tutaj na badaniu, czy nowe funkcjonalności lub modyfikacja istniejących nie spowodowały defektów w funkcjonalności, która dotychczas działała poprawnie. Testy regresji warto poddawać automatyzacji testów, gdyż powinniśmy praktycznie po każdych większych zmianach zweryfikować poprawność działania dotychczasowej funkcjonalności systemu. Testy te również powodują największe znużenie u testera z uwagi na wielokrotność ich powtarzania.

Testy regresji a retesty – różnice.

Regresja ma za cel ponowne zweryfikowanie niezmienionej się części systemu po wprowadzeniu zmian w innych obszarach lub po dodaniu nowych funkcjonalności.
Retesty natomiast są upewnieniem się, że przeprowadzony test, który nie działał prawidłowo i skutkował raportem zgłoszenia błędu, działa już prawidłowo.

Co to jest weryfikacja a co to jest walidacja oprogramowania?

Weryfikacja to proces, w którym sprawdzamy, czy system lub moduł został zbudowany zgodnie z założeniami projektu, czy aplikacja jest zgodna z jej specyfikacją.
Walidacja natomiast pozwala odpowiedzieć na pytanie, czy oprogramowanie jest zbudowane prawidłowo pod względem potrzeb i wymagań użytkownika.

Jakie elementy powinny znaleźć się w poprawnym zgłoszeniu incydentu?

Zgłaszanie incydentów to jeden z podstawowych obowiązków testera oprogramowania. Poprawne ich zgłaszanie pozwala na znacznie szybsze identyfikacje ewentualnych defektów i ich poprawę. Prawidłowy raport o incydencje powinien składać się z następujących elementów:

Tytuł / Podsumowanie zgłoszenia – Tytuł powinien jasno i zwięźle określać, gdzie występuje błąd i na czym polega Priorytet – Priorytet nadawany przez testera powinien wynikać z oceny, na ile dany błąd utrudnia czy uniemożliwia pracę w aplikacji. Zazwyczaj korzystamy tutaj z góry zdefiniowanych priorytetów, takich jak „Blocker”, „Critical”, „Normal”, „Major”, „Minor”. Często można użyć również pola „Severity”, które określa, jak szybko dany błąd ma zostać rozwiązany, jego wpływ na aplikację, jednakże pozostaje on niezależny od priorytetu Komponent – Komponent / Moduł, w którym został wykryty błąd. Komponent często przydaje się celem agregacji wykrytych incydentów
Wersja oprogramowania w której znaleziono defekt Treść zgłoszenia – Wszystkie szczegółowe informacje, które pozwolą na powtórzenie wykrytego błędu. Im bardziej szczegółowo opiszemy defekt, tym większe prawdopodobieństwo, że programista szybko zdiagnozuje problem. W treści zgłoszenia dobrze jest napisać wymagane kroki do powtórzenia problemu
Środowisko testowe – Na jakim środowisku został wykryty defekt
Urządzenie / Przeglądarka – Urządzenie lub przeglądarka, na których wykryto defekt
Rezultat testów – czyli efekt samego testu, czyli co się dzieje w systemie
Oczekiwany rezultat testów (opcjonalnie) – W zależności od wiedzy testera i kultury organizacji warto podać, jaki jest oczekiwany rezultat testów. Należy tutaj jednak uważać, aby tester nie stał się w pewnym momencie analitykiem i nie definiował wymagań do systemu
Zrzuty ekranów, filmy – Zgodnie z cytatem obraz mówi więcej niż tysiąc słów, pozwala na szybką identyfikację problemu pod warunkiem poprawnego „opisania” zrzutu ekranu.

Jakie defekty jesteśmy w stanie wykryć za pomocą testów integracyjnych?

Testy integracyjne wykonujemy w celu wykrycia błędów w interfejsach i interakcjach pomiędzy zintegrowanymi elementami.
Testy integracyjne mogą zweryfikować wymianę informacji pomiędzy poszczególnymi modułami w ramach jednego systemu, jak również mogą polegać na weryfikacji integracji pomiędzy niezależnymi systemami – zazwyczaj przeprowadza się testy integracyjne po testach systemowych poszczególnych systemów. W trakcie testów integracyjnych szczególną uwagę trzeba zwrócić na to, w jaki sposób odbywa się komunikacja pomiędzy poszczególnymi modułami czy systemami i weryfikować, czy wymiana tych danych następuje prawidłowo. Przykładowo może występować integracja z zewnętrzną bazą klientów i warto zweryfikować, czy wszystkie atrybuty takich klientów przenoszą się poprawnie w produkcie. Warto zwracać uwagę na to, jak system powinien zachować się w momencie aktualizowania danych w systemie, z którym się integrujemy, tzn. czy dana aktualizacja odbywa się w czasie rzeczywistym czy są jakieś problemy.
Testy integracyjne tzw. wewnętrzne, czyli integracja modułów wykonywana jest zazwyczaj przez deweloperów, pozwalają one wykryć typowe błędy, jak np. brak przekazywania danych pomiędzy modułami, stosowanie różnych formatów komunikacji, co skutkuje ich nieprawidłowym odczytem.

W trakcie testów integracyjnych z systemami najlepiej korzystać z zasady, że w jednym momencie powinniśmy integrować dwa systemy / moduły w jednym czasie. W przypadku integracji więcej niż dwóch elementów na raz, może to spowodować, że nie będziemy w stanie zlokalizować miejsca usterki.

Jakie są podstawowe cele testów akceptacyjnych?

Testu akceptacyjne są ostatnimi przeprowadzanymi testami w ramach modelu V. Celem tych testów jest upewnienie się przez zlecającego utworzenie systemu, czy produkt można zaakceptować. Często testy akceptacyjne nazywane są również odbiorami.
Jedną z charakterystyk testów akceptacyjnych jest to, że testy powinny być przeprowadzane najlepiej na środowisku produkcyjnym lub bardzo zbliżonym do produkcyjnego. W testach akceptacyjnych udział biorą zarówno przedstawiciele odbiorcy, jak i wykonawcy. Testy takie przeprowadza się w oparciu o dokumentację opisującą, jakie obszary będą poddawane testom i w jaki sposób mają być one realizowane. Po pozytywnym przeprowadzeniu testów, akceptacja powinna zostać podpisana przez obie strony. Akceptacja może dotyczyć wielu aspektów systemu, od akceptacji użytkownika funkcjonalności systemu po zgodność oprogramowania z kontraktem czy aspekty prawne.

Jak wygląda proces testowy w środowisku Scrumowym?

Metodyki zwinne znacznie różnią się od kaskadowego modelu wytwarzania produktów również w aspekcie testowania. Przykładowo w środowisku Scrumowym role, które występują to Scrum Master, Product Owner oraz Development Team. Jak widać w ramach tego środowiska nie ma niezależnej roli Testera Oprogramowania. W środowisku Scrum to Development Team jest odpowiedzialny zarówno za tworzenie produktu, jak i za jego testowanie. Oczywiście w ramach tego Zespołu mogą znajdować się osoby zajmujące się testami oprogramowania, ale to ciągle Zespół odpowiedzialny jest za końcowy sukces lub porażkę projektu. Praca w Scrumie odbywa się w ograniczonych iteracjach, maksymalnie do miesiąca czasu, i po tym czasie powinna powstać funkcjonalność potencjalnie gotowa do wdrożenia (a więc po testach i poprawkach błędów). Podstawowymi elementami wdrożonymi w środowisko Scrumowe, dbającymi o aspekt testowania, to DoD (ang. Definition of Done) oraz AC ( ang. Acceptance Criteria).
DoD definiuje, kiedy jesteśmy w stanie uznać, że nasza praca jest zakończona i gotowa do potencjalnego wdrożenia. Definicję taką opracowuje Product Owner przy konsultacji z Development Team. Definicja taka obowiązuje w ramach całego Sprintu i dopiero później może zostać przedefiniowana.
Kryteria akceptacji pozwalają na określenie, w jaki sposób należy zweryfikować konkretne wymaganie, które może zostać spisane w postaci User Stories.

Co to są testy czarnoskrzynkowe?

Za pomocą testów czarnoskrzynkowych jesteśmy w stanie przeprowadzić testy atrybutów funkcjonalnych oraz niefunkcjonalnych badanego systemu. Testy te charakteryzują się tym, że nie mamy dostępu do wewnętrznej struktury modułu lub systemy i głównie testujemy tutaj zewnętrzne aspekty oprogramowania. Główną zaletą testów czarnoskrzynkowych jest to, że testy te wykonywane są z punktu widzenia użytkownika końcowego i jesteśmy w stanie znaleźć rozbieżności w specyfikacji.

Proszę przedstawić proces testowy, w którym uczestniczy się w obecnej pracy.

Jeżeli to nie jest Twoja pierwsza praca masz łatwiej, ewentualnie jak brałeś/aś udział w projektach typu Cherry-IT czy uTest i musi wykazać się własną inwencją 🙂 Odpowiadając na to pytanie, najlepiej jest zacząć od tego, w jakich uczestniczy się projektach i w jakich technologiach są one realizowane. Następnie należy opowiedzieć o swoich obowiązkach i przedstawić sam proces testowy od etapu analizy (o ile tak jest w firmie) po testy akceptacyjne. Wykaż się inwencją, opisuj poszczególne elementy.

Wady, problemy testowania w modelu kaskadowym

Główną wadą, która występuje w modelu kaskadowym jest to, że testy są oderwane od innych faz wytwarzania oprogramowania. Po pierwsze powoduje to, że w momencie przedłużenia fazy developmentu produktu, czas, który musi zostać wygospodarowany na tą czynność, zabierany jest z fazy testowania oprogramowania. W rezultacie w późniejszym etapie testy stają się niekompletne. Po drugie proces testowania jest całkowicie oderwany od innych czynności deweloperskich (planowania, analizy, projektowania itd.), co skutkuje tym, że często tester jest pierwszą osobą, która widzi projekt w całości i może się okazać, że system jest zbudowany w taki sposób, że nie spełnia oczekiwań klienta. Dodatkowo koszt poprawy błędów w tak późnej fazie jest zdecydowanie wyższy niż na etapie planowania czy analizy.

Proszę omówić cykl życia zgłoszonego defektu/błędu?

Cykl życia defektu w dużej części zależy od organizacji. Wiele firm stosuje swoje zmodyfikowane wersje cyklu życia produktu. Przepływ zgłoszenia zazwyczaj jest również zależny od wykorzystywanego narzędzia oraz sposobu zarządzania projektami (często inne przepływy zgłoszenia są w środowisku Scrumowym, a inne w modelu kaskadowym).
Jak dwa pytania wyżej jeżeli masz doświadczenie w branży opisz swoimi słowami jak to wyglądało u Ciebie.

Jakie są znane Panu / Pani sposoby szacowania testów?

Szacowanie czasochłonności testów jest dość złożoną czynnością i zazwyczaj przeprowadzaną przez doświadczonych testerów czy kierowników testów. Popularnie mówi się o estymacji czasu pracy.
Jedną z technik szacowania testów jest metoda ekspercka (tzw. metoda delficka), która polega na tym, że szacowanie przeprowadzane jest przez doświadczony zespół lub osoby, które miały już styczność z danym problemem lub mają podobną wiedzę, która może okazać się przydatna. Warto tutaj zwrócić uwagę, że jest to metoda dość tania i szybka, natomiast musimy polegać na dobrych ekspertach. W przypadku, gdy szacunki wykonywane są przez osoby bez doświadczenia, może okazać się ona bardzo nieskuteczna.
W projektach Scrumowych szacowanie czasochłonności testów odbywa się na przykład za pomocą techniki Poker Planning, gdzie każde zadanie, które musi zostać wykonane, jest szacowane przez wszystkich członków zespołu (cały zespół odpowiedzialny jest za testy).
Kolejną metodą, którą można wykorzystać do szacowania testów jest tzw. metoda punktów funkcyjnych, W ostateczności do szacowania testów można wykorzystać również średni czas potrzebny na testy, czyli 30-40% czasu developmentu.

Co to jest testowanie oprogramowania?

Testowanie oprogramowania to jeden z procesów związanych z wytwarzaniem oprogramowania. Testowanie zazwyczaj ma na celu weryfikację oraz walidacje tworzonego oprogramowania. Główną czynnością wchodzącą w ten proces jest wykonywanie testów, natomiast czynności testowe następują zarówno przed, jak i po wykonaniu testów. Jeżeli chcesz rozszerzyć odpowiedź to wykorzystaj odpowiedzi z poprzednich pytań.

Jakie są cele testowania?

Do celów testowania zalicza się:
– zapobieganie defektom
– nabieranie zaufania do poziomu jakości
– znajdowanie usterek
– dostarczanie interesariuszom informacji potrzebnych do ,podejmowania decyzji.

Czy jest możliwe kompletne przetestowanie systemu?

Jedną z podstawowych zasad testowania oprogramowania jest to, że testowanie kompletne (gruntowne) nie jest możliwe do wykonania. Nie jesteśmy w stanie przetestować każdej możliwej kombinacji wejść dla każdej zmiennej. Dodatkowo, jeśli oprogramowanie ma działać na wielu urządzeniach w różnych konfiguracjach, również nie jesteśmy w stanie zweryfikować każdej możliwej kombinacji.

Kompetencje i umiejętności przydatne na stanowisku testera oprogramowania
  • Wie, jak działa system , który ma być testowany,
  • Zna techniki testowania,
  • Korzysta z narzędzi, które wykorzystywane są w procesie testowym,
  • Szybko się uczy i jest chętny do poznawania nowych rzeczy,
  • Potrafi dobrze komunikować się w sposób werbalny i pisemny,
  • Jest osobą asertywną,
  • Nadto jest dokładny i dociekliwy,
  • Charakteryzuje go ciekawość,
  • Przywiązuje uwagę do szczegółów,
  • Ma krytyczne spojrzenie na przedmiot testów,
Z czego powinien składać się plan testów?

Plan testów jest podstawowym dokumentem w procesie testowym. Powinien zawierać:

wykaz elementów systemu, które będą podlegały testom, elementy, które zostaną pominięte w testach,
opis, w jaki sposób będzie testowane oprogramowanie (techniki)
narzędzia, jakie będą wykorzystywane w testach,
kryteria zaliczenia i niezaliczenia testów,
kryteria zawieszenia testów,
ogólne zadania, jakie są do wykonania w obrębie procesu testowego,
informacje o wymaganych kompetencjach (np. automatyzacja testów),
wymagania potrzebne do stworzenia środowiska testowego
wykaz osób uczestniczących w procesie ze wskazaniem odpowiedzialności,
potrzeby szkoleniowe, jeśli są potrzebne (np. potrzeba doszkolenia ludzi z zakresu automatyzacji testów),
harmonogram przeprowadzenia testów,
ryzyka oraz plany awaryjne,
To tylko kilka elementów które postaram się opisać w jednym z kolejnych wpisów, gdyż temat jest rozległy i należy się do niego solidnie przygotować.

Jakie są główne zadania testera ?

Do głównych zadań testera należy:
współtworzenie planów testów,
przygotowanie / dbanie o środowiska testowe,
ocena wyników testów,
przygotowanie danych testowych,
wykonywanie testów,
rejestrowanie wykrytych defektów,
ocena wymagań, specyfikacji pod kątem ich testowalności,
automatyzacja testów,

Co to jest testowanie dynamiczne?

Testy dynamiczne charakteryzują się tym, że odbywają się na uruchomionym systemie i polegają na zasileniu systemu danymi oraz weryfikowaniu oczekiwanych rezultatów. Testy modułowe, integracyjne, systemowe oraz akceptacyjne są testami dynamicznymi.

Co to są testy niefunkcjonalne i jakie atrybuty jesteśmy w stanie za ich pomocą zweryfikować?

Testy niefunkcjonalne można przeprowadzać na każdym poziomie testów. Mają one za cel weryfikowanie atrybutów niefunkcjonalnych systemu takich, jak:

  • wydajność,
  • efektywność,
  • użyteczność,
  • zdolność wprowadzania zmian w przyszłości,
  • niezawodność,
Proszę przedstawić model V wykorzystywany w testach oprogramowania.

Model V składa się zarówno z faz produkcji oprogramowania, jak i jego testowania.
Fazy produkcji oprogramowania to:
– specyfikacja wymagań,
– specyfikacja systemu,
– specyfikacja funkcjonalna,
– implementacja,

Odpowiadające im fazy testowania oprogramowania są następujące:
– testy akceptacyjne,
– testy systemowe,
– testy integracyjne,
– testy modułowe,

Przetestować mechanizm rejestracji w jakimś systemie, np. Facebook/Twitter lub np. dowolny system pocztowy.

Zadanie polega na tym, że kandydat ma wykonać testy eksploracyjne mechanizmu logowania, rejestracji w jakimś wskazanym systemie. Efektem ma być lista wykrytych defektów oraz dodatkowo jeden lub dwa defekty opracowane zgodnie ze standardem raportowania błędów. Dodatkowo uczestnik rekrutacji ma opracować przypadek testowy. Czas na zadanie około 1 godzina.
Korzystaj z wcześniejszych pytań by ująć wszystkie elementy które powinny być w przypadku testowym, scenariuszu a także w zgłoszeniu błędu. Jeżeli rekruter sobie zażyczy może opisać jak zgłosić defekt i opisać np. cykl życia błędu.

Z czego składa się przypadek testowy ?

Przypadek testowy składa się z zestawu wartości wejściowych, warunków początkowych, oczekiwanych wyników oraz warunków końcowych. Jest tworzony w określonym celu lub dla warunku testowego, jakim jest wykonanie danej ścieżki w programie lub zweryfikowanie zgodności z wymaganiem.

Poniżej przykład przypadku testowego
Nazwa Przypadku – PT1 – Poprawne zalogowanie się,
Środowisko testowe – System Windows 10, przeglądarka Chrome v. 78
Warunek Wstępny – Posiadanie konta użytkownika w systemie oraz aplikacja dostępna pod adresem:
www.logowanie.pl/zaloguj,
Kroki do wykonania – Wpisz ‘mtest’ w polu „Login”. Wpisz ‘hapsswd’ w polu „Hasło”. Naciśnij klawisz „Zaloguj”. Oczekiwany rezultat: Po kliknięciu „Zaloguj” użytkownik powinien zalogować się na stronę główną aplikacji

Mając na względzie, że obecnie na rynku jest przesyt osób z niskim bądź zerowym doświadczeniem, warto by potencjalny kandydat posiadał jeszcze inne umiejętności. 

Doświadczenie

Jeżeli nie udało Ci się zdobyć pierwszej pracy  – staraj się szukać, pytać i rozmawiać. W internecie również można brać udział w projektach które pomogą Ci nabyć doświadczenie:
– Cherry IT;
– uTest.

Jak wspomniano na wstępie, będą kolejne wpisy w tematyce dla początkujących testerów. Poszerzymy też tematykę o pytania z testów automatycznych czy bardziej praktycznych.  Dodatkowo w innych sekcjach znajduje się bardzo dużo wiedzy, z różnych gałęzi testerskich.