Testowanie oprogramowania w praktyce. Studium przypadków - ebook

Wprowadzenie Adam Roman, Karolina Zmitrowicz

Niniejsza publikacja jest unikatową pozycją na polskim rynku wydawniczym dotyczącą testowania oprogramowania. Oddajemy do rąk Czytelników zbiór artykułów pisanych przez praktyków dla praktyków. Każdy autor opisuje swoje własne doświadczenia w pracy testera, kierownika testów czy inżyniera jakości. Teksty dotyczą wielu bardzo różnorodnych obszarów zarządzania jakością, takich jak:

• automatyzacja,

• testowanie urządzeń mobilnych,

• testowanie wydajnościowe,

• testy w firmie start-upowej,

• zarządzanie testowaniem,

• aspekty miękkie pracy testera,

• wykorzystanie sztucznej inteligencji.

Artykuły zostały napisane przez osoby o bardzo zróżnicowanej praktyce zawodowej, wykształceniu, pełnionych funkcjach oraz zakresie odpowiedzialności. Opisują doświadczenia związane z testowaniem bardzo odmiennych projektów. Każdy z autorów przedstawia problem, przed jakim stanął w pewnym momencie swojej kariery zawodowej, stara się przybliżyć Czytelnikowi swój sposób jego rozwiązania. Przy okazji – w myśl zasady: „tylko ten się nie myli, kto nic nie robi” – autorzy nie wstydzą się opowiadać o swoich porażkach, kłopotach i wszelkiego rodzaju problemach, jakie po drodze napotkali.

Gdyby te osoby pracowały razem, dzięki synergii byłyby w stanie rozwiązać swoje problemy szybciej i efektywniej. Wspólna praca nie była jednak możliwa, dlatego właśnie proponujemy Państwu tę książkę – niech wiedza, doświadczenie oraz błędy popełnione przez Autorów będą pożyteczną i cenną lekcją, mamy nadzieję, że również przydatną w pracy Czytelników.

Chcielibyśmy bardzo serdecznie podziękować wszystkim Autorom za przygotowanie materiałów do niniejszej publikacji, a także Wydawnictwu PWN, zwłaszcza red. Łukaszowi Łopuszańskiemu, który wyszedł z inicjatywą stworzenia tej książki, a nam zaproponował jej zredagowanie.

Karolina Zmitrowicz

Adam Roman1. Automatyzacja testów Natalia Krawczyk

1.1. Opis przypadku

W obecnej firmie, w zespole, który liczy 10 programistów i 2 testerów, pracuję dla klienta ze Skandynawii. Pełnię funkcję zarówno starszego testera, jak i często test managera. Zajmuję się testami manualnymi, automatycznymi, konfiguracją środowisk deweloperskich, testowych oraz konfiguracją procesów ciągłej integracji. Po stronie klienta są jedynie menedżerowie projektów. Klient ten posiada kilku partnerów biznesowych, dla których dostarcza oprogramowanie. Jednym z klientów jest firma mająca hurtownię internetową. Otrzymaliśmy zlecenie naprawy istniejących błędów oraz utrzymywania aplikacji webowej będącej ich sklepem internetowym, który działa w trzech krajach. Aplikacja jest oparta o CMS Webnodes oraz korzysta z zewnętrznego SOAP API, które dostarcza informacje o użytkownikach, klientach, ich zniżkach, zamówieniach oraz o samych produktach. Program został napisany w technologii .Net.

Wygląda to na dosyć typowy, „normalny” projekt informatyczny będący w fazie utrzymania. Niestety, szybko okazało się, że nie będzie łatwo. Natknęliśmy się na szereg problemów.

Firma, która tworzyła sam system, nie wykazała się dobrymi praktykami – nazewnictwo zastosowane w kodzie nie było napisane w języku angielskim, nie zastosowano żadnych prawidłowych wzorców. Kod aplikacji śmiało można było określić mianem „spaghetti code” – niewielka zmiana w kodzie powodowała nieprzewidywalne skutki. Do tego należy dodać, że nie dostaliśmy żadnej dokumentacji informującej nas o tym, jak powinien działać system, mogliśmy jedynie polegać na wiedzy czerpanej z kodu źródłowego.

Nie był to niestety koniec problemów – budżet na testowanie był bardzo ograniczony, a czasem nawet go nie było.

Początkowo to deweloperzy musieli dbać o jakość w projekcie. Jak wiadomo, testy wykonywane przez dewelopera są na najniższym poziomie niezależności testów, deweloper nigdy nie podejdzie tak krytycznie do swojego kodu jak niezależny tester.

Brak specyfikacji oraz bezpośredniego kontaktu z końcowym klientem był chyba najtrudniejszym problemem w tym projekcie. Często dowiadywaliśmy się o jakiejś funkcji poprzez nieświadome jej zepsucie. Nie mieliśmy na początku bezpośredniego kontaktu z końcowym klientem. Aby uzyskać odpowiedź na nasze pytanie, musieliśmy je przesłać do naszego klienta, następnie on je tłumaczył na język norweski i wysyłał zapytanie do klienta końcowego. Zdarzało się, że na odpowiedź czekaliśmy tydzień, a nawet dłużej. Próbowaliśmy ten problem rozwiązać poprzez utworzenie wspólnego czatu w systemie do komunikacji Slack, ale niestety nie skutkowało to szybszą komunikacją. Zyskaliśmy jedynie możliwość bezpośredniego kontaktu z klientem, który niestety odpisywał nam z dużym opóźnieniem.

W przypadku wdrożenia rozległych zmian bądź zmian w zakresie krytycznych funkcjonalności udawało nam się uzyskać kilka dodatkowych godzin na testy regresji. Niestety, bez pełnej dokumentacji i wiedzy na temat systemu testy te nie zawsze znajdywały wprowadzone błędy. W tym celu przygotowałam prostą listę kontrolną (ang. checklist) obejmującą podstawowe akcje, jakie należało przetestować przed wdrożeniem nowej wersji na środowisko produkcyjne.

Podsumowując, w projekcie było kilka problemów do rozwiązania:

• brak dokumentacji,

• brak procesu testowego,

• złej jakości kod źródłowy,

• ograniczona komunikacja z klientem.

1.2. Rozwiązanie problemu

Nie będę opisywać tutaj, jak deweloperzy poradzili sobie z naprawą kodu i jego refaktoryzacją. Chciałabym opowiedzieć głównie o problemie związanym z testowaniem aplikacji.

Czasami udawało nam się uzyskać dodatkowy budżet na testowanie, np. aby sprawdzić, jak aplikacja działa na różnych przeglądarkach, jednak mieliśmy poczucie, że nie robimy tego tak, jak należy. Brakowało nam dokumentacji, do której moglibyśmy się odnieść, testów automatycznych, które wspierały testowanie manualne, ogólnego procesu opisującego, jak powinniśmy postępować w przypadku każdego nowego zadania, aby utrzymać jak najwyższą jakość produktu. Bardzo często mówiliśmy o tym naszemu klientowi na spotkaniach statusowych. Pewnego dnia, gdy okazało się, że mam trochę luźniejszy czas w innych projektach u tego klienta, zostałam poproszona o przygotowanie propozycji: jak miałby wyglądać idealny proces testowy dla tego projektu, w jaki sposób chciałabym wdrożyć w nim testy automatyczne, aby skrócić czas testowania?

Początkowo przygotowałam ogólną odpowiedź, która zawierała listę rzeczy, które powinny być przygotowane (dokumentacja testowa, testy automatyczne), jak i pogląd na ogólny proces testowy dla tego projektu.

Jako warunki wstępne do wprowadzenia dobrego procesu testowego postawiłam:

• utworzenie dokumentacji testowej,

• wprowadzenie testów automatycznych UI na poziomie testów akceptacyjnych (otrzymaliśmy zgodę na 10 testów),

• zdefiniowanie i ustawienie procesu ciągłej integracji w Team City.

Następnie zdefiniowałam proces testowy (rys. 1.1) uwzględniający testowanie jednej funkcjonalności, jak i testowanie regresji przed wdrożeniem nowej wersji systemu na środowisko produkcyjne.

W przypadku każdej nowej funkcjonalności proces uwzględniał:

• analizę zadania w celu wyceny czasochłonności czynności testowych,

• dodanie nowej funkcjonalności do dokumentacji testowej bądź wprowadzenie zmian w istniejącej,

• napisanie testów automatycznych (o ile ma to w danym przypadku sens na warstwie UI),

• testowanie manualne z uwzględnieniem napisanej dokumentacji oraz testy eksploracyjne,

• zaraportowanie znalezionych defektów do Jiry,

• retesty (o ile znaleziono, zaraportowano i poprawiono nowe defekty).

Testowanie przed wdrożeniem nowej wersji na produkcję miało uwzględniać:

• uruchomienie testów automatycznych i analizę ich wyników,

• testy manualne na podstawie dokumentacji testowej (tylko funkcjonalności nieuwzględnione w testach automatycznych).

Szybko okazało się, że taki opis nie był wystarczający. Warunki wstępne zostały bardzo szczegółowo spisane i przedstawione końcowemu klientowi jako propozycja procesu testowego, dzięki któremu łatwiej będzie nam kontrolować jakość projektu. Dokument z propozycją zawierał szczegółowy opis składników dokumentacji testowej (wraz z kilkoma przykładami) oraz opis sposobu tworzenia testów automatycznych. Dodatkowym utrudnieniem wymagającym analizy i rozwiązania było niestabilne API. Pisząc testy automatyczne muszę podać w asercji oczekiwane rezultaty, takie jak: cena produktu, jego dostępność itp. Opierając się na testowym API, nie jesteśmy w stanie tego zrobić. Dzisiaj interfejs programistyczny aplikacji podaje nam cenę X dla produktu Y, ale jutro może nam zwrócić inną. Rozwiązaniem tego jest jego zamockowanie, czyli przygotowanie wcześniej gotowych odpowiedzi z API, zastąpienie API zaślepką, która odpytana zwróci przygotowane wcześniej odpowiedzi. Cała analiza była przeprowadzona przy współpracy z deweloperem, który wspierał mnie swoją wiedzą na temat architektury aplikacji i doświadczeniem. Zaproponowaliśmy 10 scenariuszy testowych, których weryfikacja powinna być według nas zautomatyzowana w pierwszej kolejności (były to scenariusze pokrywające kluczowe funkcjonalności systemu). Tak przygotowany dokument wraz z pełną estymacją został wysłany do końcowego klienta w celu zatwierdzenia. Po kilku dniach oczekiwań dostaliśmy zgodę na wykonanie zaplanowanych działań.

Rysunek 1.1. Zdefiniowany proces testowy

Rozpoczęłam od przygotowania dokumentacji testowej, która miała być bazą dla całego procesu testowego. Zaproponowana przeze mnie dokumentacja testowa napisana była w programie Microsoft Excel i składała się z 3 części:

1. Listy funkcjonalności – tabeli, na którą składały się kolumny: id funkcjonalności; nazwy modułu, którego dana funkcjonalność dotyczy; opis funkcjonalności zapisanego w postaci User story; link do arkusza, w którym znajdują się scenariusze testowe do danego user story; ilość zdefiniowanych scenariuszy testowych; ilość scenariuszy testowych pokrytych przez testy automatyczne; status testu; link oraz id zgłoszonego błędu w zewnętrznym systemie do zarządzania błędami (tab. 1.1).

2. Arkuszy zawierających dokładny opis funkcjonalności oraz scenariusze testowe do danego user story (wraz z przykładowymi danymi testowymi, statusem każdego scenariusza i ewentualnym linkiem do zgłoszonego błędu w Jirze).

3. Raportu zawierającego listę wszystkich user stories wraz z ich obecnym statusem: Before testing, Under testing, Positive, Negative.

Tabela 1.1. Lista funkcjonalności

Tabela 1.2. Arkusz z opisem funkcjonalności i odpowiadających jej scenariuszy testowych

Następnie zaczęłam pracę nad przygotowaniem testów automatycznych.

Testy automatycznie zostały napisane w języku C#, przy użyciu następujących narzędzi:

• nUnit (wersja 2.6),

• SeleniumWebDriver,

• Chrome WebDriver.

Ponieważ otrzymaliśmy zgodę na napisanie tylko 10 testów, postanowiłam zastosować nietypowe podejście, aby w trakcie tych 10 testów sprawdzić jak najwięcej. Pierwszy pomysł, jaki większości z nas w takiej sytuacji może przyjść do głowy, to zakończenie każdej akcji asercją – sprawdzeniem, czy akcja się wykonała, czy stan aplikacji się zmienił. Przykładowo, po otwarciu przeglądarki i przejściu do danej strony sprawdzilibyśmy asercją, czy tytuł strony jest odpowiedni, następnie po kliknięciu w przycisk zaloguj sprawdzilibyśmy asercją, czy pole do wpisana loginu jest wyświetlone, itp. Jak wiadomo jednak nie jest to najlepsze rozwiązanie: przy pierwszej asercji, która zwróci wynik negatywny (oczekiwany warunek nie zostanie spełniony), test zostanie przerwany, więc jeśli w aplikacji byłby błąd polegający na tym, że po zalogowaniu źle wyświetla się na przykład imię zalogowanego użytkownika (a ten warunek byłby sprawdzany po zalogowaniu), wszystkie napisane testy zakończyłyby się po zalogowaniu do aplikacji. Takim podejściem uzależniamy test sprawdzający jedną funkcję od warunków dotyczących zupełnie innych funkcji systemu. Dlatego zastosowałam trochę inne rozwiązanie. Postanowiłam sprawdzać w każdym teście jedną konkretną operację i weryfikować ją jak największą liczbą asercji.

Zanim opiszę dokładnie, na czym polega powyższa metoda, chciałabym przybliżyć narzędzie nUnit oraz jego możliwości, aby lepiej wytłumaczyć obrane przeze mnie podejście. nUnit jest narzędziem wykorzystywanym do pisania testów jednostkowych w języku programowania C#. Narzędzie to ma adnotacje, które określają, czy dana metoda w klasie jest testem (), czy powinna wykonywać się przed/po każdym teście ( / ), lub czy dana klasa jest zestawem testów (). Standardowo – testy, określane adnotacją , są niezależne od siebie, zawierają przygotowanie do testu, wykonanie samego testu oraz sprawdzenie jego wyniku.

Postanowiłam pozamieniać nieco role adnotacji: testem był cały zestaw testów, a sprawdzenie wykonanej operacji – pojedynczym testem. Wydaje się to na pierwszy rzut oka trochę zagmatwane, postaram się wytłumaczyć to na przykładzie testu sprawdzającego dodanie produktu do koszyka jako „niezalogowany użytkownik”.

Przygotowanie do testu składałoby się wówczas z następujących czynności:

• uruchomienie przeglądarki;

• przejście do adresu testowanej aplikacji;

• przejście do strony produktu, który miałby być dodany do koszyka.

Większość tych akcji umieściłam w metodzie oznaczonej adnotacją SetUpFixture, czyli metodzie, która uruchomi się przed wykonaniem zestawu testów. Jednak tu należy bardzo uważać – jeśli wykonanie jakiejś metody, operacji zawartej w tym miejscu zakończy się wyjątkiem, zestaw testów oraz metoda oznaczona adnotacją nigdy się nie wykonają. Czemu zwracam na to uwagę?

W metodzie wykonującej się po zestawie testów lub po teście przeważnie wyłączamy przeglądarkę, kończymy procesy itp. Jeśli wszystkie nasze testy zostaną przerwane na metodzie SetUpFixture, na stacji roboczej, gdzie uruchamiamy testy, wszystkie uruchomione procesy, np. chrome.exe, pozostaną włączone i będą wymagały ręcznego zakończenia.

Wróćmy do naszego przykładu.

Akcja w tym teście jest tylko jedna – wybranie żądanej liczby egzemplarzy produktu i wciśnięcie przycisku „Dodaj do koszyka”. Wykonanie tej operacji zamieściłam już w metodzie oznaczonej adnotacją , ale sama nazwa metody zaczynała się od przedrostka „T001” – oznaczenia, że ta metoda wykona się jako pierwsza w danym zestawie testów. Nie jest to jakieś specjalne oznaczenie, tylko zwykły ciąg znaków wybrany przeze mnie. Testy w danym zestawie testów domyślnie uruchamianie są w kolejności alfabetycznej.

Kolejnym etapem testu jest sprawdzenie poprawności wykonania się operacji. Załóżmy, że będziemy sprawdzać:

• czy wyświetlił się komunikat o prawidłowym dodaniu produktu do koszyka,

• czy odpowiednio zmieniła się ilość produktów w koszyku wyświetlana w górnej części ekranu,

• czy po przejściu do strony koszyka dodany przez nas produkt się w nim znajduje,

• czy na stronie koszyka sumaryczna ilość dodanych produktów jest prawidłowa,

• czy na stronie koszyka sumaryczna kwota za dodane produkty jest prawidłowa.

Wymieniłam 5 sprawdzeń, więc potrzebujemy 5 asercji. Pierwszą z nich umieszczamy w teście „T001”. Kolejną w teście z przedrostkiem „T002”. W teście „T003” przed asercją jest wykonanie akcji przejścia do strony koszyka. Wykonanie jej jest obarczone ryzykiem, ale jeśli się nie uda, będziemy wiedzieli, że jedna z kluczowych funkcjonalności w systemie nie działa. Kolejne asercje umieszczamy również w osobnych testach.

W taki sposób zaimplementowałam 10 testów sprawdzających kluczowe operacje wykonywane przez użytkowników systemu. Dzięki nim wiedziałam, że nawet jeśli programiści będą zmuszeni wykonać wdrożenie nowej wersji systemu na środowisko produkcyjne bez testów manualnych (tylko na podstawie wyniku testów jednostkowych i napisanych przeze mnie testów automatycznych), podstawowe funkcjonalności na tzw. Money path (szeregu akcji zapewniającej klientowi zysk) będą działać poprawnie.

Równocześnie z implementacją testów automatycznych trwały prace nad przygotowaniem dedykowanego środowiska testowego z namiastką symulującą API. W tym celu użyliśmy programu SoapUI, dzięki któremu mogliśmy zamockować część interfejsu programistycznego aplikacji oraz przygotować odpowiedzi na zapytania. Pracę nad tym zadaniem wykonywał głównie deweloper, do niego należało przygotowanie aplikacji, aby zamiast odpytywać zewnętrzne API na przykład o dane użytkownika, zwracała się do przygotowanych mocków. Moją rolą w tym zadaniu było przygotowanie przykładowych odpowiedzi, które będą zwracane przez zamockowany interfejs programistyczny aplikacji. Do tego celu wykorzystałam przykładowe odpowiedzi z testowego API. Dzięki stałym odpowiedziom mogłam bez problemu zdefiniować oczekiwane rezultaty w asercjach w napisanych testach automatycznych oraz mogłam być pewna, że jeśli na stronie zostanie wyświetlona inna cena produktu niż się spodziewałam, wina będzie leżała po stronie aplikacji, a nie po stronie zewnętrznego API.

Kolejnym etapem było zdefiniowanie i skonfigurowanie nowego projektu w systemie ciągłej integracji (w tym przypadku TeamCity), który by instalował aktualną wersję na dedykowanym środowisku testowym z zamockowanym API i uruchamiał testy. Po wdrożeniu aktualnej wersji aplikacji na dedykowane środowisko testowe uruchamialiśmy procedurę sprawdzającą spójność bazy danych oraz sprawdzaliśmy, czy strona jest już dostępna. Jeśli aplikacja została poprawnie wdrożona, proces był kontynuowany. Jeśli aplikacja wciąż nie odpowiadała, kolejne etapy były pomijane. Dodatkowo, aby nie martwić się o dane pozostałe po teście, wprowadziliśmy również przywracanie bazy danych z momentu sprzed uruchomienia testów.

Rysunek 1.2. Proces testowania w TeamCity

Całościowo proces dla testów w TeamCity wyglądał następująco:

1. Pobierz aktualny kod źródłowy aplikacji z repozytorium.

2. Skompiluj kod.

3. Uruchom testy jednostkowe.

4. Zainstaluj aplikację z testowym plikiem konfiguracyjnym na środowisku testowym.

5. Uruchom procedurę sprawdzającą spójność danych i poczekaj aż się zakończy.

6. Wykonaj test wstępny (sprawdź, czy aplikacja jest gotowa do uruchomienia testów automatycznych).

7. Wykonaj backup bazy danych.

8. Uruchom testy automatyczne.

9. Przywróć backup bazy danych z punktu 7.

Wykonanie całego procesu trwało około 45 minut. Ponieważ nie było potrzeby, żeby uruchamiać te testy po każdej zmianie kodu w repozytorium, ustawiliśmy w TeamCity, aby proces uruchamiał się raz dziennie w nocy. W razie potrzeby uruchamialiśmy go też manualnie na żądanie.

1.3. Podsumowanie działań

Dzięki spełnieniu warunków wstępnych udało nam się wprowadzić ustandaryzowany proces testowy w przypadku każdego nowego zadania. Może on miejscami odbiegać od założeń przyjętych w pierwszym dokumencie opisu procesu, jaki stworzyłam, jednak sprawdza się bardzo dobrze w naszym przypadku. Składa się on obecnie z następujących etapów:

• analizy i estymacji – wykonywany jest wspólnie z deweloperem, podczas którego programista tłumaczy, co będzie zmienione oraz gdzie można spodziewać się błędów regresji, a tester zadaje pytania, analizuje przypadki użycia i zaczyna rozpisywać podstawowe przypadki testowe; wynikiem analizy było oszacowanie, ile godzin potrzeba na wykonanie zadania (zarówno czynności deweloperskich, jak i testerskich);

• projektowania testów – przeprowadzane jest przez testera, podczas którego do dokumentacji testowej dodawane są nowe scenariusze testowe lub modyfikowane już istniejące; po dopisaniu nowych scenariuszy tester przedstawia je deweloperowi w celu ich przeglądu;

• analizy wyników testów automatycznych – często jest wykonywana przez dewelopera, jak i przez testera; jeśli jakiś test zakończył się niepowodzeniem, należało sprawdzić, czy przyczyną był błąd na stronie, czy błąd w kodzie testów automatycznych, czy może problem ze środowiskiem testowym;

• wykonania testów manualnych nowej funkcjonalności – na podstawie napisanej wcześniej dokumentacji testowej;

• implementacji skryptów wykonujących testy automatyczne (o ile dana funkcjonalność tego wymagała);

• raportowania wyników testów;

• ewentualnych retestów;

• testów eksploracyjnych.

Do dziś stosujemy ten proces w przypadku nowych funkcjonalności. Wszystko jest uporządkowane i dobrze przetestowane. Testy automatyczne są bardzo stabilne, szybkie oraz zdarzyło im się parę razy znaleźć błędy regresji. Dodatkowo programiści docenili ten proces – dzięki wnikliwej analizie i rozpisywaniu przypadków testowych wiedzą na co powinni zwrócić uwagę przy dewelopmencie, co sprzyja powstawaniu mniejszej liczby usterek.

Niestety, opracowany przeze mnie proces testowy nie przyjął się w przypadku wdrożenia nowej wersji produktu. Przypomnę, że proces wymagał manualnego przetestowania wszystkich scenariuszy testowych niepokrytych przez testy automatyczne. Przyczyną niepowodzenia były zbyt wysokie koszty wykonania testów manualnych (szacowany był na 2–3 dni). Dlatego sam proces wykonania testów regresji uległ zmianie, składał się z:

• sprawdzenia i analizy wyników testów automatycznych;

• testów eksploracyjnych, obejmujących podstawowe funkcjonalności;

• dodatkowych testów funkcjonalności, które były obarczone największym ryzykiem (jeśli zmiany związane były np. z rejestracją konkretnego typu użytkownika, przeprowadzono testy dla wszystkich scenariuszy testowych związanych z rejestracją użytkownika, logowaniem użytkownika i edycją jego profilu) – o ile udało nam się na takie testy uzyskać zgodę.

1.4. Wnioski, zalecenia, rekomendacje

Wprowadzenie uporządkowanego procesu testowego przyniosło wiele korzyści. Jedną z nich jest zaangażowanie testera od momentu estymacji i analizy. Często, aby dobrze wyestymować daną zmianę, przeprowadzaliśmy analizy, podczas których już rozpisywaliśmy przypadki użycia i przykładowe scenariusze testowe, jakie będą sprawdzane podczas etapu testów danej funkcjonalności. Dzięki temu rzadko zdarzały się błędy we wprowadzanej zmianie – programiści implementując kod, od razu wiedzieli, na co zwrócić uwagę.

Testy automatyczne okazały się być bardzo przydatne, ponieważ wcześniej opracowany proces testowy nie mógł być w pełni wdrożony ze względu na brak środków na jego przeprowadzenie. Jeśli wszystkie testy automatyczne kończyły się sukcesem, mogliśmy stwierdzić, że przynajmniej podstawowe funkcjonalności, takie jak zakup produktów, będą działać prawidłowo. Dzięki temu, że testy używały zamockowanego API, można było na nich zawsze polegać. Praktycznie nie zdarzały się fałszywie negatywne wyniki (było kilka przypadków spowodowanych źle skonfigurowanym środowiskiem testowym).