Poradnik początkującego testera – #2 W poszukiwaniu (nie) pierwszej pracy jako tester oprogramowania

W poniższym artykule znajdziecie odpowiedź na pytanie, w jaki sposób znaleźć pracę na stanowisku testera oprogramowania oraz jak przygotować się do etapu rekrutacji. Sama rozmowa rekrutacyjna jest stresującym przeżyciem, szczególnie jeśli są to nasze początki w poszukiwaniu pracy i nie wiemy, jak to w praktyce wygląda. Obecnie, mimo że w branży informatycznej jest czas pracownika, to i tak, aby znaleźć dobrą pracę z odpowiednimi perspektywami, musimy się do tego solidnie przygotować. Zatem do dzieła, w końcu chcemy dostać pracę, na której nam zależy.

Wszystko zależy od kontekstu

Przygotowanie do rozmowy rekrutacyjnej, jak również sposób, w jaki odbywa się sama rekrutacja, bardzo często zależy od tego, na jakie stanowisko związane z testami oprogramowania aplikujesz. Obecnie specjalizacji w obszarze testowania jest sporo i każde ze stanowisk może charakteryzować się innym sposobem rekrutacji.  Zatem zanim zaczniesz takie przygotowania, dobrze zastanów się, czym charakteryzuje się stanowisko, na które aplikujesz i czego możesz spodziewać się na samej rozmowie rekrutacyjnej. Warto również zapytać bezpośrednio swojego potencjalnego pracodawcę lub headhuntera, w jaki sposób będzie odbywać się rekrutacja. Pracodawca powinien to docenić, gdyż w ten sposób dasz mu do zrozumienia, że zależy Ci na tej pracy.

Kategoryzując stanowiska z obszaru testowania, możemy rozróżnić najbardziej popularne:

  • Tester oprogramowania
    • tester manualny (różne poziomy doświadczenia)
  • Specjalista ds. automatyzacji testów
    • aplikacji webowych
    • aplikacji desktopowych
    • aplikacji mobilnych
  • Specjalista ds. testów wydajnościowych
  • Specjalista ds. testów bezpieczeństwa
  • Kierownik działu testów
  • Lider zespołu testów

Każda z powyższych specjalizacji będzie charakteryzowała się innym sposobem rekrutacji oraz innymi pytaniami, z którymi musisz się zmierzyć. W niniejszym artykule staraliśmy się wyciągnąć części wspólne, skupiając się jednak głównie na testerze manualnym. Zawarliśmy informacje zarówno odnośnie procesu poszukiwania pracy, analizy pracodawcy, przygotowania odpowiedniej aplikacji, jak i przebiegu samej rozmowy rekrutacyjnej.

Gdzie szukać ofert pracy?

Lista miejsc, gdzie możesz znaleźć ofertę pracy w obszarze testowania oprogramowania:

  • Facebook Grupa „Testowanie Oprogramowania” – obecnie najpopularniejsza grupa na Facebooku w Polsce, dotycząca testowania oprogramowania. Regularnie pojawiają się na niej oferty pracy związane z testowaniem. Dużą zaletą jest to, że zamieszczane oferty muszą posiadać widełki płacowe
  • pracuj.pl – największy krajowy serwis, który zawiera listę ofert pracy. Przykładowo na dzień 07.07.2017 r. ofert na stanowisko „tester oprogramowania” (bez podziału na stanowiska) było 273
  • infopraca.pl – kolejny z krajowych serwisów pozwalających na znalezienie pracy. Liczba ofert w ramach obszaru testowania oprogramowania jest zdecydowanie mniejsza od pracuj.pl, ale czasem coś ciekawego udaje się znaleźć
  • GoldenLine – największy krajowy serwis społecznościowy specjalizujący się w kontaktach zawodowo-biznesowych, na którym można znaleźć sporo ofert pracy
  • LinkedIN – największy światowy serwis społecznościowy ukierunkowany na kontakty zawodowo-biznesowe. Zalecamy zarejestrowanie się na nim, aby móc śledzić oferty pracy w kraju i za granicą

Analiza ogłoszenia o pracę

Jak już znajdziemy interesujące nas ogłoszenie o pracę, ważną rzeczą jest jego analiza. To w nim powinieneś wyszukać kluczowe informacje i obszary, których wymaga twój potencjalny pracodawca i co należy uwzględnić w Twoim CV. Jeśli na przykład w ogłoszeniu pojawia się modne ostatnio hasło, że praca odbywa się w środowisku Agile / Scrum, warto umieścić (o ile znamy) nasz poziom znajomości w samym CV. Jeśli jest to nasza pierwsza praca i nie mamy praktycznego doświadczenia w pracy z danym frameworkiem czy narzędziem, warto przynajmniej znać część teoretyczną, danego zagadnienia i zawrzeć odpowiednią adnotację. Warto również zwrócić uwagę, w jakim języku należy przesłać swoją aplikację. W sytuacji, gdy ogłoszenie jest w języku angielskim, nie ma co się zastanawiać i należy aplikację również wysłać w tym języku. W przypadku, gdy ogłoszenie jest w języku polskim i nie jest zaznaczone, że CV musi być po angielsku, można wysłać w naszym ojczystym języku. Warto jednak na to zwracać uwagę. Co dalej?

Analiza pracodawcy

Zanim zaaplikujesz na swoje wymarzone stanowisko, warto zrobić rozpoznanie, czym dokładnie zajmuje się Twój przyszły pracodawca, w jaki sposób tworzy swoje produkty i jaką ma renomę na rynku. Nie wszystkie te rzeczy wynikają z samego ogłoszenia o pracę, zatem warto poświęcić trochę czasu na przeprowadzenie rozpoznania. W przypadku, gdy rekrutacja odbywa się poprzez „Head Huntera”, możemy na początku nie wiedzieć, do jakiej firmy aplikujemy, ale w późniejszym etapie także można przeprowadzić taką analizę.

  • Analiza strony WWW

Przeanalizuj firmową stronę internetową potencjalnego pracodawcy i zapoznaj się z jego ofertą oraz produktami, które w ostatnich latach realizował. Na stronie WWW bardzo często znajdziesz informacje dotyczące technologii, narzędzi oraz technik wykorzystywanych w trakcie tworzenia produktów, co pozwoli odpowiednio przygotować się do rozmowy rekrutacyjnej. Często można również znaleźć podrozdział dotyczący rekrutacji pracowników, gdzie można znaleźć istotne elementy dotyczące sposobu rekrutacji. Aplikując na stanowisko testera, szczególnie interesujące dla Ciebie powinny być aspekty testowania oraz zapewnienia jakości – pozwoli to na poznanie, jak potencjalny pracodawca podchodzi do tych zagadnień.

  • Media społecznościowe

Warto zapoznać się z profilem firmowym na Facebooku, Twitterze, LinkedIN, GoldenLine itp., na którym to również można znaleźć dość istotne informacje o ostatnich wydarzeniach w firmie, czego znajomością możesz pochwalić się podczas samej rekrutacji. My, jako potencjalni pracodawcy, często wypytujemy naszych kandydatów, co wiedzą o naszej firmie i kluczowych wydarzeniach z nią związanych (informacje te są ogólnodostępne).

  • GoWork

Jeśli ktoś aplikuje do firm z naszego krajowego podwórka, warto zapoznać się z profilem pracodawcy dostępnym w serwisie GoWork, w którym to znajdują się opinie obecnych / byłych pracowników firmy, do której aplikujemy. Jesteśmy daleko od tego, aby wierzyć tym wszystkim opiniom (i tym przesłodzonym, i tym bardzo negatywnym), ale często wśród wielu komentarzy znajduje się informacja odnośnie sposobu rekrutacji. Może się również zdarzyć, że będą tam zamieszczone pytania,  które zostały zadawane w trakcie rozmowy. Warto zatem poświęcić te 3 minuty, aby zobaczyć, czy czegoś istotnego nie można się dowiedzieć.

Przygotowanie CV

Przeglądnęliśmy już „wizytówkę” naszego potencjalnego pracodawcy. Warto teraz popracować nad naszą wizytówką, którą będziemy wysyłać do pracodawcy. Dobrze przygotowane CV powinno zaciekawić potencjalnego pracodawcę, powinno być proste, spójne i zawierać informacje dotyczące naszego doświadczenia zawodowego, wykształcenia, odbytych szkoleń i uzyskanych certyfikatów, umiejętności (miękkich i twardych) oraz ewentualnie zainteresowań. Poniżej przedstawiamy wzór takiego CV (jeśli chcesz otrzymać ten szablon w postaci pliku tekstowego, zgłoś się bezpośrednio do Nas).

Chcąc zabezpieczyć się przez falą „hejtu” uprzedzamy, że zdajemy sobie sprawę, że jest wiele lepszych, bardziej profesjonalnych wzorów. Naszym celem nie było stworzenie idealnego szablonu CV, a jedynie wskazanie, jakie elementy powinny się w nim znaleźć.

thumbnail of cv_szablon

cv_szablon

Zanim wyślesz CV

  • Sprawdź CV w poszukiwaniu błędów ortograficznych (spell-checker powinien wystarczyć)
  • Sprawdź, czy Twoje CV jest aktualne – weryfikacja adresu email, nr telefonu, profilu LinkedIN, itp.
  • Wyślij CV koleżance/koledze/nam do zweryfikowania. Warto, aby ktoś niezależny na nie spojrzał i dał ewentualne uwagi
  • Skonwertuj CV do PDF – dobrą praktyką jest wysyłanie CV w takiej postaci, gdyż uchroni to Nas przed ewentualnymi problemami w wyświetlaniu pliku związanymi z niekompatybilnymi wersjami programu, w którym było tworzone CV
  • Pamiętaj, aby nie kłamać w CV – tego potencjalny pracodawca nie lubi chyba najbardziej, a prawda zawsze wyjdzie na jaw

Aplikujemy

Przyszła chwila, w której wyślesz swoją pierwszą aplikację. Tutaj również warto zwrócić uwagę na kilka rzeczy, aby nie „spalić” naszej kandydatury na starcie

  • Poprawny mail – wysyłając aplikację bezpośrednio na maila, zwróć uwagę, czy nie zrobiłeś żadnej literówki. Wówczas otrzymasz zwrotkę o niedostarczonym CV i będziesz musiał wysłać je ponownie. W najgorszym wypadku ktoś inny otrzyma Twoje CV, a Ty nieświadomy błędu, będziesz czekać na odpowiedź od pracodawcy
  • Zwróć uwagę na swój adres email – mieliśmy okazję widzieć setki aplikacji od potencjalnych kandydatów. Czasem dostawaliśmy aplikacje od blondynka@domenaukryta.pl, fajnyfacet@domenaukryta.pl czy grubybenek23@domenaukryta.pl. Nie musimy pisać, że takie adresy są mało profesjonalne i mogą skutkować tym, że potencjalny pracodawca nie potraktuje nas poważnie. Warto skorzystać z tradycyjnego podejścia i wysłać aplikację z maila <imię.nazwisko@jakaspoczta.pl>
  • Temat wiadomości – uwzględnij w temacie wiadomości nazwę ogłoszenia o pracę oraz nr ref. często występujący w ogłoszeniu. W przeciwnym wypadku Twoja aplikacja może nie trafić do odpowiedniego departamentu/działu
  • Załącznik – nie zapomnij załączyć swojego CV

Przygotowanie do rozmowy rekrutacyjnej

Pierwszym sukcesem jest zaproszenie na rozmowę rekrutacyjną.  Rozmowa rekrutacyjna może przybrać jedną z następujących form (nie są to wszystkie formy):

  • rozmowa stacjonarna w siedzibie pracodawcy
  • rozmowa telefoniczna
  • rozmowa via Skype lub podobne narzędzie

Bez względu na formę rozmowy należy się do niej solidnie przygotować. Warto przypomnieć sobie zakres sylabusa ISTQB Foundation Level i poczytać jakieś książki z dziedziny testowania oprogramowania. Dla osób rozpoczynających swoją karierę w testowaniu możemy tutaj polecić książkę „Zawód tester” Radka Smilgina. Ponadto, jeśli w ofercie pracy jest zaznaczone, że wymagana jest umiejętność tworzenia przypadków testowych, można być praktycznie pewnym, że takie pytanie / zadanie się pojawi. Na podstawie naszego doświadczenia i doświadczenia „wujka googla” stworzyliśmy zestaw przykładowych 30 pytań rekrutacyjnych, które czasem pojawiają się na rozmowach rekrutacyjnych. Od razu zaznaczamy, że nawet, jeśli wykujesz te pytania na pamięć, nie gwarantujemy otrzymania pracy 🙂

 

Popularne pytania na rozmowie rekrutacyjnej na stanowisko 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.

Retest 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

Rozmowa rekrutacyjna

Poniżej znajdziesz formę rozmowy, którą sami wykorzystujemy w trakcie rekrutacji. Będzie to więc z punku widzenia potencjalnego pracodawcy. Zaznaczamy, że Twoja rozmowa rekrutacyjna może wyglądać inaczej.

Sama rozmowa rekrutacyjna dzieli się zazwyczaj na kilka części. O tym, że na rozmowę warto być parę minut wcześniej chyba nie musimy wspominać, ale też nie polecamy nękania swojego potencjalnego pracodawcy na przykład 30 min przed czasem, na który się umówiliśmy (o ile jest to rekrutacja stacjonarna). Pamiętaj również, aby wziąć ze sobą na taką rozmowę swoje CV (najlepiej w dwóch kopiach – dla siebie i pracodawcy), certyfikaty, dyplomy, jeśli jakieś posiadasz, oraz coś do notowania.

  • Wstęp

Podczas pierwszej części pracodawca zazwyczaj omawia szczegóły rekrutacji – jak będzie ona wyglądać, ile będzie etapów i kto bierze udział w takiej rozmowie. Zazwyczaj w samej rozmowie uczestniczy osoba z HR lub / oraz ewentualny przełożony, dla którego potencjalny pracownik będzie pracować, ale nie jest to regułą. Dobrze, jeśli pracodawca (lub osoba go reprezentująca) przedstawi szczegóły stanowiska, na które szuka pracownika – jeśli nie, możesz dopytać o szczegóły (nie uważamy, że jest to niegrzeczne).

  • Przedstawienie swojej kariery zawodowej

Tutaj zaczyna się Twoja rola, nabierz dwa, trzy oddechy i … Musisz przedstawić swoją dotychczasową karierę zawodową. Należy zaznaczyć, że najlepiej skupiać się na sprawach istotnych dla naszego potencjalnego pracodawcy. Niekoniecznie musi go interesować, że było się na przykład hostessą czy roznosiło się ulotki (chyba, że ma to swoje uzasadnienie). W tej części przydaje się Twoje CV, którym możesz się posłużyć, aby nie przeoczyć jakiejś istotnej rzeczy. Warto, aby sama wypowiedź była spójna i najlepiej podzielić ją na kilka części:

– stanowiska, na których się pracowało

– produkty, które się testowało

– techniki testów wykorzystywane w pracy

– jak wyglądał proces testowy

– Twoje obowiązki w pracy

– w jaki sposób wyglądała współpraca z innymi osobami

– narzędzia wykorzystywane w pracy

Takie omówienie pozwoli na zbudowanie pełnego obrazu u potencjalnego pracodawcy. W przypadku, gdy nie masz doświadczenia zawodowego, należałoby tutaj wymieniać te rzeczy, które poznało się na studiach, stażu czy we własnym zakresie – każdy w końcu od czegoś zaczynał. Chcąc mieć większe szanse, warto budować swoją karierę zawodową już na etapie studiów.

  • Certyfikaty,  umiejętności, znajomość języków obcych

Kolejną częścią jest przedstawienie do wglądu osobie weryfikującej Twoją wiedzę posiadanych certyfikatów / dyplomów oraz zwrócenie uwagi na znajomość języków obcych. Obecnie takie minimum to komunikatywna znajomość języka angielskiego.

  • Pytania z obszaru testowania

Kolejnym elementem jest weryfikacja Twojej wiedzy z obszaru testowania oprogramowania. Bez względu na jakie stanowisko z obszaru testów aplikujesz, jest pewna część wspólna, o którą zazwyczaj pracodawcy pytają, szczególnie, że większość pracodawców wymaga  posiadania wiedzy lub certyfikatu na poziomie ISTQB FL. Jeśli odrobiłeś „pracę domową” z punktów wyżej, nie powinieneś mieć problemu z odpowiedziami na podstawowe pytania. Wiadomo, zawsze może zdarzyć się pytanie, na które nie znasz odpowiedzi, ale złym „pomysłem” jest odpowiadanie na wszystkie pytania „nie wiem” 🙂

  • Zadania

Jednym z elementów, który ma miejsce w trakcie rekrutacji pracownika na stanowisko testera, są zadania, które potencjalny pracownik musi wykonać. Zadania muszą być o tyle proste, aby w szybki sposób zweryfikować wiedzę i dać odpowiedź, czy kandydat nadaje się do pracy.

Nasza firma w obszarze testów manualnych daje zazwyczaj kandydatowi jakąś aplikację i prosi o przetestowanie, np. wykonanie testów eksploracyjnych. Rezultatem takiego zadania ma być poprawnie zaraportowane zgłoszenie błędu, utworzony przypadek testowy i przekazanie ogólnych informacji, co do wykrytych błędów. Na takie zadanie kandydat ma około 30 min czasu.  Ta część z reguły daje pracodawcy odpowiedź na to, czy chcemy współpracować z taką osobą, bo nie zawsze osoba, która świetnie poradzi sobie z pytaniami teoretycznymi, jest w stanie wykorzystać tą wiedzę w praktyce. Niektóre z firm kończą swoją rekrutację na etapie pytań teoretycznych 🙂

  •   Podsumowanie

Kwestia zamknięcia takiej rozmowy rekrutacyjnej to również istotny element. Zazwyczaj na koniec rozmowy rekrutacyjnej pracodawca pyta o oczekiwania finansowe i pozafinansowe potencjalnego kandydata. Warto tutaj zaznaczać, czy oczekiwana kwota jest kwotą brutto czy netto i jaki sposób zatrudnienia Cię interesuje / jest możliwy.

Pozostało oczekiwanie

Na koniec rozmowy rekrutacyjnej należy upewnić się, że dostaniesz informację zwrotną o procesie rekrutacji oraz o jego wynikach.

No nic, teraz pozostało już tylko oczekiwanie…, a My życzymy powodzenia w poszukiwaniu pracy i trzymamy kciuki.

 DODATEK A – Dbanie o swój wizerunek

Warto zacząć myśleć o tym już na wczesnym etapie swojej kariery (a nawet przed jej rozpoczęciem). Dodatek ten z biegiem czasu przekształci się w osobny artykuł, ale już teraz wrzucamy parę kwestii do zapamiętania.

  • Potencjalny pracodawca sprawdzi Cię w „sieci” – warto mieć to na uwadze, wrzucając np. obraźliwe treści o swoim poprzednim pracodawcy na profil facebookowy lub zamieszczając fanatyczne zdjęcia
  • Dbaj o swój profil na LinkedIN – powinien być aktualny, spójny z CV (jest to również potencjalne miejsce znalezienia pracy)
  • Dbaj o swój profil na GoldenLine (opcjonalnie) – jak powyżej
  • Występuj na meetupach – nawet osoby z mniejszym doświadczeniem mają możliwość występowania na różnych meetupach, np. z obszaru testowania.  Jest to świetna rzecz, którą można również zamieścić w CV, nie mówiąć o doświadczeniu i kontaktach, które zdobędziemy