12 – Narzędzia i automatyzacja testów

Agenda

Narzędzia wspomagające testowanie
Wstęp do automatyzacji testów manualnych

Narzędzia wspomagające testowanie

Czynności testowe, w których zastosowanie znają narzędzia wspierające testowanie:

Narzędzia do zarządzania defektami
Generacja danych testowych
Zarządzanie – wymaganiami, procedurami, przypadkami testowymi, danymi testowymi, wynikami testów
Komunikacja
Excel ☺
Aplikacje do screenshotów i nagrywania pulpitu
Zbieranie i przetwarzanie logów
Tworzenie raportów z egzekucji oraz monitorowanie przebiegu
Narzędzia wspierające tworzenie kodu i automatyzację

Cele wykorzystania narzędzi wspomagających testowanie:

Automatyzacja powtarzalnych czynności lub zadań, które angażuje dużo zasobów, dzięki czemu możemy zwiększyć efektywność – testy regresji
Zwiększanie spójności procesu testowego i odtwarzalności defektów, co wpływa na podniesienie jakości testów
Automatyzacja czynności, których nie można wykonać manualnie lub są trudne do wykonania – testy wydajnościowe
Pomoc dla czynności manualnych i podniesienie wydajności, co wpływa pozytywnie na wzrost niezawodności testowania

Typy Narzędzi Testowych

Narzędzia wspierające testowanie można podzielić pod względem obszarów, które będą wspierać

Narzędzia wspierające zarządzanie testowaniem i testaliami
Zarządzanie testami i cyklem życia aplikacji
Zarządzanie wymaganiami
Zarządzanie defektami
Zarządzanie konfiguracją
Ciągła integracja

Narzędzia wspomagające przy testowaniu statycznym
Oprogramowanie do przeprowadzania analizy statycznej

Narzędzia wspierające przy projektowaniu i implementacji testów
Narzędzia do testowania opartego na modelu
Generowanie danych testowych

Narzędzia wspomagające przy wykonaniu i zbioru logów z przebiegu testów
Wykonywanie testów (testy regresji)
Wykonujące pomiar pokrycia kodu lub wymagań
Jarzma testowe

Narzędzia wspierające przy pomiarze wydajności i analizy dynamicznej
Testy wydajnościowe

Narzędzia wspierające wyspecjalizowane czynności w procesie testowym

Wdrożenie nowych narzędzi do organizacji

Wybór narzędzia wspomagającego testowanie oprogramowanie powinno się wziąć pod uwagę czynniki tj.:

Dojrzałość organizacji
Możliwość doskonalenia testów dzięki narzędziom
Kompatybilność nowych narzędzi z używanymi aktualnie w organizacji
Określenie wad i zalet narzędzia
PoC – proof of concept
Ocena dostawcy lub obsługi narzędzi open source
Określenie potrzeb szkoleniowych

Na sukces wdrożenia narzędzia mają wpływ:

Propagowanie użycia narzędzia i wdrażanie w organizacji
Określenie standardów odnośnie używania narzędzia
Zapewnienie wsparcia i szkoleń
Dostosowanie procesów uwzględniając nowe narzędzie
Monitorowanie i obserwacja wpływu narzędzia na organizację

Źródło do materiałów: SJSI Sylabus ISTQB FL

Automatyzacja Testów:

Agenda

Testowanie manualne a automatyczne
Jakie testy automatyzujemy
Kiedy automatyzujemy testy
Opłacalność testów automatycznych
Demo Selenium IDE

Jaka jest różnica między testami manualnymi a automatycznymi?

Testowanie manualne polega na wcieleniu się w aktora – użytkownika końcowego i testowaniu oprogramowania w celu wyszukania błędów.

Testowanie automatyczne polega na użyciu dedykowanego oprogramowania, które wykona zaprojektowane i zaimplementowane przypadki testowe i porówna wynik z oczekiwanym rezultatem testów.

Co automatyzujemy?

Automatyzacji można poddać wszystkie poziomy i typy testów.

Najczęściej automatyzowane są:

Testy Jednostkowe
Testy Mikroserwisów
Testy wydajnościowe
Testy UI (Interfejsu użytkownika)

Piramida Testów jest graficzną reprezentacją relacji między ilością testów a poziomem testów. U podstawy zaprezentowane są testy modułowe, które są najliczniejsze i stanowią siatkę bezpieczeństwa, aby błędy nie przedostawały się na wyższe poziomy testów.

Testy Jednostkowe

Testy Jednostkowe zgodnie z piramidą testów są najliczniejszą grupą testów
Ze względu na ich ilość i pracochłonność są idealnym kandydatem do testów automatycznych.
Ten rodzaj testów jest głównie wykonywany przez Developerów
Dobrze napisane testy jednostkowe i wysokie pokrycie minimalizuje ryzyko na wystąpienie defektów w późniejszych etapach testów
Gdy Test jednostkowy nie zakończył się wynikiem pozytywnym Developer dokonuje poprawek w kodzie by usunąć defekt

Testy jednostkowe powodują wzrost kosztu fazy developmentu jednakże wpływa pozytywnie na obniżenie kosztów wykrycia awarii na późniejszych etapach testów.

Testy Mikroserwisów

Testy Mikroserwisów – czyli mikrousług najczęściej obejmujących jeden obszar biznesu
Automatyzacja testów komunikacji między mikroserwisami i wydajnością tej komunikacji
Są to głównie testy integracyjne i wydajnościowe

Testy Interfejsu Graficznego

Automatyczne testy UI mają na celu odciążenie testerów manualnych w testach funkcjonalnych zwłaszcza w przypadku testów powtarzalnych (testy regresji)
Narzędzie użyte w testach symuluje zachowania testera i porównuje z oczekiwanym wynikiem

Może być realizowana na dwa sposoby:

Narzędzie nagrywające ruchy testera
nie wymaga wiedzy programistycznej
łatwe i szybkie tworzenie testów
często w formie wtyczek do przeglądarek
dużą wadą jest trudność utrzymania tego rodzaju testów
Narzędza współpracujące z językami programowania w celu interakcji z UI
Łatwe w utrzymaniu
Wymagają wiedzy programistycznej
Możliwość ponownego użycia kodu

Kiedy automatyzujemy?

Gdy testy są powtarzalne – testy regresji
Gdy wdrożone jest Continuous Integration
Projekt długodystansowy
Testy, których nie jesteśmy w stanie wykonać manualnie

Opłacalność automatyzacji testów

Kiedy opłacają się testy manualne a kiedy automatyczne?

Testy manualne odgrywają znaczącą rolę mimo rosnącej popularności testów automatycznych
Testy manualne wykonywane są w projektach krótkich
Testowanie eksploracyjne i akceptacyjne z natury musi być przeprowadzone manualnie
Testy automatyczne nie wymagają obecności testera i nie muszą być wykonywane w godzinach pracy
Przygotowanie testów automatycznych jest czasochłonne i kosztowne
Testy automatyczne wymagają utrzymania

Może okazać się przydatne w pierwszych krokach automatyzacji testów:

Selenium IDE Recorder
Katalon Studio
Taiko/Gauge
Robot Framework

Proces Rozwoju Testów

●  Continuous Testing – Ciągłe Testowanie Oprogramowania
●  TDD – Test – Driven Development
●  BDD – Behaviour – Driven Development
●  DDD – Domain – Driven Design

Co to jest Testowanie Ciągłe?

Testowanie Ciągłe jest procesem wykonywania testów automatycznych jako części procesu wytwarzania oprogramowania w celu uzyskania informacji zwrotnej na temat ryzyka biznesowego związanego z kandydatem (funkcjonalnością) do wdrożenia oprogramowania tak szybko, jak to możliwe.
Ewoluuje i rozszerza zakres/automatyzację testów, aby odpowiedzieć na zwiększoną złożoność i tempo rozwoju i dostarczania nowoczesnych aplikacji.

Proces Rozwoju Testów – Testowanie Ciągłe

Głównym celem testowania ciągłego jest ocena pokrycia ryzyka biznesowego,
Testy Ciągłe zapewniają natychmiastowy wgląd w to, czy kandydat (funkcjonalność) na wydanie jest zbyt ryzykowny, aby przejść przez linię dostaw,
Testowanie Ciągłe tworzy siatkę bezpieczeństwa, która pomaga zespołowi chronić doświadczenie użytkownika w przyspieszonych procesach rozwoju i unikać awarii oprogramowania,
Testowanie Ciągłe zakłada, że testowanie będzie wbudowane w proces rozwoju, a nie dołożone na końcu,
Testowanie Ciągłe jest płynnie zintegrowane z procesem dostarczania oprogramowania i łańcuchem narzędzi Dev/Ops,
Testowanie Ciągłe oczekuje, że stabilne środowisko testowe z ważnymi danymi testowymi będzie dostępne dla każdego przebiegu testu.
Testowanie Ciągłe obejmuje wszystko od „przesunięcia w lewo” (jednostka, komponent, pokrycie…) do „przesunięcia w prawo” (monitorowanie/ APM, Testowanie na Produkcji),
Testowanie Ciągłe polega na wykonywaniu właściwego zestawu testów na właściwym etapie rozwoju oprogramowania – bez tworzenia wąskiego gardła,
Testowanie Ciągłe dostarcza informacji zwrotnych odpowiednich dla każdego etapu procesu dostarczania,
Testowanie Ciągłe ocenia każdą warstwę nowoczesnej architektury na odpowiednim etapie procesu dostarczania oprogramowania.
Testowanie Ciągłe obejmuje testy end-to-end, które realistycznie oceniają doświadczenie użytkownika końcowego na wszystkich warstwach (front-end i back-end),
Testy w ramach Testowania Ciągłego muszą być na tyle szerokie, aby wykryć, kiedy zmiana w aplikacji nieumyślnie wpływa na funkcjonalność, na której użytkownicy polegają,
Ciągłe Testowanie redukuje liczbę fałszywych pozytywów poprzez przedkładanie solidnych, elastycznych, nowoczesnych testów nad kruche skrypty,
Testowanie Ciągłe polega na ciągłym przeglądzie i optymalizacji zestawu testów w celu wyeliminowania redundancji i maksymalizacji pokrycia ryzyka biznesowego.
Ciągłe testowanie jest zmianą.
Agile i Dev/Ops polega na zmianie – transformacji ludzi, procesów i technologii Dev/Ops w celu dostarczenia innowacyjnego oprogramowania tak szybko, jak to możliwe.
Pomimo tych wszystkich zmian, jedna rzecz pozostaje niezmienna: proces testowania oprogramowania. Jedno z ostatnich badań donosi, że 70% organizacji zaadoptowało Agile, ale tylko 30% automatyzuje testowanie.
Inne badanie wykazało, że podczas gdy przyjęcie Agile jest obecnie bliskie 88%, tylko 26% organizacji Agile szeroko zaadoptowało automatyzację testów.

Procesy testowania utknęły w przeszłości, nawet gdy organizacje inwestują dużo czasu i wysiłku w przekształcanie procesów rozwoju, aby sprostać dzisiejszym i przyszłym wymaganiom biznesowym.

Większość starszych narzędzi i procesów testowania oprogramowania nie nadaje się do ciągłego testowania, którego wymagają Agile i Dev/Ops z powodu:

–    niezdolność do szybkiego procedowania zmian,
–    wolny czas realizacji zmian,
–    wysoki poziom utrzymania,
–    niestabilność środowiska testowego.

Proces Rozwoju Testów – TDD

Test – Driven Development (TDD) jest praktyką tworzenia oprogramowania, która skupia się na tworzeniu przypadków testów jednostkowych przed stworzeniem właściwego kodu. Jest to iteracyjne podejście, które łączy programowanie, tworzenie testów jednostkowych i refaktoryzację.

Podejście TDD czerpie swoje korzenie z zasad manifestu Agile i programowania ekstremalnego.
Jest to praktyka strukturyzacji, która umożliwia programistom i testerom uzyskanie zoptymalizowanego kodu, który okaże się odporny w długim okresie.

W TDD programiści zaczynają tworzyć małe przypadki testowe dla każdej funkcji na podstawie ich wstępnego zrozumienia.
Główną intencją tej techniki jest modyfikowanie lub wpisanie nowego kodu tylko wtedy, gdy testy się nie powiodą. Zapobiega to pojawianiu skryptów testowych.

Trzy fazy Test – Driven Development
●   Tworzenie precyzyjnych testów: Programiści tworzą precyzyjne testy jednostkowe, aby zweryfikować funkcjonalność konkretnych funkcji. Upewniają się, że test skompiluje się tak, aby mógł się wykonać. W większości przypadków test jest skazany na niepowodzenie.
●   Poprawianie kodu: Kiedy test zakończy się niepowodzeniem, programiści dokonują minimalnych zmian wymaganych do poprawienia kodu, tak aby mógł on działać z powodzeniem, kiedy zostanie ponownie wykonany.
●   Refaktoryzacja kodu: Kiedy test przebiegnie pomyślnie, należy sprawdzić, czy w kodzie nie ma nadmiarowości lub czy nie ma możliwości optymalizacji kodu w celu zwiększenia ogólnej wydajności.

Zalety TDD:

Sprzyja tworzeniu zoptymalizowanego kodu,
Pomaga programistom lepiej analizować i rozumieć wymagania klienta oraz prosić o wyjaśnienie, gdy nie są one odpowiednio zdefiniowane,
Dodawanie i testowanie nowych funkcjonalności staje się o wiele łatwiejsze na ostatnich etapach rozwoju,
Pokrycie testami w TDD jest znacznie wyższe w porównaniu do konwencjonalnych modeli rozwoju. Dzieje się tak dlatego, że TDD koncentruje się na tworzeniu testów dla każdej funkcjonalności od samego początku.
Zwiększa produktywność dewelopera i prowadzi do rozwoju bazy kodu, która jest elastyczna i łatwa w utrzymaniu.

Proces Rozwoju Testów – BDD

Behaviour – Driven Development jest praktyką testowania, która podąża za ideą specyfikacji przez przykład (np. Test-Driven Development [TDD]). Ideą jest opisanie, jak aplikacja powinna się zachowywać w bardzo prostym języku skoncentrowanym na użytkowniku/biznesie.
Biznesowa perspektywa BDD na zachowanie aplikacji pozwala zespołom na tworzenie żywej dokumentacji, która jest łatwa w utrzymaniu i może być konsumowana przez wszystkich członków zespołu, w tym testerów, programistów i właścicieli produktu.

W BDD testy są tworzone przy użyciu języka Gherkin Given-When-Then:

●  dany (pewien kontekst)
●  kiedy (coś się wydarzy)
●  wtedy (wynik)

BDD jest jedną z technik, którą można wykorzystać do tworzenia testów do zautomatyzowanych testów akceptacyjnych podczas Testowania Ciągłego.
Dzięki testom opartym na BDD uruchamianym podczas procesu Ciągłej Integracji, można dać interesariuszom szybką informację zwrotną na temat tego, czy funkcjonalność jest rzeczywiście zaimplementowana i działa – w języku, który mogą łatwo zrozumieć.

Proces Rozwoju Testów – DDD

Domain – Driven Design jest podejściem do tworzenia oprogramowania, które koncentruje się na programowaniu modelu domeny, który ma bogate zrozumienie procesów i reguł danej domeny.

Zalety DDD:

●  Usprawniona komunikacja – wszechobecny element językowy ułatwia i upraszcza komunikację, szczególnie pomiędzy technicznymi i nie technicznymi członkami zespołu deweloperskiego.
●  Dostosowanie do celów biznesowych – dzięki jasności i spójności w zakresie zamierzonych rezultatów biznesowych produktu cyfrowego, istnieje większe prawdopodobieństwo stworzenia produktu, który odzwierciedla sposób działania firmy.
●  Elastyczność – dzięki warstwowej i modułowej budowie, produkt łatwiej jest aktualizować, modyfikować i modernizować w miarę potrzeb, z mniejszą liczbą niezamierzonych skutków.
●  Koncentracja na użytkowniku – chociaż domena jest bardziej fundamentalna i w pewnym sensie ważniejsza niż doświadczenie użytkownika lub interfejs użytkownika, to jednak dzięki utrzymaniu domeny w centrum procesu projektowania, w rezultacie powstaje produkt, który odpowiada na potrzeby użytkowników, dla których domena jest najbardziej istotna.

● Efektywność – z bliskim zaangażowaniem ekspertów w danej dziedzinie, produkt ma większe szanse na wykonanie zadania, które powinien wykonać, w przeciwieństwie do zadania, które programista mógłby pomyśleć, że powinien lub mógłby wykonać; tj. istnieje mniejsze prawdopodobieństwo, że będzie posiadał funkcje, których nikt nie będzie używał.