Poradnik początkującego testera – #3 30 pytań rekrutacyjnych

Wiele osób, które przygotowuje się do swojej pierwszej pracy na stanowisku Testera oprogramowania zastanawia się, jakie pytania może im zadań potencjalny pracodawca i z jakiego obszaru. W ramach naszego poradnika – Poradnik początkującego testera  postanowiliśmy zebrać najpopularniejsze pytania, które pojawiały się w trakcie Naszych rekrutacji – czy to z perspektywy pracodawcy, czy uczestnika rekrutacji. Mamy nadzieję, że pomoże to przygotować się Wam na rekrutację i dostać swoją wymarzoną pracę na stanowisku Testera oprogramowania.

UWAGA

Pytania, które otrzymujesz na rozmowie głównie zależą od stanowiska, na jakie będziesz rekrutować. Inny zakres pytań będziesz otrzymywał rekrutując się na stanowisko „Tester oprogramowania”, a inny na „Programistę testów automatycznych”. W poniższym artykule znajdziesz ogólne pytania na stanowisko „Manualnego testera oprogramowania”.

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 – 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 – Rezultat, 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

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.

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.

Testy regresyjne mają 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.

  • Testy modułowe (jednostkowe)
  • Testy integracyjne
  • Testy systemowe
  • Testy akceptacyjne

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.

Testy integracyjne wykonujemy w celu wykrycia błędów w interfejsach i interakcjach między zintegrowanymi elementami. Testy te mogą weryfikować wymianę informacji pomiędzy modułami w ramach jednego systemu, ale również mogą polegać na weryfikacji integracji pomiędzy niezależnymi systemami – tutaj zazwyczaj przeprowadza się testy integracyjne po testach systemowych poszczególnych systemów. W trakcie testów integracyjnych szczególną uwagę musimy zwrócić na to, w jaki sposób odbywa się komunikacja pomiędzy modułami / systemami i weryfikować, czy wymiana 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. Warto zwracać uwagę na to, jak system powinien zachować się w momencie aktualizacji danych w systemie, z którym się integrujemy, tzn. czy aktualizacja odbywa się w czasie rzeczywistym czy też nie. Testy integracyjne tzw. wewnętrzne, czyli integracja modułów wykonywana jest zazwyczaj przez programistów, pozwalają 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 integrujemy dwa systemy / moduły na raz. W przypadku integracji więcej niż dwóch modułów / systemów na raz, może to spowodować, że nie będziemy w stanie zidentyfikować miejsca usterki.

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.

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.

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.

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.

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.

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.

Tutaj kandydat 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.

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.

To jedno z pytań otwartych, których odpowiedź zależy od tego, jakie narzędzia są znane kandydatowi i jakie wykorzystywane są w organizacji, w której pracuje / pracował. Podpowiedzią z Naszej strony może być, aby odpowiadając na to pytanie zastanowić się nad całym cyklem życia oprogramowania i narzędziami, z których się korzysta / korzystało. Przykładowo narzędzia do planowania i zarządzania testami, narzędzia do zgłaszania defektów, narzędzia do automatyzacji testów itp.

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).

Poniżej przedstawiamy pełny przepływ zgłoszonego błędu wykorzystywanego w narzędziu Bugzilla

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. 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, która szerzej opisana jest pod adresem https://pl.wikipedia.org/wiki/Punkt_funkcyjny. W ostateczności do szacowania testów można wykorzystać również średni czas potrzebny na testy, czyli 30-40% czasu developmentu.

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.

Jednym ze sposobów, w jaki jesteśmy w stanie wykonywać testy, są testy automatyczne. Nie da się jednak w 100% zastąpić testy manualne testami automatycznymi ze względu na olbrzymi koszt wdrożenia oraz utrzymania takich testów. Testy automatyczne są uzupełnieniem testów manualnych. Testy te są szczególnie mało efektywne w trakcie rozwoju oprogramowania, w którym zachodzą ciągłe zmiany. Programista testów automatycznych nie jest wówczas w stanie nadążyć za wprowadzanymi zmianami, przez co też testy stają się nieużyteczne. Testy automatyczne swoją największą wartość dają jednak w trakcie przeprowadzania testów regresyjnych, w których wymagana jest duża pracochłonność ze strony testów manualnych.

Do celów testowania zalicza się:

  • zapobieganie defektom
  • nabieranie zaufania do poziomu jakości
  • znajdowanie usterek
  • dostarczanie interesariuszom informacji potrzebnych do podejmowania decyzji

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.

  • Wie, jak działa system , który ma być testowany
  • Zna techniki testowania
  • Zna narzędzia, 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ą
  • Jest dokładny i dociekliwy
  • Charakteryzuje go ciekawość
  • Przywiązuje uwagę do szczegółów
  • Ma krytyczne spojrzenie na przedmiot 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

Do głównych zadań testera należy:

  • współtworzenie planów testów
  • przygotowanie / dbanie o środowiska testowe
  • przygotowanie danych testowych
  • wykonywanie testów
  • rejestrowanie wykrytych defektów
  • ocena wyników testów
  • ocena wymagań, specyfikacji pod kątem ich testowalności
  • automatyzacja testów

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.

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ść

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

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.

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 IE 11.
  • 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