Przywództwo w testowaniu: narzędzia wykonywania testów

Automatyzacja testów (wykonywania)

Temat automatyzacji testów (zwykle za pośrednictwem graficznego interfejsu użytkownika) zajmuje wysokie miejsce w agendzie większości testerów i menedżerów testów. Na pierwszy rzut oka narzędzia te wydają się bardzo obiecujące, jednak wiele organizacji chcących zautomatyzować część lub całość testów funkcjonalnych napotyka problemy.

W tym artykule nie będziemy zagłębiać się w szczegóły techniczne, ale omówimy niektóre kwestie istotne dla menedżerów testów i kierowników projektów, którzy muszą przygotować uzasadnienie biznesowe dla automatyzacji. Przyjrzymy się:

• Co zyskujesz, a czego nie zyskujesz dzięki narzędziom do wykonywania testów
• Automatyzacja testów za pomocą graficznego interfejsu użytkownika (GUI)
• Automatyzacja testów interfejsów API i usług
• Testy regresji
• Struktury automatyzacji testów

Ważne jest ustalenie realistycznych oczekiwań dotyczących tego, co automatyzacja może, a czego nie może zrobić, dlatego kilka kolejnych sekcji może wydać się nieco pesymistycznych.

Co zyskujesz, a czego nie zyskujesz dzięki narzędziom do wykonywania testów

Niezależnie od tego, czy testujesz aplikacje desktopowe dla systemu Windows, witryny internetowe czy urządzenia mobilne, zasady automatyzacji testów, a także jej zalety i pułapki, są podobne. Narzędzia zapewniają:

• Niestrudzonego, rzekomo bezbłędnego robota, który na żądanie i tak często, jak sobie tego życzysz, uruchomi dowolne przygotowane przez Ciebie testy.
• Precyzyjne porównanie wyników i/lub rezultatów testów z przygotowanymi oczekiwanymi wynikami, na dowolnym poziomie szczegółowości, który zdecydujesz się zaprogramować w narzędziu.

Nie otrzymujesz natomiast:

• Elastyczności i płynnych reakcji na anomalie, błędy lub wątpliwe zachowanie.
• Wzroku i sposobu myślenia ludzkiego testera, zdolnego do podejmowania decyzji w celu badania, zadawania pytań, eksperymentowania i kwestionowania zachowania testowanego systemu.
• Testów za darmo. Nadal musisz na przykład zaprojektować testy oraz przygotować dane testowe i oczekiwane wyniki.
• Chociaż narzędzia do wykonywania testów oferują szeroki zakres funkcji, często brakuje im zaawansowanych możliwości przechowywania danych. Jeśli szukasz bardziej kompleksowego rozwiązania, możesz zapoznać się z dostępnym najlepszym oprogramowaniem do zarządzania bazami danych.

Przyjrzyjmy się znaczeniu tych korzyści i problemów.

Jeśli jesteś w miarę kompetentnym programistą, łatwo jest zaimplementować proceduralne testy wykonywane przez ludzi jako automatyczne procedury w języku skryptowym narzędzia, aby narzędzie mogło je dokładnie wykonać.

Jeśli środowisko i dane używane przez aplikację testową pozostają spójne, możesz oczekiwać, że testy będą uruchamiać się niezawodnie raz za razem. To właśnie jest oczywistą obietnicą zautomatyzowanego wykonywania testów.

Jednak testy automatyczne nie odwzorowują dokładnie tego, co robią (dobrzy) testerzy podczas testowania.

Test wykonany przez narzędzie NIE jest równoważny temu samemu testowi wykonanemu przez człowieka.

Jeśli test jest zapisany w skrypcie, może wskazywać testerowi, co należy zrobić. Testerzy mogą jednak wyjść poza proste porównanie oczekiwanego wyniku z wynikiem wyświetlanym na ekranie.

Testerzy muszą przejść do miejsca wykonywania testu i zachować czujność na nietypowe zachowanie — reakcję na polecenia, szybkość reakcji, wygląd ekranu oraz zachowanie obiektów, na które wpływa zmieniający się stan aplikacji.

Ludzki tester, obserwując anomalię, może się zatrzymać, odtworzyć wcześniejsze kroki lub dokładniej zbadać aplikację albo dane, zanim stwierdzi, że aplikacja działa poprawnie (lub nie) i zdecyduje, czy kontynuować test zapisany w skrypcie, dostosować dane i skrypt testu, czy postępować zgodnie z pierwotnym planem.

Ludzie są elastyczni, podczas gdy narzędzia wykonują tylko dokładnie to, co zostało im zaprogramowane. W transakcji opartej na ekranie narzędzie wprowadza dane, klika przycisk i sprawdza komunikat lub wyświetlony wynik – i na tym kończy się jego działanie. W przypadku testerów-ludzi otrzymujemy znacznie więcej, co zwykle przyjmujemy za oczywiste. 

W zasadzie można zaprogramować narzędzie tak, aby wykonywało wszystkie kontrole, które człowiek przeprowadza instynktownie – ale trzeba będzie napisać dużo kodu i poświęcić czas na debugowanie testów. Nawet wtedy nie uzyskamy zdolności człowieka do decydowania o tym, co zrobić dalej – zatrzymać się, kontynuować, zmienić test w trakcie jego wykonywania lub dokładniej zbadać anomalię.

Nigdzie nie widać wyraźniej braku elastyczności narzędzi niż w reakcji na utratę synchronizacji skryptu z testowanym systemem. Być może oczekiwany wynik nie jest zgodny, system ulega awarii albo zachowanie interfejsu użytkownika (na przykład zmieniona kolejność pól lub nowe pole) różni się od tego, czego oczekuje skrypt. Co robi narzędzie? Próbuje kontynuować działanie, po czym następuje lawina niepowodzeń skryptu lub awarii. 

Tak, można i należy mieć w skrypcie procedury obsługi nieplanowanych zdarzeń, które przechwytują niepowodzenia testów. Utrata synchronizacji, niezgodności między stanem systemu a danymi testowymi, zmiany kolejności pól, nowe pola lub usunięte pola to sytuacje, które tester może rozpoznać i odpowiednio obsłużyć bez zatrzymywania testowania. Narzędzia nie potrafią tego zrobić bez dużego nakładu pracy programistycznej z naszej strony.

Wykorzystywanie ludzi do wykonywania testów opartych na skryptach ma również wady. Testerzy mogą obsesyjnie przestrzegać skryptu i zapominać o korzystaniu ze swoich umiejętności obserwacyjnych. Mogą przeoczyć oczywiste anomalie, ponieważ skupiają się na postępowaniu zgodnie ze skryptem. To właśnie takie nieoptymalne podejście otrzymujemy w wyniku automatyzacji wykonywania testów.

Ślepe przestrzeganie skryptów testowych jest złym pomysłem w przypadku testerów-ludzi, ale w automatyzacji testów jest najlepszym rozwiązaniem, jakie możemy zastosować.

W tym porównaniu testerów postępujących zgodnie ze skryptami z narzędziami wykonującymi testy nie uwzględniliśmy działań testerów eksploracyjnych. Podejście eksploracyjne daje testerom swobodę badania i testowania w dowolnym miejscu i dowolny sposób. 

Oczywiście narzędzia nie potrafią symulować takiej aktywności. Co ważniejsze, narzędzia nie potrafią określać zakresu, ustalać priorytetów ani modelować funkcjonalności i ryzyka systemu, a następnie odpowiednio projektować testów.

Działania związane z analizą i projektowaniem testów są wymagane niezależnie od tego, czy test jest wykonywany przez człowieka, czy przez narzędzie.

Istnieją dalsze ograniczenia dotyczące możliwości narzędzi do wykonywania testów:

• Narzędzia do wykonywania testów robią dokładnie to, co zostało im zaprogramowane – ani więcej, ani mniej
• Narzędzia zwykle nie wykonują kompilacji i konfiguracji środowiska oraz aplikacji ani ładowania danych testowych
• Narzędzia nie projektują przypadków testowych ani skryptów oraz nie przygotowują danych testowych i oczekiwanych wyników
• Narzędzia nie potrafią podejmować przemyślanych decyzji w przypadku wystąpienia nieoczekiwanych zdarzeń.

Aby zoptymalizować procesy wykonywania testów, ich integracja z solidnym oprogramowaniem do zarządzania testami może zapewnić usprawnione przepływy pracy i rozbudowane raportowanie.

Automatyzacja testów graficznego interfejsu użytkownika (GUI)

Minęło około dwudziestu pięciu lat, odkąd narzędzia do automatyzacji testów GUI pojawiły się na rynku, ale liczba nieudanych wdrożeń narzędzi do testowania GUI nadal jest wysoka. Wynika to głównie z tego, że oczekiwania wobec automatyzacji są zbyt wysokie – a narzędzia używane bez odpowiedniej dyscypliny nigdy ich nie spełnią.

Narzędzia do automatyzacji testów GUI mają opinię łatwych w użyciu jako produkty, ale trudnych w zarządzaniu, gdy testowane aplikacje (a co za tym idzie, skrypty testowe) wymagają zmian. Narzędzia te są bardzo wrażliwe na zmiany w interfejsie użytkownika. Zmiany położenia, kolejności i rozmiaru obiektów ekranowych, a także dodanie lub usunięcie takich obiektów, mogą wpływać na skrypty. Problemy powodują również bardziej techniczne zmiany, takie jak zmiana nazw obiektów ekranowych lub modyfikacja „niewidocznych” osadzonych bibliotek GUI.

Automatyzacja testów GUI działa najlepiej, gdy zachowana jest dyscyplina w zakresie:

• Proces rozwoju oraz zmiany i wydania są starannie zarządzane. Na przykład analizuje się wpływ zmian i informuje o nich testerów. 
• Podejścia do tworzenia skryptów testowych. Doświadczeni inżynierowie automatyzacji testów stosują systematyczne konwencje nazewnictwa, struktury katalogów, modułowe i wielokrotnego użytku komponenty, techniki programowania defensywnego i tak dalej.

Tworzenie skryptów automatyzacji testów to zadanie, które wymaga czegoś więcej niż podstawowych umiejętności programistycznych, a przede wszystkim doświadczenia w automatyzacji i obsłudze używanego narzędzia. W przypadku automatyzacji testów na dużą skalę potrzebne są również umiejętności projektowe. 

Niezależnie od tego, jak dostawcy opisują narzędzia – „bez skryptów”, „możliwe do użycia przez osoby niebędące programistami” lub „użytkownicy również mogą automatyzować” – nadal potrzebne są sposób myślenia programisty, umiejętności projektowe i systematyczne podejście.

Automatyzacja testów API i usług

Jeśli komponenty lub funkcjonalności są wdrażane jako usługi wywoływane przez lekkich klientów lub klientów mobilnych, testowanie będzie wykonywane za pomocą API lub poprzez wywołania usług. Ten tryb testowania realizuje się przy użyciu niestandardowego kodu napisanego przez programistów albo dedykowanych narzędzi do testowania API lub usług. W każdym przypadku zwykle dąży się do automatyzacji testowania w taki czy inny sposób.

Ponieważ interfejs API jest „bliżej” kodu, który ma być testowany, testy mogą być znacznie bardziej skoncentrowane na testowanej funkcjonalności. Z pewnością można pominąć złożoność nawigacji po interfejsie użytkownika oraz samego testowania za jego pośrednictwem. Z tego powodu obowiązuje ogólna zasada:

Jeśli testowaną funkcjonalność (na poziomie kodu lub komponentu) można sprawdzić za pomocą wywołania funkcji, interfejsu API lub wywołania usługi, automatyzacja będzie łatwiejsza — i jest zalecana.

Testowanie za pośrednictwem interfejsu API ma zdecydowane zalety.

• Chociaż trzeba będzie użyć lub napisać kod, same testy będą znacznie łatwiejsze do zastosowania (nie trzeba martwić się interfejsem użytkownika).
• Po oskryptowaniu wywołania API pozostaje jedynie zestawienie zakresu przypadków testowych, które chcesz zastosować. Nie ma ograniczeń co do liczby testów, które możesz przeprowadzić.
• Testy oparte na interfejsie API zwykle wykonują się znacznie szybciej, dzięki czemu ten styl testowania dobrze sprawdza się w podejściach opartych na ciągłym dostarczaniu, w których potok wdrożeniowy jest w dużym stopniu zautomatyzowany i musi szybko reagować.

„Piramida automatyzacji testów” (wyszukiwanie w Google pokaże setki przykładów tej grafiki) została niemal powszechnie przyjęta jako sposób przedstawiania zalecenia, aby działania związane z automatyzacją testów koncentrowały się bardziej na testowaniu przez programistów lub za pośrednictwem interfejsu API niż przez interfejs graficzny użytkownika.

• Stosuj testy interfejsu użytkownika tam, gdzie konieczne jest sprawdzenie przepływu pracy użytkownika, ale w niewielkiej liczbie, ponieważ testy są kosztowne i mogą wykonywać się powoli.
• Stosuj wywołania API lub usług tam, gdzie testowaną funkcjonalność można odizolować i gdzie szybkość oraz łatwość automatyzacji są niezbędne.

Testy regresji

Klasycznym zastosowaniem narzędzi automatyzacji jest wykonywanie testów regresji. Testy te są uruchamiane jednokrotnie i uznawane za dokładne odwzorowanie oczekiwanego działania. Gdy zmieni się testowany kod aplikacji, powiązane biblioteki wielokrotnego użytku lub środowisko testowe, testy te dają pewność, że wymagana funkcjonalność nie została negatywnie zmieniona w wyniku tej modyfikacji.

Możesz wyobrazić sobie testy automatyczne jako formę, w którą dopasowuje się testowany system. Oczywiście testy powinny „zaliczyć” wszystkie kontrole, które przeprowadzono wcześniej. Uruchamiając je ponownie, próbujesz wykazać równoważność funkcjonalną nowej wersji oprogramowania z poprzednią. Należy przestrzegać kilku prostych zasad:

• Po pierwsze, testy i przeprowadzane kontrole należy wybrać tak, aby dały pewność, że nie występują niepożądane zmiany w działaniu. Testy te działają jak „drut wyzwalający”, wykrywający różnice w zachowaniu.
• Gdy naprawiane są błędy lub wprowadzane są inne zmiany w oprogramowaniu, mogą wystąpić przypadki zmienionego (prawidłowo) działania, które napotkane przez testy spowodują niezaliczenie kontroli. Musisz albo wcześniej zmienić testy, albo pozwolić im zakończyć się niepowodzeniem i poprawić je później. Czasami szybciej jest całkowicie usunąć niezaliczone testy i utworzyć od podstaw nowe, które je zastąpią. W każdym razie zmienione testy muszą następnie zostać wykonane do końca i zakończyć się pomyślnie.
• Jeśli testowany system nie jest stabilny, zawiera wiele błędów lub przechodzi rozległe zmiany między wydaniami, utrzymywanie zestawu testów automatycznych może nie być opłacalne. Nawet jeśli funkcjonalność systemu się nie zmienia, interfejs użytkownika może nadal ewoluować — niestabilny interfejs użytkownika również utrudnia utrzymanie automatyzacji. Koszt badania przyczyn niepowodzeń testów i ich utrzymania może przewyższać korzyści z ich stosowania. Rozsądne może być ręczne testowanie mniej stabilnych części systemu do czasu ich ustabilizowania.

Testowanie za pośrednictwem interfejsu użytkownika może być czasami uciążliwe, kosztowne i powolne. Zanim rozpoczniesz automatyzację testów interfejsu graficznego użytkownika, a nawet zanim zautomatyzujesz pojedynczy skrypt, warto rozważyć, czy testowanie kluczowej funkcjonalności nie byłoby łatwiejsze, szybsze i bardziej ekonomiczne za pomocą interfejsu API.

Klasycznym zastosowaniem narzędzi automatyzacji jest wykonywanie testów regresji. Aby mieć pewność, że używasz do tego najbardziej skutecznych narzędzi, zobacz naszą listę najlepszych narzędzi do testowania oprogramowania

Struktury automatyzacji testów

Struktury testowe są istotną częścią każdego udanego procesu testowania automatycznego. Możesz myśleć o nich jako o zestawie wytycznych służących do tworzenia i projektowania przypadków testowych. Ich użycie może zwiększyć szybkość i wydajność zespołu testowego, poprawić dokładność testów, ograniczyć ryzyko oraz zmniejszyć koszty utrzymania testów. Przyjrzyjmy się teraz dwóm z nich.

Omawiając struktury automatyzacji testów, należy koniecznie uwzględnić rolę narzędzi do automatyzacji zapewniania jakości w kształtowaniu skutecznej strategii testowania.

Struktury testów jednostkowych

Struktury testów jednostkowych istnieją od wielu lat i są szeroko wykorzystywane przez programistów do testowania kodu. Testy programistów są zwykle dość lokalne — w końcu zazwyczaj testują pojedynczy komponent, a interfejsy do innych komponentów lub baz danych są symulowane albo zastępowane atrapami. Dlatego chociaż testy jednostkowe wymagają kroków konfiguracji i porządkowania przed rozpoczęciem testów oraz po ich zakończeniu, zadania te zwykle ograniczają się do uruchamiania testów pojedynczego komponentu. Dla każdego komponentu istnieją osobne zestawy testów.

Testy jednostkowe tworzone przez programistów są zazwyczaj objęte kontrolą wersji i zarządzane równolegle z kodem komponentów. Zwykle narzędzia ciągłej integracji pobierają kod źródłowy oraz wszystkie testy jednostkowe i uruchamiają je po każdym zatwierdzeniu nowego kodu i/lub testów. Wszyscy programiści widzą wyniki tych testów, więc niepowodzenie testu w CI staje się bardzo widoczne. Naprawianie nieudanych testów i kodu ma wysoki priorytet w zespołach, które korzystają z CI w ten sposób, dzięki czemu najnowsza wersja systemu cały czas przechodzi wszystkie testy CI.

Struktury automatyzacji testów integracyjnych i systemowych

W ostatnich latach narzędzia do testowania GUI integrowano z narzędziami CI za pomocą zwirtualizowanych urządzeń testowych, środowisk oraz wykonywania poleceń za pośrednictwem interfejsów wiersza poleceń. Wiele organizacji zdołało w pełni zintegrować wykonywanie testów jednostkowych, testów na poziomie API i testów GUI za pośrednictwem usług CI.

Jednak wiele zespołów testowych nadal korzysta z własnych środowisk testowych, niezależnych od środowisk programistycznych lub usług CI. Zespoły te mają tendencję do tworzenia własnych struktur automatyzacji testów, ponieważ narzędzia CI są zbyt mocno ukierunkowane na programistów lub zastrzeżone narzędzia są niewystarczające.

Testy GUI mają tendencję do implementowania testów kompleksowych lub ścieżek użytkownika z wykorzystaniem różnych aplikacji, urządzeń sprzętowych i środowisk. Testy te muszą płynnie konfigurować zintegrowane środowiska testowe oraz przygotowane dane testowe na różnych platformach, co wymaga uprzywilejowanych i złożonych procedur oraz różnorodnych środowisk technicznych do działania. Zdecydowana większość zespołów korzystających z automatyzacji testów GUI tworzy własne, unikatowe, ale skuteczne struktury automatyzacji.

Struktury automatyzacji GUI różnią się poziomem zaawansowania — od narzędzi przypominających narzędzia do testów jednostkowych po złożone i kompleksowe rozwiązania wymagane do zarządzania środowiskami, kompilacjami aplikacji, ogromnymi zbiorami danych testowych, komunikacją i synchronizacją między platformami i środowiskami, a także komunikatami i powiadomieniami dla członków zespołu.

Niektóre zastrzeżone narzędzia są wyposażone w programy narzędziowe lub mechanizmy zarządzające służące do zarządzania, wykonywania i raportowania wyników zautomatyzowanych zestawów testów. Ich wartość jest różna, dlatego wiele organizacji tworzy własne struktury automatyzacji testów, aby rozszerzyć ich funkcjonalność. W ostatnich latach zakres struktur automatyzacji się zwiększył i nie istnieje już jedna prosta definicja, dlatego przyjrzyjmy się teraz temu, co struktury automatyzacji testów mogą zapewnić zespołom programistycznym.

Struktura automatyzacji testów rozszerza funkcjonalność silników wykonywania testów.

Konfiguracja zestawu testów

Struktura integruje testy automatyczne w znaczące kolekcje lub klastry testów. Kolekcje te można konfigurować, dzięki czemu testy mogą być uruchamiane w hierarchii sekwencji, grup lub dowolnych wyborów. Narzędzia te mogą obejmować funkcje sterowania testami danymi przy użyciu przygotowanych tabel danych testowych. Jest to najprostszy rodzaj struktury — popularne narzędzia zwykle oferują jakąś formę konfiguracji zestawu testów.

Konfiguracja i czyszczenie

Struktura obsługuje wszystkie czynności związane z konfiguracją i czyszczeniem pojedynczego testu, kolekcji lub całego zestawu. Konfiguracja może obejmować tworzenie środowisk testowych od podstaw, pełną konfigurację oraz wstępne ładowanie baz testowych i innych źródeł danych od podstaw. Czyszczenie może obejmować usuwanie danych testowych albo resetowanie lub usuwanie częściowych bądź kompletnych środowisk. Struktura może integrować się z narzędziami do orkiestracji potoków i może pozostawać pod ich kontrolą.

Obsługa wyjątków

Niepowodzenie dowolnego testu — niezależnie od tego, czy wystąpi w testowanym systemie, czy jest wynikiem utraty synchronizacji — można obsłużyć w spójny sposób, zgłaszając zdarzenie i zazwyczaj pozwalając pozostałym testom w danej kolekcji kontynuować działanie. Strukturę można zaprogramować tak, aby obsługiwała niepowodzenia kontroli testów, utratę synchronizacji, przekroczenia limitu czasu wykonywania oraz inne wybrane wyniki testów — każdy z wykorzystaniem niestandardowych procedur.

Rejestrowanie i komunikaty

Struktura w spójny sposób rejestruje wykonywanie testów i ich stan we wszystkich kolekcjach testów. Struktura albo wyzwala raporty z narzędzi wykonujących testy, albo zapewnia spójny dziennik raportowania wszystkich czynności związanych z konfiguracją, wykonywaniem i czyszczeniem testów. Struktura może współdziałać z botami ChatOps, aby informować zespół o wyjątkach i umożliwiać członkom zespołu wstrzymywanie, zatrzymywanie, powtarzanie lub ponowne uruchamianie zestawów testów.

Abstrakcja testów z użyciem języka dziedzinowego

Na rynku pojawiły się dwa odrębne rodzaje struktur, które abstrahują kod wykonywania testów do modeli lub tekstu czytelnego dla człowieka albo nietechnicznego:

• Struktury sterowane słowami kluczowymi umożliwiają definiowanie testów za pomocą słów kluczowych. Wywołania funkcji silnika wykonywania są implementowane jako polecenia przypominające język angielski, zawierające symbole zastępcze dla parametrów lub danych. Moduły definiowane przez użytkownika i przeznaczone do ponownego użycia można definiować i wywoływać za pomocą poleceń w postaci zwykłego tekstu w ten sam sposób. Istnieją struktury dla wszelkiego rodzaju interfejsów, w tym GUI, usług, API, interpreterów wiersza poleceń i innych. Skrypty mogą testować funkcjonalność na różnych platformach systemowych i urządzeniach.
• Struktury programowania sterowanego zachowaniem (BDD) umożliwiają rejestrowanie opowieści i scenariuszy (przykładów) opisujących zachowanie funkcji za pomocą języka dziedzinowego (DSL). Najpopularniejszym językiem jest tak zwany Gherkin, który wykorzystuje strukturę językową „given … when … then …” do rejestrowania przykładów. Konstrukcje „given/when/then” skutecznie reprezentują warunki wstępne, kroki i warunki końcowe przypadków testowych. Narzędzia BDD przekształcają tekst „given/when/then” w „wywołania kroków” w języku programowania. Programista (lub tester) musi zaimplementować „elementy oprzyrządowania” albo kod umożliwiający wywołania silnika wykonywania testów. W ten sposób język wymagania (opowieść) można bezpośrednio połączyć z kodem wykonywania testu.

Struktury oparte na modelach

W tym przypadku narzędzia umożliwiają utworzenie modelu testowanego systemu. Może on zostać automatycznie utworzony na podstawie strony internetowej, na której narzędzie skanuje kod HTML, wykrywa formularze i pola oraz buduje model, z którego ścieżki prowadzące przez formularze mogą być automatycznie generowane lub wybierane przez testera. Mapy obiektów dla aplikacji mobilnych lub innych inteligentnych urządzeń można również tworzyć ręcznie. Za pomocą ścieżek w mapie obiektów wywołania funkcji silnika wykonywania testów są realizowane w sposób podobny do narzędzi BDD i narzędzi opartych na słowach kluczowych. Zasadniczo testy można tworzyć graficznie, bez użycia kodu. Narzędzia z tego obszaru są stosunkowo nowe i szybko się rozwijają. Należy oczekiwać, że ich wykorzystanie będzie w przyszłości coraz większe.

Zapisz się do newslettera The QA Lead, aby otrzymywać powiadomienia o publikacji nowych części serii. Te wpisy są fragmentami kursu Przywództwo w testowaniu autorstwa Paula, który zdecydowanie polecamy wszystkim, którzy chcą dokładniej zgłębić ten i inne tematy. Jeśli się zdecydujesz, użyj naszego ekskluzywnego kodu kuponu QALEADOFFER, aby otrzymać $60 zniżki od pełnej ceny kursu!

Powiązany artykuł: 10 NAJLEPSZYCH NARZĘDZI DO MONITOROWANIA SERWERÓW INTERNETOWYCH