Redakcja
Koszty automatyzacji są znaczące i wpływają na nie m.in.:
- wybrana metoda automatyzacji,
- wytworzenie i utrzymanie narzędzi automatyzacji i frameworka automatyzacji,
- koszty wytworzenia skryptów automatycznych,
- koszty zmiany już powstałych skryptów,
Najczęściej na zmianę specyfikacji testów wpływa zmiana wymagań biznesowych. W projekcie z (dobrze zaprojektowanymi) manualnymi przypadkami testowymi jest to zazwyczaj prosta zmiana tekstu. W projekcie automatyzacji na zmianę skryptów wpływa nie tylko zmiana wymagań, ale również refaktoryzacja kodu (np. zmiany w obszarze lokalizatorów elementów), dodanie elementów na froncie (np. rozszerzenie / zawężenie liczby pól w formularzu), czy zamiana technologii (np. zastąpienie HTML-a przez JS).
- i wiele innych czynników, jak wytyczne płynące z modelu rozwoju oprogramowania czy wiedza i umiejętności specjalistów od automatyzacji.
Koszty utrzymania będą wyższe jeśli zrezygnujemy z page object pattern albo innych wzorców stosowanych w automatyzacji: https://dzone.com/articles/design-patterns-in-automation-testing
Z dostępnej wiedzy i badań wynika, że działania QA są tańsze od próby automatyzacji testów na interfejsie graficznym [http://testerzy.pl/baza-wiedzy/koszty-i-wartosc-automatyzacji]. Jako członek zespołu projektowego rozważ następujące działania, które mogą przynieść więcej korzyści taniej niż automatyzacja.
1. Znaj zakres dokonywanych w aplikacji zmian. Generacja automatyczna.
Dzięki stosowaniu CI (ciągła integracja) z wbudowaną analizą statyczną kodu i z automatycznie generowanymi informacjami o zmianach w modułach możesz dostać informację o jakości dostarczanego kodu oraz o zakresie modyfikacji.
Kod commitowany na serwerze, z którego budowana jest wersja (CI) może być poddany szeregowi weryfikacji:
- Analiza statyczna podpowie, czy kod jest dobrej jakości albo przynajmniej czy spełnia zdefiniowane w organizacji reguły;
- Mechanizm sprawdzający zakres wprowadzonych zmian na kodzie może w podstawowej wersji pokazać, jakie funkcje lub klasy zostały zmienione i zwracać albo ich nazwy (ważne, aby były one samo się wyjaśniające) albo komentarze zawierające zakres odpowiedzialności danego fragmentu kodu. Sam commit może mieć również wymaganą regułę opisywania przez programistę zakresu i celu zmian.
Aby uzyskać jeszcze większą wartość poszczególne funkcje i klasy mogą być automatycznie mapowane na pojedyncze funkcje i/lub na procesy biznesowe.
- Jeśli posiadasz testy jednostkowe i/lub integrację (również webservice'y) oraz jakiekolwiek inne zadania QA, które mogą być wykonane automatycznie, mogą być one również wykonywane na każdym nowym commicie lub buildzie.
Automatycznie wygenerowane raporty z narzędzi CI mogą pomóc testerowi manualnemu zdefiniować, co i w jakim zakresie warto testować.
2. Znaj zakres dokonywanych w aplikacji zmian. Generacja ręczna.
Jeżeli nie masz dobrego serwera zarządzania wersjami kodu, to popracuj z programistami i z ludźmi odpowiedzialnymi za budowanie wersji nad notą wydania. Niech wraz z wersją oprogramowania do testów przekazują informację o zakresie zmian, uwzględniając dodane funkcje (i ich wpływ na inne moduły), naprawione defekty (i jak poprawki mogą wpłynąć na inne funkcje), obszary warte zweryfikowania pod kątem ryzyka regresji itd. Może tu przydać się również dokument opisujący architekturę rozwiązania, w którym zobaczymy jakie moduły kodu wpływają na jakie wymagania funkcjonalne spisane w dokumentacji.
Nota wydania jest naturalną instrukcją dla testera manualnego na temat zakresu testów do wykonania.
3. Wysokiej jakości kod i dobre praktyki kodowania.
Jeśli poczytasz Uncle Boba i jego object oriented design [http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod], dowiesz się jak pisać kod, który jest tańszy w utrzymaniu, łatwiejszy w modyfikacji i dużo prostszy w testowaniu. Często stosowanie już pierwszej zasady o pojedynczej odpowiedzialności klas i modułów znacząco redukuje konieczność tworzenia automatycznych testów GUI.
Promuj w zespole ideę tworzenia oprogramowania metodą TDD lub pisania testów jednostkowych. Zachęcaj i stosuj dobre praktyki tworzenia kodu [https://helion.pl/ksiazki/czysty-kod-podrecznik-dobrego-programisty-robert-c-martin,czykov.htm#format/d], a aplikacja na interfejsie nie będzie potrzebowała zbyt wielu automatycznych testów GUI ze względu na większą stabilność i mniejsze ryzyko regresji.
4. Testowanie A/B.
Zdarza Ci się wrzucić na produkcję coś, co nie jest w całości przetestowane i masz na to przyzwolenie? Stosuj w takim razie metodę A/B. Spośród wielu użytkowników wybierz kilku (kilkuset) testowych, którym udostępnisz wersję po zmianach (B). Jeśli w ich monitorowaniu dostrzeżesz odchyłki od standardowego zachowania albo w logach pojawią się informacje o wyjątkach, szybko udostępnij im ponownie wcześniejszą wersję (A). Zbadaj logi i dowiedz się na jaki problem natrafili. Jeśli wersja B osiągnęła swój cel, wypuść ją do całej populacji Twoich odbiorców.
Pojawia się tutaj oczywiście koszt mechanizmu do zmian przełącznikowych, narzędzi monitorujących oraz praca polegająca na analizie i obsłudze alertów. Niekwestionowaną zaletą będzie za to możliwość zweryfikowania jakości bezpośrednio przez końcowych użytkowników.
Testy A/B naturalnie zastępują testy automatyczne interfejsu, przerzucając odpowiedzialność za weryfikację potencjalnej regresji na końcowego użytkownika. Musi zostać dokonana analiza ryzyka defektu na produkcji, jednak to silnie będzie bazować na kontekście użycia danego oprogramowania.
5. Przeglądy.
Przeglądaj każdy półprodukt, jaki powstaje. Z różnym natężeniem i przez różne osoby, ale dbaj, aby wytworzona specyfikacja była wysokiej jakości. Mówimy tu również, a może przede wszystkim, o specyfikacji kodowej. Dobrze wykonany przegląd musi uwzględniać zaangażowanie całego zespołu projektowego wraz z analitykami, testerami i programistami.
Wszystkie źródła są tutaj zgodne - znalezione w ten sposób błędy i defekty są najtańsze do usunięcia. Techniki wczesnego zaangażowania redukują olbrzymie koszty naprawy defektów w późnych fazach wytworzenia i wdrożenia produktu.
Przeglądy nie zastąpią nam w 100% testów interfejsowych, ale pozwolą na wytworzenie stabilniejszego oprogramowania, które będzie potrzebowało mniejszego zaangażowania testów regresywnych.
6. Predykcje błędów.
Szacowania lub też prognozowania liczby defektów znane są od wielu lat, ale dzięki optymalizacji wspierających je algorytmów dopiero w ostatnich latach zaczęto je skutecznie stosować w procesie wytwarzania oprogramowania. W ogólnym zarysie są to narzędzia automatyczne, bazujące na analizie statycznej i/lub na miarach projektu i produkt. Są one w stanie przewidzieć, gdzie i ile defektów jest albo pojawi się w przyszłości.
Do predykcji można zaprząc matematykę ze statystyką, sztuczną inteligencję oraz nauczanie maszynowe. Zgodnie z badaniami i publikacjami Jarosława Hryszko, który ten temat studiuje i wdraża komercyjnie, koszt przygotowania mechanizmu do przewidywania błędów jest niewielki. Wynika to przede wszystkim z darmowych i ogólnodostępnych rozwiązań.
Predykcja defektów pozwoli programistom popełniać ich mniej, a testerom lepiej zorientować cele testowania. Wpływa to bezpośrednio na ograniczenie zakresu testów regresywnych.
Autor: Radek Smilgin
Dziękuję za wkład i pomoc Monice Lichocie-Cywińskiej.
