Pytania rekrutacyjne dla testera

Pytania rekrutacyjne dla testera: Podczas przygotowywania się do rekrutacji jako tester, kluczowym jest zrozumienie typowych pytań, na które można się spodziewać, oraz staranne przygotowanie odpowiedzi. Będziemy omawiać zarówno ogólne pytania, które testują podstawową wiedzę i podejście do testowania, jak i bardziej zaawansowane pytania. Pozostając na bieżąco z najnowszymi trendami i wymaganiami w branży testowania, będziesz w stanie skutecznie przygotować się do rekrutacji i wyróżnić się wśród innych kandydatów. Przyjrzymy się więc kilku istotnym pytaniom rekrutacyjnym dla testerów, które mogą Cię spotkać podczas procesu selekcji. Gotowy, aby odkryć tajniki udanej rekrutacji jako tester? Przejdźmy do działania!

Zgłoszenia incydentu to jeden z podstawowych obowiązków testera oprogramowania. Poprawna zgłoszenie  incydentów pozwala na znacznie szybsze identyfikacje ewentualnych defektów i ich poprawę. Poprawny raport o incydencje powinien się składać z następujących elementów:
  • Tytuł / Podsumowanie zgłoszenia – Tytuł powinien jasno i zwięźle podsumowywać gdzie występuje błąd i na czym polega.
  • Priorytet – Priorytet nadawany przez testera powinien wynikać z oceny na ile dany błąd utrudnia/uniemożliwia pracę w aplikacji. Zazwyczaj korzystamy tutaj z góry ze zdefiniowanych priorytetów takich jak: Blocker, Critical, Normal, Major, Minor. Często również korzystamy z pola Severity które określa jak szybko dany błąd ma zostać rozwiązany, jego wpływ na aplikację i jest on niezależny od Priorytetu
  • Komponent – Wybieramy komponent/moduł w którym to wykryliśmy błąd. Komponent często przydaje się celem agregacji wykrytych incydentów.
  • Wersja – Wersja w której udało nam się wykryć defekt
  • Treść Zgłoszenia – Tutaj wszystkie szczegółowe informacje które pozwolą na powtórzenie wykrytetego błędu. Im bardziej szczegółowo opiszemy defekt tym większe prawdopodobieństwo że programista szybko zdiagnozuje problem. W treści zgłoszenia możemy również napisać wymagane kroki do powtórzenia problemu.
  • Środowisko testowe – Na jakim środowisku został wykryty defekt
  • Urządzenie/Przeglądarka – Urządzenie lub przeglądarka w przypadku aplikacji mobilnych na których udało się wykryć defekt
  • Rezultat testów – jaki jest efekt samego testu co się dzieje w systemie
  • Opcjonalnie Oczekiwany Rezultat Testów – w zależności od wiedzy testera i kultury organizacji warto wpisać jaki jest oczekiwany rezultat testów. Warto tutaj uważać aby tester nie stał się w pewnym momencie analitykiem i nie definiował wymagań co do systemu
  • Zrzuty Ekranów / Filmy – Zgodnie z cytatem obraz mówi więcej niż 1000 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 dodania nowej funkcjonalności. Skupiamy się tutaj na badaniu czy nowe funkcjonalności lub modyfikacja istniejących nie spowodowało 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ć system przeprowadzając testy regresji. Testy te również powodują największe znudzenie u testera gdyż wielokrotnie trzeba powtarzać te same testy.

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

Testy regresyjne mają za cel ponowne zweryfikowanie nie zmienionej części systemu  po wprowadzeniu zmian w innych obszarach lub po dodaniu nowych funkcjonalności  natomiast re-test jest upewnieniem się że test który nie działał prawidłowo i skutkował raportem zgłoszenia działa już prawidłowo.

  • Testy Modułowe/Jednostkowe
  • Testy Integracyjne
  • Testy systemowe
  • Testy Akceptacyjne

Smoke Testy jest 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 czy podstawowe funkcjonalności działają poprawnie. Dobrą praktyką jest posiadanie zautomatyzowanych przypadków testowych obejmujących przypadki z zakresu testów dymnych.

Testy integracyjne wykonujemy w celu wykrycia błędów w interfejsach i interakcjach pomiędzy integracyjnymi elementami. Testy integracyjne mogą weryfikować wymianę informacji pomiędzy modułami w ramach jednego systemu ale również testy integracyjne mogą polecać na weryfikacji integracji pomiędzy niezależnymi systemami. . Zazwyczaj wtedy przeprowadza się testy integracyjne już 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 np. może następować integracja z zewnętrzną bazą klientów i warto zweryfikować czy wszystkie atrybuty takich klientów przenoszą się prawidłowo. Warto zwracać uwagę na to jak system powinien się zachować w momencie aktualizacji danych w systemie z którym się integrujemy – czy aktualizacja odbywa się w czasie rzeczywistym czy nie. Testy integracyjne tzw. wewnętrzne czyli integracja modułów wykonywana jest zazwyczaj przez programistów w których to możemy wykryć typowe błędy jak, nie następuje przekazanie danych pomiędzy modułami, różne formaty komunikacji pomiędzy modułami co skutkuje ich nieprawidłowym odczytem.
W trakcie testów z systemami najlepiej korzystać z zasady że w jednym momencie integrujemy dwa systemy/moduły na raz, w przypadku integracji więcej niż jednego modułu / systemu 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 testów systemowych 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 się zachowywać system. Testy systemowe powinny również być przeprowadzane na środowiskach najbardziej zbliżonych produkcyjnych. W ramach testów systemowych możemy badać aspekty funkcjonalnych jak i niefunkcjonalnych. Np. W ramach testów funkcjonalnych przeprowadzamy testy w oparciu o wymagania a w testach niefunkcjonalnych badamy np. użyteczność czy wydajność zbudowanej aplikacji. Testy systemowe najlepiej jak są przeprowadzane przez osoby doświadczone mające wiedzę jak powinien działać testowany system.

Weryfikacja jest to  proces w którym weryfikujemy czy system lub moduł został zbudowany zgodnie z założeniami na początku projektu. Pozwoli nam to sprawdzić czy aplikacja jest zgodna z jej specyfikacją. Natomiast Walidacja pozwoli nam odpowiedzieć na pytanie czy oprogramowanie  jest zbudowane prawidłowo pod względem potrzeb i wymagań użytkownika.

Testy modułowe zwyczajowo też nazywane testami jednostkowymi lub testami komponentów są pierwszymi testami wykonywanymi w trakcie testowania. Są to testy na najniższym poziomie w trakcie którego testujemy pojedyncze fragmenty kodu (klasy, metody itp). Testy poszczególnych modułów są wykonywane w oderwaniu od reszty aplikacji. Testy modułowe pozwalają na weryfikację właściwości niefunkcjonalnych takich jak wydajność. Testy te zwyczajowo 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 kolejnych dopiero kod samej aplikacji. .

Testu Akceptacyjne są ostatnimi przeprowadzanymi testami w ramach modelu V.  Celem tych testów jest upewnienie się przez zlecającego tworzenie systemu czy produkt można zaakceptować. Często testy akceptacyjne również nazywane są odbiorami.
Jedną z charakterystyk testów akceptacyjnych jest to że testy powinny być przeprowadzone 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ą w jaki sposób będą przeprowadzone testy akceptacyjne. 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. Wszystkie obszary które będą podlegać akceptacji powinny znaleźć się w dokumencie opisującym w jaki sposób przeprowadzane będą testy akceptacyjne.

Metodyki zwinne znacznie różnią się od kaskadowego modelu wytwarzania produktów oraz w aspekcie testowania. Przykłądowo 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 – Tester 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 może znajdować się osoby zajmujące się testami oprogramowania ale to ciągle zespół odpowiedzialny jest za końcowy sykces 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 Scrum’owe dbającymi o aspekt testowania do 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 Teamem. Definicja taka obowiązuje w ramach całego Sprintu 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 czarno skrzynkowych jest to że testy wykonywane są z punktu widzenia użytkownika końcowego i jesteśmy w stanie znaleźć rozbieżności w specyfikacji.

Tutaj pracownik musi wykazać się własną inwencją :). Najlepiej odpowiadając na to pytanie zacząć od tego w jakich projektach się uczestniczy w jakich technologiach, opowiedzieć o obowiązkach i przedstawić sam proces testowy. Proces testowy powinien zaczynać się (o ile tak w firmie jest) od etapu analizy i naszego udziału w tym procesie po testy akceptacyjne.

Główne wady które występują w modelu kaskadowym 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 – przez co w późniejszym etapie testy stają się niekompletne. Po drugie proces testowania całkowicie oderwany jest od innych czynności developerskich (Planowania, Anality, Projektowania itp) co skutkuje ż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łędu w tak późnej fazie jest zdecydowanie droższy niż na etapie planowania czy analizy.

To jedno z pytań otwartych których odpowiedź zależy od tego jakie narzędzia znasz i jakie były wykorzystywane w organizacji. Podpowiedzią z naszej strony tutaj może być że odpowiadając na to pytanie warto zastanowić się nad całym cyklem rozwoju i narzędziami z których korzystamy. Np. Narzędzie do planowania i zarządzania testami, narzędzie do zgłaszania defektów, narzędzie do automatyzacji itp.

Cykl życia defektu w dużej części zależy od organizacji, wiele organizacji stosują 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 Scrum’owym a inne w modelu Kaskadowym). Poniżej przedstawiamy pełny przepływ zgłoszonego błędu wykorzystywanego w narzędziu Bugzilla
https://www.bugzilla.org/docs/2.18/html/lifecycle.html.

zacowanie czasochłonności testów jest dość złożoną czynnością i zazwyczaj przeprowadzana jest 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 już miały 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 oraz szybka natomiast musimy polegać na dobrych ekspertach. W przypadku gdy szacunki są wykonywane przez osoby bez doświadczenia może ona okazać się bardzo nieskuteczna. 
W projektach Scrumowych szacowanie projektów odbywa się np. za pomocą techniki Poker Planni
W ramach ng 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ą szacunkową  Kolejną metodą którą można wykorzystać do szacowania testów to metoda Punktów Funkcyjnych która szerzej opisana jest https://pl.wikipedia.org/wiki/Punkt_funkcyjny. W ostateczności do szacowania testów można wykorzystać średni czas potrzebny na testy – jest to 30-40% czasu developmentu.

Jest to jeden z procesów związany z wytwarzaniem oprogramowania. Testowanie zazwyczaj ma na celu weryfikację oraz walidacje tworzonego oprogramowania.  Główne czynności wchodzące w testowanie to 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 natomiast nie są w stanie nam zastąpić ich całkowicie. Szczególnie testy automatyczne są mało efektywne w trakcie rozwoju oprogramowania w którym to zachodzą ciągłe zmiany. Programista testów automatycznych nie jest w stanie nadążyć za wprowadzanymi zmianami przez co też testy stają się nie użyteczne. Testy automatyczne swoją największą wartość dają w trakcie przeprowadzania testów regresyjnych, w których to wymagana jest duża pracochłonność ze strony testów manualnych.
Podsumowując testy automatyczne są uzupełnieniem testów manualnych.

  • Zapobieganie Defektom
  • Nabieranie zaufania do poziomu jakości
  • Znajdowanie usterek
  • Dostarczanie informacji interesariuszom 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 obecnie oprogramowanie działa na wielu urządzeniach w różnych konfiguracjach,
tutaj również nie jesteśmy w stanie zweryfikować każdej możliwej kombinacji

  • Wie jak działa projekt
  • 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 się komunikować w sposób werbalny i pisemny
  • Jest osobą asertywną
  • Jest dokładny i dociekliwy
  • Charakteryzuje go ciekawość
  • Przywiązuje uwagę do szczegółów
  • Krytyczne spojrzenie do systemu

  • Plan testów powinien zawierać jakie elementy systemu będą podlegały testom
  • Powinien zawierać jakie elementy zostaną pominięte w testach
  • Opis w jaki sposób będziemy testować oprogramowanie (techniki)
  • Jakie narzędzia będą wykorzystywane w testach
  • Plan testów powinien zawierać Kryteria Zaliczenia  / Nie zaliczenia testów
  • Kryteria zawieszenia testów
  • Ogólne zadania jakie są do wykonania w obrębie procesu testowego
  • Powinien zawierać informacje o wymaganych kompetencjach (np. automatyzacja testów)
  • Wymagania potrzebne do środowiska testowego
  • Kto za co odpowiada
  • Jakie potrzeby szkoleniowe są potrzebne (np. potrzeba doszkolić ludzi z zakresu automatyzacji testów)
  • Harmonogram przeprowadzenia testów
  • W ramach planu testów również powinny być określone ryzyka oraz plany awaryjne

  • 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 testy odbywają się poprzez uruchamianie systemu i testowania poprzez zasilenie systemu danymi i weryfikacji oczekiwanych rezultatów. Testowanie modułowe, Testy integracyjne, Systemowe oraz Akceptacyjne są testami dynamicznymi.

Testy niefunkcjonalne mają za cel weryfikowanie atrybutów niefunkcjonalnych systemu. Testy niefunkcjonalne są możliwe do przeprowadzenia na każdym poziomie testów. Atrybuty niefunkcjonalne które możemy testować to:
  • Wydajność
  • Efektywność
  • Użyteczność
  • Zdolność wprowadzania zmian w przyszłości
  • Niezawodność

Model składa się zarówno z faz produkcji testowania jak i testowania oprogramowania.
Fazy produkcji oprogramowania
 – Specyfikacja Wymagań
 – Specyfikacja Systemu
 – Specyfikacja funkcjonalna
 – Implementacja
Odpowiadające im fazy testowania oprogramowania
– Testy Akceptacyjne
– Testy systemowe
– Testy integracyjne
– Testy Modułowe

Zadanie polega na tym że pracownik ma wykonać testy eksploracyjne mechanizmu logowania / rejestracji w jakimś wskazanym systemie. Efektem jego pracy ma być lista wykrytych defektów. Defekty opracowane zgodnie ze standardem raportowania zgłoszeń. Dodatkowo uczestnik rekrutacji ma opracować przypadek testowy. Czas na zadanie około 1 godziny.

Przypadek testowy to zbiór wejść, warunków wykonania oraz oczekiwanych wyników utworzony aby wykonać określoną ścieżkę w programie albo aby zweryfikować odpowiednie wymaganie. Przypadek testowy składa się z zestawu wartości wejściowych, warunków początkowych, oczekiwanych wyników oraz warunków końcowych.
Nazwa Przypadku 
Środowisko Testowe
Warunek Wstępny
Kroki do wykonania
PT1
Windows 10, IE 11
Włączona przeglądarka: www.logowanie.pl/zaloguj oraz posiadanie konta użytkownika do logowania
Podaj Logn w pole zaloguj: mtest
podaj hasło w polu passwd: hpasswd
Naciśnij klawisz zaloguj
Oczekiwany rezultat
po kliknięciu zaloguj użytkownik powinien zalogować się na stronę główną aplikacji

10 pytań otwartych na stanowisko tester oprogramowania

  1. Jakie metryki i wskaźniki używasz do oceny jakości procesu testowego ?
  2. Jakie czynniki uwzględniasz przy priorytetyzacji testów ?
  3. Jakie umiejętności uważasz za kluczowe dla testera i jak je rozwijasz
  4. Jakie narzędzia wykorzystujesz w swojej pracy jako tester oprogramowania – co możesz polecić ?
  5. Jak podejdziesz do testowania aplikacji , której wymagania są niejasne lub niedokładne
  6. Z jakich źródeł czerpiesz wiedzę z obszaru testowania
  7. Jaki artykuł lub książkę możesz polecić osobą rozwijającą się w obszarze testowania oprogramowania
  8. Jakie są Twoje ulubione techniki testowania i dlaczego ?
  9. Jakie cechy powinien mieć dobry tester oprogramowania ?
  10. Jakie są zalety automatyzacji testów oprogramowania ?

Share This Post!

Ostatnie wpisy

Najnowsze komentarze

    Ostatnie wpisy