SPIS TREŚCI
8.
WPROWADZENIE
„Praktyka testowania” to zbiór zadań, z jakimi się spotkasz podczas codziennej pracy testera. Dotyczy tych zagadnień, które mogą Ci się przydać zarówno podczas rozmów kwalifikacyjnych, jak i w czasie wykonywania zawodowych obowiązków. Książka jest przeznaczona dla osób, które poznały już aspekty teoretyczne za pomocą sylabusa ISTQB (poziom podstawowy) czy też mojej książki „Zawód tester”, a teraz chcą wzbogacić swoją wiedzę praktycznymi przykładami. Na pojedyncze zadanie składają się:
• odrobina teorii z zachętą do samodzielnego przypomnienia sobie szczegółów,
• opis zadania z testowania,
• szablon wzorcowego rozwiązania,
• przykładowe rozwiązania zadania.
Po przejściu zadania rekomendowane jest przygotowanie własnego rozwiązania. Da to możliwość spróbowania w praktyce wszystkiego co ważne w teorii i przydatne w codziennej pracy testera. Rozwiązania zadania zostały przygotowane przez adeptów testowania pod opieką mentora.
Przed przeczytaniem tej książki
Rekomenduję poznanie teorii testowania z innych źródeł lub też poznanie jej już w trakcie rozwiązywania zadań.
W książce wykorzystałem rozwiązania przygotowane przez uczestników warsztatów „Praktyka testowania”: Małgorzatę Żak, Kamila Urbańskiego, Bartłomieja Fydrycha i Adriana Burczego. Pamiętając, że te opracowania były tworzone na początku ich testerskiego rozwoju, trzeba docenić ich za starania oraz dbałość o jakość.
CZĘSTO ZADAWANE PYTANIA
I POPEŁNIANE BŁĘDY
Ogólne zagadnienia dla całej książki
1. Proszę spróbować tak odpowiadać, aby każda odpowiedź miała strukturę raportu gotowego do przekazania klientowi albo projektowi.
− Raporty tekstowe czyta się ciężko, więc trzeba próbować je uatrakcyjniać, stosując na przykład formę tabelaryczną, dodając zrzuty ekranów z opisem tekstowym, dodając strzałkę wskazującą defekt itp.
− Raport powinien mieć czytelną strukturę – pomocne mogą być nagłówki i sekcje, które pokazują, jak są zaadresowane poszczególne polecenia zadania.
2. Proszę dbać o jakość języka i wystrzegać się błędów. Wszyscy mamy z tym problem, ale w pracy jest ważne, aby nie popełniać prostych błędów, szczególnie takich, których nie wychwyci autokorekta, na przykład „po przez” zamiast „poprzez” czy „było by” zamiast „byłoby”.
3. Proszę też dbać o dobrą składnię, co zwykle sprowadza się do „pisz prosto”. Unikaj długich zdań, wielokrotnie złożonych czy nawiasów większych niż treść zdania.
4. Raporty testerskie powinny być możliwie jak najbardziej pozbawione emocji i obiektywne. Jest to szczególnie trudne na przykład w przypadku testowania użyteczności, które jest mocno subiektywne.
5. Stwierdzenia typu „nie podoba mi się” mogą być postrzegane jako kontrowersyjne i konfrontacyjne. Proszę pamiętać, że to nie tester zamawia oprogramowanie, a programista może po prostu powiedzieć –
„ma się podobać klientowi”. Dodatkowe akcentowanie subiektywnych opinii jest zachętą do polemiki – na przykład zamiast „bardzo dokuczliwe” wystarczy napisać „dokuczliwe”. Lepszą formą jest próba poczucia się użytkownikiem i wypowiadania się w jego imieniu, na przykład „użytkownikom może się nie podobać” lub „użytkownicy mogą to uznać za dokuczliwe”. Nie zmienia to faktu, że jest to ciągle pewna opinia, ale jej forma zachęca do rozważenia, czego potrzebuje nasz końcowy odbiorca.
6. Skąd mam wiedzieć, czy to co znalazłem, jest defektem, czy nie?
To bardzo ważny temat dla całej książki. Jeśli jesteśmy przekonani, że coś jest defektem, musimy go zaraportować, a potem często również bronić przed zamknięciem bez rozwiązania. Tester powinien być przekonany, że to, co znalazł jest defektem i musi znaleźć dowody na to, że ma rację. Podstawową informację o zachowaniu oprogramowania daje specyfikacja wymagań. W wielu przypadkach trzeba sięgać do innych źródeł, jak np. zachowanie podobnych aplikacji czy standardów wskazujących, jak w danych okolicznościach powinno zareagować oprogramowanie. Dobry tester musi wskazać źródła, które potwierdzają tezę o problemie. Jeśli takich nie ma, można powołać się na swoje doświadczenie (jeśli się je ma).
7. W pracy często posługujemy się różnego rodzaju analizatorami, które zwracają nam informacje na wysokim poziomie ogólności, na przykład:
– „wydajność aplikacji to 20/100”,
– „aplikacja jest niebezpieczna”,
– „użyteczność strony jest na poziomie – słaba”. Sama informacja z takiego narzędzia nie jest podstawą do stworzenia raportu defektu. Kroki reprodukcji nie mogą się sprowadzać do „uruchom analizator i sprawdź negatywny wynik”. Jest to tylko wstęp do poważniejszej analizy, która może nam pokazać prawdziwe problemy. Przykładowo, czas ładowania się strony może zależeć od wielu czynników, jak na przykład brak zapisu danych do pamięci podręcznej (ang. cache ) czy brak kompresji obrazów. Dobry raport problemów powinien zawierać szczegóły wyników pracy analizatora.
8. Powielanie zbędnych informacji w raporcie często zamazuje jego obraz. Dodanie nadmiarowych elementów lub długich opisów niewiele wnosi. Co więcej, może generować dodatkowe pytania.
9. Stosowanie metody kopiuj-wklej zawsze będzie generowało dużo treści, należy jednak zastanowić się nad jej wartością. Raporty muszą być tworzone inteligentnie, a to znaczy, że nie mogą być ani zbyt długie, ani zbyt krótkie. Szukamy w nich skrótów i uproszczeń. Często jednak lepsza jest jedna rozbudowana tabelka niż dziesięć, do których trzeba przewijać strony, aby zestawić sobie dane.
10. Czasami możecie nie znać odpowiedzi na pytanie postawione w tej książce. Wtedy nie bójcie się poprosić o pomoc, przyznając, że nie macie wiedzy lub umiejętności, aby rozwiązać dane zadanie. Pomocą mogą służyć fora lub bardziej doświadczeni testerzy.
11. W raportach należy unikać kolokwializmów i sformułowań potocznych. Ich pojawienie się może obniżać ocenę profesjonalizmu autora.
12. W raportach należy unikać rozbudowanych historii, narracji i kwiecistych opisów. Język raportu musi być prosty, zwięzły.
13. Obszar testowania nie jest zbyt ustandaryzowany i definicje nie będą miały większego znaczenia, jeśli tylko nie będziemy nadpisywać powszechnie przyjętych reguł. Przykładowo – „scenariusz testowy” prawie w każdym źródle ma trochę inną definicję. Są jednak miejsca, gdzie nie warto nadpisywać przyjętego nazewnictwa – „test negatywny” nie oznacza przypadku testowego zakończonego niepowodzeniem, a użycie w testach danych, które powinny zostać odrzucone lub nie powinny być w aplikacji przetworzone.
2. ZNAJDOWANIE ODPOWIEDZI I ANALIZA
INFORMACJI
Wyszukiwanie i analiza informacji o testowanym oprogramowaniu, czyli o najważniejszej umiejętności testera oprogramowania
I. Krótkie wprowadzenie do teorii
Informacja o testowanym oprogramowaniu rzadko jest łatwo dostępna. Jej znalezienie i przetworzenie do swoich potrzeb jest bardzo ważną umiejętnością, którą powinien mieć każdy dobry tester. Aby móc testować oprogramowanie, musimy wiedzieć, jaki jest jego cel, otoczenie (kontekst) i potrafić zdefiniować, jak powinno działać poprawnie. Od tych informacji bowiem zależy, czy i jak oprogramowanie zostanie przetestowane. Od tego w głównej mierze będzie również zależeć, czy testy zostaną przeprowadzone we właściwy sposób i czy klient otrzyma to, czego oczekuje. Najprościej jest odnaleźć dokumentację opisującą testowane oprogramowanie, która powinna zawierać informacje o funkcjonalności danej aplikacji. Dokumentacja może mieć różne formy:
• dokument Word lub PDF;
• treść zamieszczona na stronie internetowej;
• baza zgłoszeń i wymagań w systemie raportowania błędów, na przykład Jira;
• for um związane z aplikacją;
• publikacje prasowe o aplikacji.
Specyfikacja często nie nadąża za zmieniającym się oprogramowaniem. Pewne jego funkcjonalności są odrzucane, a nowe dodawane i, niestety, nie jest to odzwierciedlone w dokumentacji.
2. Znajdowanie odpowiedzi i analiza informacji
Równie często zdarza się, że wymagania nie zostają nigdzie utrwalone. W takim przypadku musimy się zdać na własną intuicję, logikę i ogólnie przyjęte dobre praktyki. Jeśli to możliwe, możemy spróbować porozumieć się z twórcami oprogramowania lub z osobą dobrze znającą aplikację i zdobyć od nich możliwie dużo szczegółowych informacji odnośnie do działania aplik acji. Możemy również szukać podobnych aplikacji i ich działanie spróbować odnieść do aplikacji przez nas testowanej.
II. Rekomendowane źródła
Sylabus ISTQB poziomu podstawowego (PL)
http://edu.ittraining.pl/material/Sylabus-ISTQB-Poziomu-Podstawowego-PL
Zawód tester. Od decyzji do zdobycia doświadczenia
https://ksiegarnia.pwn.pl/Zawod-tester.-Od-decyzji-do-zdobycia-doswiadczenia,743423772,p.html
Dodatkowe
Analiza wymagań – FURPS
http://testerzy.pl/baza-wiedzy/analiza-wymagan-furps
Wymaganie
https://pl.wikipedia.org/wiki/Wymaganie_(in%C5%BCynieria)
III. Zadanie
Masz już oprogramowanie do testów. Czas więc na kolejne zadanie.
1. Wyszukaj i przeanalizuj wszystkie informacje dostępne o oprogramowaniu.
• Opisz, co udało Ci się dowiedzieć, jakie informacje przydatne do procesu testowania udało Ci się uzyskać.
• Zest aw źródła i dostępne informacje w czytelnym raporcie.
• Napisz w kilku zdaniach, w jaki sposób chcesz użyć znalezionych informacji i wniosków wyciągniętych z analizy.
VI. Odpowiedzi. Przykłady
2. Uruchomienie testów i zaraportowanie wyników
Produkt z serwisu Allegro, dla którego przeprowadzane są testy z podziałem na klasy równoważności, analiza wartości brzegowych oraz analiza dziedzinowa
A. Analiza wartości brzegowych
Przeprowadzony test
Sprawdzenie poprawności działania dodawania produktów do koszyka w serwisie Allegro dla produktu https://allegro.pl/lenovo-thinkpad-11e-n2930-4x2-16ghz-4gb320gb-win8-i7624205331.html dla wartości brzegowych przedziału
Kroki reprodukcji
Sprawdzam, jak strona reaguje, jakie są efekty. Wpisuję wartości: 0, 1, 317 i 318 w polu dodawania produktu do koszyka.
ID_klasyPrzedział klasy
Oczekiwany wynik testu
1 1 >nie można wpisać wartości, pojawia się komunikat o błędzie
21– 317można dodać produkt do koszyka
3> 317nie można wpisać wartości, pojawia się komunikat o błędzie
Wyniki
Rezultaty są przedstawione w poniższej tabeli uwzględniającej ilość produktów w koszyku
Liczba sztuk
0 1 317 318
Liczba sztuk
Podaj min. 1, maks. 317
Liczba sztuk
Liczba sztuk
Podaj min. 1, maks. 317 z 317 sztuk z 317 sztuk z 317 sztuk z 317 sztuk –|+ – 31| + –1+ – 317 +
Dla każdej klasy wyniki testu zgadzają się z oczekiwanymi rezultatami. Dla klasy z wartościami 1–317 dodawanie do koszyka działa poprawnie. Natomiast dla obu klas wychodzących poza zakres (klasa 1 > i klasa > 317 nie da się wpisać tych wartości, poza tym pojawia się komunikat o błędzie. Dla klasy poprawnej 1–317 znikają ikony minusa i plusa, które informują o granicy przedziału.
B. Klasy równoważności
Przeprowadzony test
Sprawdzenie poprawności działania dodawania produktów do koszyka w serwisie
Allegro dla produktu https://allegro.pl/lenovo-thinkpad-11e-n2930-4x2-16ghz-4gb320gb-win8-i7624205331.html dla wartości znajdujących się w 3 różnych klasach równoważności.
Kroki reprodukcji
Zakres możliwych ilości produktu dzielę na 3 klasy równoważności. Dla każdej z nich sprawdzam po dwie wartości.
ID_klasyPrzedział klasyBadana wartośćOczekiwany wynik testu 11–10025 i 75można dodać produkt do koszyka 2101–200101 i 155można dodać produkt do koszyka 3201–317222 i 290można dodać produkt do koszyka
Wyniki
Dla każdej badanej wartości opcja dodawania towarów do koszyka działa poprawnie; brakuje defektów dla tej opcji.
Klasa równoważności jest to zbiór danych używanych do przeprowadzenia testu. Wykonanie testu z użyciem kilku elementów zbioru powoduje uznanie całej klasy za poprawną.
C. Analiza kombinatoryjna
Przeprowadzony test
Przetestowanie poprawności wyświetlania przefiltrowanych wyników w serwisie Allegro dla hasła „laptop”, dla 3 wybranych charakterystyk.
Kroki reprodukcji
Używając kryterium Base Choice, określam, na podstawie liczby wyników filtrowania, jedną kombinację charakterystyk jako podstawowy element pokrycia, a kolejne buduję, wymieniając tylko jeden element na wszystkie pozostałe wartości. Po wyborze kolejnych charakterystyk sprawdzam poprawność wyświetlania wyników wyszukiwania.
Przypadek testowy Rodzaj karty graficznej Typ napędu Typ laptopaOczekiwane wyjście
1grafika zintegrowana DVD standardowydziała bez błędów
2grafika dedykowana DVD standardowydziała bez błędów
3grafika zintegrowanabrakstandardowydziała bez błędów
4grafika zintegrowanaBlue-raystandardowydziała bez błędów
5grafika zintegrowana DVD ultrabookdziała bez błędów
6grafika zintegrowana DVD 2 w 1działa bez błędów
7grafika zintegrowana DVD wzmocnionydziała bez błędów
Wyniki
Elementy należące do bloku bazowego (grafika zintegrowana, DVD, standardowy) zostały wypisane czcionką pogrubioną. Są one testowane bardzo często. Każdy z pozostałych elementów wszystkich wejść występuje tylko w jednym elemencie pokrycia. Przypadki testowe odpowiadają elementom pokrycia. Każdy przypadek pokrywa jeden element pokrycia. Dla wszystkich badanych kombinacji wyświetlanie wyników było prawidłowe, nie pojawiły się żadne błędy.