Podróż przez świat testowania - ebook

SPIS TREŚCI

Od Autorek do Ciebie

1. Zgłaszanie błędów

1.1. Otaczają nas błędy

1.2. Schemat zgłoszenia

1.3. Bug czy feature

2. Proces wytwarzania oprogramowania

2.1. Produkcja i cykl Deminga (PDCA)

2.2. Scrum

2.3. Kaskada i model V

2.4. Waterfall vs. Agile

2.5. Role w projekcie

3. Poziomy testów

4. Typy testów

4.1. Testy funkcjonalne

4.2. Testy niefunkcjonalne

4.2.1 Testy wydajnościowe

4.2.1.1. Testy obciążeniowe

4.2.1.2. Test przeciążeniowe

4.2.2. Testy przenaszalności

4.2.3. Testy zabezpieczeń

4.2.4. Testy użyteczności

4.3. Testy związane ze zmianami

4.3.1. Testy Potwierdzające (retesty)

4.3.2. Testy Regresji

4.3.3. Różnica pomiędzy retestami a testami regresji

4.4. Testy Dymne

5. Zapis pomysłów na testy

5.1. Klasyczny schemat

5.2. Checklista

5.3. Mapa myśli

5.4. Przypadki testowe pozytywne i negatywne

6. Techniki testowania

6.1. Biała skrzynka

6.2. Czarna skrzynka

6.2.1. Klasy równoważności

6.2.2. Analiza wartości brzegowych

6.2.3. Testowanie w oparciu o tablicę decyzyjną

6.2.4. Testowanie przejść pomiędzy stanami

6.2.5. Testowanie oparte na przypadkach użycia

6.3. Testowanie w oparciu o doświadczenie

7. Narzędzia

8. Poszukiwanie pracy

8.1. CV

8.2. Oferty pracy

9. Dzień z życia testera

Zakończenie

Odpowiedzi

Praktykuj – Zgłaszanie błędów

Praktykuj – Proces produkcji oprogramowania

Praktykuj – Poziomy testów

Praktykuj – Typy testów

Praktykuj – Zapis pomysłów na testy

Praktykuj – Techniki testowania

Rozwiązane krzyżówki

Dziękówka

BibliografiaOd Autorek do Ciebie

Szukasz swojej drogi zawodowej? Myślisz o przebranżowieniu się? Ciekawią Cię zagadnienia związane z pracą testera oprogramowania? Chcesz usystematyzować swoją wiedzę lub po prostu masz ochotę przeczytać przyjemnie napisaną książkę? Jeśli na którekolwiek z tych pytań odpowiedź brzmi „TAK!”, to porzuć wszelką beznadzieję, bo jesteś w dobrym miejscu! Zapraszamy do lektury naszej wspólnej opowieści o świecie testowania.

Uwaga! Nie każdy po przeczytaniu tej książki uzna testowanie oprogramowania za swoją ścieżkę kariery. Jednak „Podróż przez świat testowania” pokaże Ci podstawy testowania i może pomóc w zweryfikowaniu, czy droga testera jest dla Ciebie.

Chcemy, żeby książkę czytało się lekko i przyjemnie. Mamy nadzieję, że żarty będą zabawne nie tylko dla nas. Czytając pamiętaj, że jesteśmy testerkami, pracujemy w branży IT i chcemy dzielić się wiedzą najlepiej jak potrafimy. Dziękujemy wszystkim osobom (redaktorom, korektorom i konsultantom), dzięki którym nasze zdania są bardziej składne. Liczymy na wyrozumiałość w stosunku do liczby użytych uśmiechniętych buziek :)

Zaczynamy! Od razu od praktyki, bo nie ma na co czekać. Takich właśnie praktycznych elementów będzie w tej książce sporo. Zależy nam na umożliwieniu Ci doświadczania wszystkiego co przeczytasz, żeby łatwiej Ci to było zrozumieć i zapamiętać. Zatem zatrzymaj się na chwilę przy każdej sekcji „Praktykuj!” i postaraj się wykonać zawarte w niej zadanie. Jeśli wymaga ono zapisania czegoś, to znajdziesz pod nim miejsce na własne notatki. Czasem ta wolna przestrzeń może nie wystarczyć, więc notatnik może się przydać (ten fizyczny lub komputerowy :)). Odpowiedzi do niektórych sekcji „Praktykuj” znajdziesz na końcu książki. W „Podróży przez świat testowania” umieściłyśmy również zadania, które będą wymagały poszukania i zainstalowania aplikacji lub udania się w czeluści Internetu i przećwiczenia tam nowych umiejętności. Wtedy po prostu…

Praktykuj!

Potestuj ostatnio odwiedzony sklep internetowy.

I jak wrażenia? Co zostało poddane testom? Ile czasu Ci to zajęło? Czy masz pewność, że wszystko zostało przetestowane? Pewnie ciężko Ci odpowiedzieć na to pytanie. A może nawet nie wiesz jak zacząć to całe „testowanie”. Co to w ogóle znaczy „przetestuj”? Z jednej strony odpowiedź jest prosta – sprawdź czy działa. Ale ale, co znaczy „działa”? Z drugiej strony testowanie to nie tylko sprawdzanie czy działa, jakkolwiek zdefiniujemy słowo „działa”. Testowanie to wielowymiarowe pojęcie, którego definicji w książkach, artykułach i sylabusach jest mnóstwo, a jeszcze więcej definicji spotkasz na rozmowach kwalifikacyjnych i w poszczególnych firmach. Na dodatek trafisz jeszcze na takie pojęcia jak testy jednostkowe, niefunkcjonalne, wydajnościowe, testowanie regresji, przypadki testowe, wartości brzegowe, tablice decyzyjne… istny zawrót głowy.

Na szczęście trzymasz w rękach książkę, w której wyjaśnimy Ci te pojęcia w przystępny sposób i damy możliwość doświadczenia testowania „na własnej skórze” dzięki zadaniom praktycznym. Naszym zdaniem teoria jest ważna, ale nic nie zastąpi starej dobrej praktyki. Zatem podczas podróży przez kolejne strony książki, będziesz mieć możliwość wykorzystania nowo nabytych umiejętności. Poprowadzimy Cię przez ten ciekawy, choć nieco zawiły świat i wskażemy drogę, którą możesz obrać w dalszym rozwoju.

Kilka ważnych informacji zanim zaczniesz czytać dalej:

• Przykłady w tej książce są życiowe, ale też wesołe. Niestety zawiodą się miłośnicy banków, kredytów, egzaminów i chorób. Chciałyśmy, aby nasza książka bawiła ucząc i uczyła bawiąc. Poważne przykłady są dobre i same z nich korzystamy w naszych szkoleniach, jednak w tej książce chciałyśmy, żeby było inaczej – lekko, przyjemnie, uśmiechnięto-emotkowo :)

• Serio, zachęcamy do czytania innych książek o testowaniu. W naszej znajdziesz tylko wycinek wiedzy, a na rynku jest mnóstwo świetnych pozycji. Bardzo lubimy książki, szczególnie naszych polskich autorów – Adama Romana, Radosława Smilgina, Karoliny Zmitrowicz. Naprawdę warto czytać!

• W książce będziemy używać określenia „tester”, bo tak jest prościej. Mamy nadzieję nie urazić żadnej testerki ani QA. Wiemy, że zapewnianie jakości to nie tylko testowanie, a „QA” to szerokie pojęcie. Robimy to dla wygody czytającego (no dobra, dla naszej też ;) ). Podobnie jest ze słowem „błąd”. W książce nazywamy błędem wszystko to, co na co dzień w pracy tak się właśnie określa. W innych publikacjach możesz znaleźć oddzielne definicje na błąd, defekt czy awarię.

• Jeśli któryś rozdział lub fragment książki wydaje Ci się niezrozumiały, to śmiało idź dalej. Wróć do niego później. Jeśli nadal nie ogarniasz, to daj nam znać, bo może nie opisałyśmy czegoś wystarczająco dobrze: [email protected]

Długo zastanawiałyśmy się od czego zacząć książkę. Naturalnym pomysłem było rozpoczęcie „od początku”, czyli od procesu produkcji oprogramowania i umiejscowieniu w nim testera. Jest to podejście stosowane w różnych materiałach dotyczących testowania. Często też tak zaczyna się kursy i szkolenia. Zapewne nie wszyscy Czytelnicy chcą traktować tę książkę jako kompleksowy kurs testowania. Może znajdą się też tacy, którzy będą chcieli w ciągu tygodnia lub dwóch przejść niektóre rozdziały, skupić się na praktyce i już zacząć szukać pracy. Gdy zgłaszają się do nas takie osoby, to zwykle zaczynamy szkolenie od tego, jak tester powinien zgłaszać błędy. Z myślą o takich właśnie czytelnikach zaczynamy książkę od rozdziału „Zgłaszanie błędów”. Natomiast osoby, które chcą spokojnie przeczytać książkę „od deski do deski”, także powinny zacząć właśnie od tego rozdziału. Mamy nadzieję, że dostarczy on Wam energii na czytanie kolejnych stron i rozdziałów oraz da wiarę w to, że się da!

Powodzenia! :)

Karolina i Natalia1. Zgłaszanie błędów

1.1. Otaczają nas błędy

Tak jak trudno sobie wyobrazić rycerza bez miecza, kransoluda bez brody, jednorożca bez rogu, sieciowca bez RJ-tki, whisky bez lodu, schabowego bez ziemniaczków, plażę bez parawanów i Geralta bez Rivii… tak równie trudno jest wyobrazić sobie testera bez umiejętności zgłaszania błędów.

Właśnie dlatego zaczynamy naszą przygodę z testowaniem od tej umiejętności. W życiu codziennym na komputerze swoim lub w przestrzeni publicznej napotykasz na rozmaite nieprawidłowości, uchybienia, pomyłki, defekty, mankamenty, felery, czy usterki. Pojawiają się one na stronach internetowych, w wielkich i małych systemach informatycznych, programach komputerowych czy aplikacjach mobilnych i webowych1.

Czy zdarzyło Ci się zgłosić taki napotkany błąd właścicielowi strony lub aplikacji? Pracując w roli testera oprogramowania robimy to na co dzień i chętnie podzielimy się z Tobą tą wiedzą i doświadczeniem.

Praktykuj! Zrzut ekranu nafaszerowany błędami

Zapisz teraz wszystkie błędy, które widzisz na poniższym zrzucie ekranu ze sklepu internetowego (z ang. screenshot, print screen lub krócej w branży używamy: screen).

------------------------------------------------------------------------

------------------------------------------------------------------------

Zgłoszenia błędów zapisane? Polecamy Ci przeczytać je ponownie za jakiś czas (za godzinę lub jutro). Sprawdź czy będziesz wiedzieć o co w nich chodzi. Takie „samosprawdzanie” jest prostą i dobrą metodą na doskonalenie umiejętności zgłaszania.

Ile błędów dostrzegasz na zrzucie ekranu?

Jeśli widzisz ich kilka to dobrze :) W dalszych rozdziałach książki nauczymy Cię jak wyszukiwać błędy, na jakiej podstawie określa się co jest błędem, a co nim nie jest i jakich technik można użyć, żeby testowanie było efektywniejsze.

Jeśli udało Ci się znaleźć aż 15 błędów, to świetnie! Choć to pewnie nadal nie wszystkie błędy, które są widoczne na tym screenie. Dlatego czytaj i praktykuj dalej!

1.2. Schemat zgłoszenia

W pracy w projekcie informatycznym ważne jest, aby zapisywać wszystko w sposób zrozumiały dla każdej czytającej zgłoszenie osoby. Dlaczego? Bo nasze zgłoszenia mogą być analizowane nie tylko przez programistów, którzy będą przygotowywać poprawkę2. Zainteresowane zgłoszeniami mogą być także osoby zarządzające projektem, które chcą mieć wiedzę na temat tego, co się dzieje i odpowiednio priorytetyzować pracę. Jeśli w zespole są inni testerzy, to byłoby dobrze, by oni również z łatwością zrozumieli o co chodzi w zgłoszeniu.

W IT na całym świecie przyjęły się takie elementy zgłoszeń:

• Tytuł – krótka informacja czego dotyczy zgłoszenie. Przykład tytułu: „Po kliknięciu przycisku Zarejestruj pojawia się pusta strona”.

• Priorytet – czyli jak ważne jest to zgłoszenie. Czasem spotkasz się tutaj z podziałem na ważne i pilne, co pomaga określić jak szybko ktoś powinien zająć się tym tematem.

Przykład priorytetów: krytyczny, wysoki, normalny, niski, trywialny.

• Środowisko – informacja o tym gdzie wystąpiła opisywana sytuacja, gdzie ją można odtworzyć. Środowiskiem jest urządzenie (np. komputer, smartfon, tablet), system operacyjny (np. Windows/Linux/Mac/Android/iOS) lub przeglądarka (np. Chrome, Firefox, Safari, Edge). W tym miejscu również podaje się wersję testowanego programu (np. 2.0.53, 0.0.16asd). Warto też podać informację dotyczącą tego czy sytuacja występuje na produkcji (tak nazywamy w IT środowisko dostępne dla klientów), na środowisku testowym, czy może na środowisku lokalnym testera lub programisty.

• Kroki3 lub opis – zwykle podaje się krok po kroku co należy zrobić, aby otrzymać dany rezultat. Czasem rozpisywanie kroków nie jest potrzebne, gdyż wystarczy jedno zdanie opisu. Warto zwrócić szczególną uwagę na ten punkt, bo jest on kluczowy dla odtworzenia sytuacji i zrozumienia zgłoszenia.

Przykład kroków:

1. Na formularzu rejestracji wpisz prawidłowy email

2. Wpisz poprawne hasło

3. Wpisz to samo hasło w pole „Powtórz hasło”

4. Kliknij przycisk „Zarejestruj”

• Rezultat otrzymany – dokąd doprowadziły nas kroki, czyli co faktycznie się wydarzyło. Przykład: „Po kliknięciu przycisku „Zarejestruj” pojawia się pusta strona. Po odświeżeniu jej nic się nie zmienia. Można natomiast zalogować się na to nowo utworzone konto”.

• Rezultat oczekiwany – co powinno się wydarzyć, jakiego zachowania oczekujemy.

Przykład: „Po kliknięciu przycisku „Zarejestruj” użytkownik powinien dostać informację o pomyślnym zakończeniu operacji, czyli o utworzeniu konta”.

Jest jeszcze jeden element zgłoszeń, o którym warto pamiętać. Mówi o nim chińskie przysłowie: „Jeden obraz jest wart więcej niż tysiąc słów”.

Co jest tym obrazem w przypadku zgłoszeń w IT? Zrzut ekranu :) Przykład takiego screenshota pojawił się już w tym rozdziale. Warto pamiętać, żeby był na nim widoczny pasek adresu strony. Można również zaznaczyć na zrzucie ekranu element, którego zgłoszenie dotyczy.

Jeśli masz taką możliwość, to nagraj filmik lub stwórz GIF-a. W wielu przypadkach zgłoszeń bez obrazu trudno byłoby dojść do tego, co jest nie tak lub zajęłoby to zbyt dużo czasu. Zdarza się, że trudno nam ubrać w słowa to co widzimy. Obrazy ułatwiają komunikację, dlatego można zaliczyć je do najważniejszych elementów zgłoszeń.

W różnych firmach możemy spotkać różne dodatkowe elementy zgłoszeń, o których możesz przeczytać w Internecie, np.:

• warunki wstępne,

• dane testowe,

• szczegółowy opis,

• funkcja lub moduł, którego dotyczy zgłoszenie,

• powtarzalność wystąpienia,

• klasyfikacja czy kategoria błędu,

• wersja, w której zgłoszenie powinno być zrealizowane.

Na początek wystarczy, że zapamiętasz te najważniejsze elementy: tytuł, priorytet, środowisko, kroki, rezultat otrzymany i rezultat oczekiwany.

Praktykuj! Przykładowe zgłoszenia ze sklepu internetowego

Przed Tobą kilka przykładów zgłoszeń ze sklepu internetowego. Przeanalizuj je. Poszukaj w nich wad i zalet. Ucz się na nich, żeby doskonalić swoje umiejętności!

Zgłoszenie 007

Tytuł: Nie działa koszyk z grami

Kroki:

1. Wrzucam grę do koszyka

2. Dodaję drugą grę

3. Usuwam pierwszą

Rezultat otrzymany: Zostaje druga gra w promocyjnej cenie.

Rezultat oczekiwany: W koszyku powinna zostać druga gra, ale w normalnej cenie albo żadna.

Zgłoszenie 404

Tytuł: Gry w koszyku źle się zachowują

Kroki: Wrzuć gry do koszyka i patrz co się dzieje

Rezultat otrzymany: Dzieje się źle

Rezultat oczekiwany: Powinno być dobrze

Zgłoszenie 1024

Tytuł: W koszyku błędnie nalicza się cena gry w promocji

Środowisko: Chrome

Priorytet: Wysoki

Kroki:

1. Dodaj do koszyka grę RPG, która daje możliwość skorzystania z promocji „Wyścigi za pół ceny” np. KODPROD: 123456

2. Dodaj do koszyka grę wyścigową, która jest objęta promocją.

Np. KODPROD: 999876

3. Usuń z koszyka pierwszą grę (RPG)

Rezultat otrzymany: W koszyku zostaje gra wyścigowa w cenie promocyjnej.

Rezultat oczekiwany: Po usunięciu gry RPG, cena gry wyścigowej powinna wzrosnąć do standardowej ceny (niepromocyjnej).

Zgłoszenie 2147483647

Tytuł: Po usunięciu z koszyka gry, która daje możliwość skorzystania z promocji, gra, która w nim zostaje jest w promocyjnej cenie, choć powinna być w normalnej cenie, bo w koszyku nie ma już produktu z promocją

Środowisko: Przeglądarka internetowa Chrome na laptopie, Chrome na telefonie z androidem 8, Safari na tablecie z iOSem 13.

Priorytet: Wysoki

Kroki:

1. Do koszyka została dodana gra RPG (z ang. role-playing game, czyli gra fabularna, w której można rozwijać postać, realizować zadania, zdobywać punkty, awansować i ratować świat). Ta gra, która została dodana do koszyka, musi być w promocji, dzięki której będzie można kupić inną grę z określonej puli gier. Promocja ta nazywa się „Wyścigi za pół ceny” i obowiązuje od 30 marca do 5 maja. Gdyby jednak już nie była aktywna, to można ją włączyć do celów testowych w Panelu administracyjnym w zakładce Promocje.

2. Następnie należy dodać do koszyka drugą grę, która jest objęta promocją. Po dodaniu do koszyka powinny być w nim dwie gry – jedna (RPG) w normalnej cenie oraz druga (wyścigi) w cenie za połowę ceny standardowej.

3. Kolejnym krokiem jest usunięcie z koszyka tej pierwszej gry, która jest w „Wyścigi za pół ceny”. Po usunięciu tej gry w koszyku powinna zostać tylko jedna gra.

Rezultat otrzymany: Po usunięciu pierwszej gry (RPG, która jest w promocji „Wyścigi za pół ceny”) w koszyku zostaje druga gra (wyścigi) która jest za połowę ceny, mimo że powinna być za standardową cenę bo pierwsza gra, dzięki której ta promocja była aktywna została usunięta z koszyka.

Rezultat oczekiwany: Druga gra, która jest w promocji za pół ceny, jeśli kupuje się ją razem z grą, którą ta promocja obejmuje, powinna być w standardowej cenie, jeśli z koszyka usuniemy grę, która tę promocję powodowała.

Jakie widzisz plusy i minusy tych zgłoszeń? Poniżej kilka myślników z naszymi luźnymi wnioskami.

Zgłoszenie 007

• Zgłoszenie napisane krótko i zwięźle. Dla wielu osób pewnie zbyt krótko. Jednak dla zespołu projektowego to zgłoszenie, co może wyda się zaskakujące, jest wystarczające. Osoby, które dobrze znają projekt i jego mechanizmy będą wiedziały o co chodzi.

• Podobnie wyglądają zgłoszenia tworzone w pośpiechu, pozostawione w systemie zarządzania błędami tylko dla porządku, żeby został po nich ślad.

• Zgłoszenie jest napisane w pierwszej osobie liczby pojedynczej, czyli z perspektywy zgłaszającego. Jest to jedna z możliwych form. Przeczytaj uważnie inne zgłoszenia i zwróć na to uwagę. Pomyśl, która forma odpowiada Tobie najbardziej.

Zgłoszenie 404

• Brakuje prawie wszystkiego ;)

------------------------------------------------------------------------

------------------------------------------------------------------------

------------------------------------------------------------------------

------------------------------------------------------------------------