Jak osiągnąć sukces w automatyzacji testów?

Przedstawione poniżej czynniki sukcesu dotyczą takich projektów automatyzacji testów, które są już realizowane, w związku z czym skupiono się na czynnikach wpływających na długofalowe powodzenie przedsięwzięcia. Nie uwzględniono natomiast czynników wpływających na powodzenie projektów automatyzacji testów znajdujących się w fazie pilotażowej. Poniżej opisano najważniejsze czynniki sukcesu związane z automatyzacją testów:

1. Architektura testów automatycznych - jest bardzo ściśle dopasowana do architektury testowanego oprogramowania. W związku z tym należy jednoznacznie wskazać, które wymagania funkcjonalne i niefunkcjonalne znajdują odzwierciedlenie w tej architekturze — zwykle są to wymagania uznawane za najważniejsze. Architekturę automatyzacji testów często projektuje się pod kątem utrzymywalności, wydajności i łatwości nauki (szczegółowe informacje na temat tych i innych cech niefunkcjonalnych zawiera norma ISO/IEC 25000:2014). W związku z tym wskazane jest zaangażowanie inżynierów oprogramowania, którzy znają architekturę systemu podlegającego testowaniu.
2. Testowalność systemu podlegającego testowaniu (SUT) - system podlegający testowaniu musi być zaprojektowany pod kątem testowalności, w tym możliwości testowania automatycznego. W przypadku testowania przy użyciu GUI może to oznaczać jak największe odseparowanie interakcji i danych realizowanych/przesyłanych za pośrednictwem tego interfejsu od jego aspektów wizualnych. Z kolei w przypadku testowania przy użyciu API może to oznaczać konieczność udostępnienia większej liczby klas lub modułów (bądź CLI) w sposób umożliwiający ich przetestowanie.
   
   W pierwszej kolejności należy zająć się testowalnymi elementami systemu podlegającego testowaniu. Jednym z najważniejszych czynników sukcesu związanych z automatyzacją testów jest zwykle łatwość implementacji automatycznych skryptów testów. Aby osiągnąć ten cel i pomyślnie zaprezentować dowód słuszności koncepcji, inżynier automatyzacji testów musi zidentyfikować moduły lub komponenty systemu podlegającego testowaniu dające się łatwo przetestować z wykorzystaniem automatyzacji i zacząć od nich.
3. Strategia automatyzacji testów - niezbędna jest praktyczna i spójna strategia automatyzacji testów, uwzględniająca kwestie utrzymywalności i spójności systemu podlegającego testowaniu.
   
   Nie zawsze można zastosować strategii automatyzacji testów w ten sam sposób, w odniesieniu do starych i nowych elementów systemu podlegającego testowaniu. Dlatego przy tworzeniu strategii należy wziąć pod uwagę koszty, korzyści i ryzyko związane z jej stosowaniem do różnych obszarów kodu.
   
   Należy również zastanowić się nad przetestowaniem GUI oraz API przy użyciu przypadków testowych dla testów automatycznych w celu sprawdzenia spójności rezultatów.
4. Framework do testów automatycznych - łatwy w użyciu, dobrze udokumentowany i utrzymywalny framework do testów automatycznych (ang. Test Automation Framework) pozwala zapewnić spójne podejście do automatyzacji testów.
   
   Aby stworzyć łatwą w użyciu i w utrzymaniu strukturę do testów automatycznych powinny być uwzględnione następujące zagadnienia:

• Implementacja mechanizmów raportowania: raporty z testów powinny dostarczać informacji na temat jakości systemu podlegającego testowaniu (test zaliczony, niezaliczony, zakończony błędem, niewykonany lub anulowany, informacje statystyczne itd.). Informacje zawarte w raportach powinny umożliwiać zaangażowanym testerom, kierownikom ds. automatyzacji testów, programistom, kierownikom projektu i innym interesariuszom uzyskanie ogólnego obrazu jakości systemu.
• Łatwe diagnozowanie problemów. Poza wykonywaniem testów i rejestrowaniem danych, framework powinien również umożliwiać łatwe diagnozowanie przyczyn niezaliczonych testów. Test może nie zostać zaliczony na skutek:
  • awarii wykrytych w systemie podlegającym testowaniu,
  • awarii wykrytych w rozwiązaniu dla testów automatycznych,
  • problemów związanych z samym testem lub środowiskiem testowym.
• Poświęcenie należytej uwagi środowisku testowemu. Funkcjonowanie narzędzi testowych zależy od spójności środowiska testowego. W przypadku testowania automatycznego konieczne jest stworzenie wydzielonego środowiska testowego, ponieważ brak kontroli nad tym środowiskiem i danymi testowymi może doprowadzić do sytuacji, w której konfiguracja testowa nie spełni wymagań związanych z wykonywaniem testów, a uzyskane rezultaty będą fałszywe.
• Dokumentowanie przypadków testowych dla testów automatycznych. Należy jednoznacznie określić cele automatyzacji testów: które elementy aplikacji mają być testowane i w jakim stopniu, jakie atrybuty (funkcjonalne i niefunkcjonalne) mają być przedmiotem testów itd. Następnie należy w przejrzysty sposób opisać i udokumentować przyjęte założenia.
• Śledzenie testów automatycznych. Framework do testów automatycznych musi umożliwiać inżynierowi automatyzacji testów śledzenie powiązań między poszczególnymi krokami a przypadkami testowymi.
• Łatwość utrzymania. Przypadki testowe dla testów automatycznych powinny być łatwe w utrzymaniu, tak, aby nie pochłaniało ono istotnej części nakładów pracy związanych z automatyzacją testów. Ponadto, nakłady pracy na utrzymanie muszą być proporcjonalne do zakresu zmian wprowadzanych w systemie podlegającym testowaniu, co z kolei oznacza, że przypadki testowe muszą być łatwe do analizowania, modyfikowania i rozszerzania. Inną ważną kwestią jest zapewnienie wysokiego stopnia ponownego wykorzystania testaliów w testach automatycznych, co pozwoli ograniczyć liczbę elementów wymagających zmiany.
• Potrzeba ciągłej aktualizacji testów automatycznych. Jeśli wprowadzenie nowych lub zmiana dotychczasowych wymagań powoduje niezaliczenie pojedynczych testów lub całych zestawów testów, nie należy pomijać niezaliczonych testów, tylko je skorygować.
• Planowanie wdrożenia. Należy zadbać o możliwość łatwego wdrażania, modyfikacji i ponownego wdrażania skryptów testowych.
• Wycofywanie testów w zależności od potrzeb. Należy zadbać o możliwość łatwego wycofywania z użycia skryptów testów automatycznych, które nie są już przydatne lub niezbędne.
• Monitorowanie i przywracanie sprawności systemu podlegającego testowaniu. Ciągłe uruchamianie przypadku testowego lub zbioru przypadków testowych wymaga w praktyce nieprzerwanego monitorowania systemu podlegającego testowaniu. Jeśli w systemie tym wystąpi błąd krytyczny (np. crash), framework do testów automatycznych musi umożliwić przywrócenie sprawności systemu, pominięcie bieżącego przypadku testowego i wznowienie testowania od następnego przypadku.

Utrzymanie kodu związanego z automatyzacją testów może być skomplikowanym zadaniem. Zdarza się, że ilość kodu używanego do testowania dorównuje ilości kodu systemu podlegającego testowaniu, przez co kluczowego znaczenia nabiera utrzymywalność. Wynika to z faktu stosowania różnych narzędzi testowych i przeprowadzania różnego typu weryfikacji, a także z konieczności utrzymywania różnych testaliów (takich jak dane wejściowe do testów, wyrocznie testowe czy raporty z testów).

Mając na uwadze powyższe uwagi dotyczące utrzymania, warto unikać następujących działań:

• Nie należy tworzyć kodu uzależnionego od sposobu działania interfejsu (tj. kodu, na który miałyby wpływ zmiany w interfejsie graficznym lub w mniej istotnych obszarach API).
• Nie należy tworzyć takich mechanizmów automatyzacji testów, które są wrażliwe na zmiany danych lub w dużym stopniu uzależnione od określonych wartości danych (przykładem może być zależność danych wejściowych do testów od danych wyjściowych z innych testów).
• Nie należy tworzyć takiego środowiska automatyzacji, które jest wrażliwe na kontekst (np. na ustawienia daty i godziny w systemie operacyjnym, parametry lokalizacji systemu operacyjnego bądź zawartość innej aplikacji). Lepszym rozwiązaniem jest użycie w razie potrzeby zaślepek testowych do sterowania parametrami środowiska.

Im więcej kryteriów sukcesu zostanie spełnionych, tym wyższe będzie prawdopodobieństwo powodzenia projektu automatyzacji. Należy jednak pamiętać, że nie każde kryterium jest obowiązkowe, a w praktyce spełnienie wszystkich kryteriów jest rzadko spotykane. Dlatego przed rozpoczęciem projektu automatyzacji testów należy przeanalizować szanse jego powodzenia z punktu widzenia spełnionych i niespełnionych kryteriów, z uwzględnieniem czynników ryzyka związanych z wybranym podejściem oraz kontekstu projektu. Po opracowaniu architektury automatyzacji testów należy również zbadać, jakich elementów brakuje lub jakie elementy wymagają dalszego dopracowania.

Artykuł oparty jest na sylabusie "Certyfikowany tester ISTQB®. Sylabus specjalistyczny. Inżynier Automatyzacji Testów", a merytoryka omawiana jest podczas naszego szkolenia "Przygotowanie do egzaminu certyfikującego ISTQB® Inżynier Automatyzacji Testowania - Moduł Specjalistyczny ISTQB® Test Automation Engineer - Specialist", na które serdecznie zapraszamy. Dla uproszczenia zastąpiono pojęcia z sylabusa pojęciami praktycznymi.