Odpowiedź.

Wdrożenie automatycznego testowania w już istniejącym projekcie to zadanie skomplikowane i wielopoziomowe.

Historia pytania: W organizacji, w której testowanie przez długi czas odbywało się ręcznie, procesy, dokumentacja i architektura kodu nie zawsze odpowiadają wymaganiom automatyzacji. Testerzy nie znają narzędzi automatycznych, a architektura testów i samych aplikacji może nie wspierać szybkiego uruchamiania testów automatycznych.

Problem: Główne trudności we wdrożeniu:

1. Brak kultury automatyzacji: brak doświadczenia, narzędzi, procesów.
2. Trudność w pracy z kodem legacym: trudności w integrowaniu testów, brak testowalnych interfejsów i stabilnej struktury elementów.
3. Brak kryteriów priorytetyzacji: co automatyzować w pierwszej kolejności i gdzie to przyniesie największy efekt?

Rozwiązanie: Zespół powinien przejść przez etapy:

1. Ocena gotowości: zidentyfikować najbardziej krytyczne i często powtarzające się ręczne testy, które przyniosą oszczędność czasu.
2. Pilotaż: wybrać mały blok systemu i zrealizować pilotowy zestaw testów automatycznych do szybkiego sprawdzenia hipotez.
3. Stopniowe wdrożenie: w miarę sukcesu pilota zwiększać pokrycie testami automatycznymi, równocześnie szkoliąc zespół w zakresie automatyzacji.

Kluczowe cechy:

• Automatyzację warto zaczynać od testów regresyjnych i „smoke”.
• Ważne jest, aby wbudować testy automatyczne w istniejący proces rozwoju (na przykład uruchamiać je przy pull request).
• Należy uwzględnić komunikację — wyjaśnić biznesowi i testerom korzyści i ograniczenia automatyzacji.

Pytania z podstępem.

Czy automatyczne testy mogą całkowicie zastąpić testowanie ręczne?

Nie. Nawet przy wysokim pokryciu testy automatyczne są stosowane tylko w powtarzalnych, deterministycznych scenariuszach. Niezauważalne błędy użyteczności, eksploracja, błędy projektowe i nietypowe „ludzkie” błędy zazwyczaj wychwytywane są ręcznie.

Czy należy automatyzować wszystkie testy bez wyjątku?

Nie. Nie wszystkie testy opłaca się automatyzować: testy o niskiej częstotliwości lub trudne scenariusze lepiej pozostawić do testowania ręcznego z uwagi na koszty i niską wydajność.

Czy testerzy muszą być programistami, aby skutecznie realizować automatyzację?

Nie, ale wskazany jest podstawowy poziom programowania. Zespół często budowany jest na połączeniu: doświadczony tester — architekt testów automatycznych, automatyzatorzy — programiści.

Typowe błędy i antywzorce

• Próba natychmiastowego pokrycia wszystkiego automatyzacją, bez określenia priorytetów.
• Niewystarczająca komunikacja między testerami ręcznymi i automatyzatorami.
• Wybór narzędzi „na słuchu”, a nie odpowiednich dla konkretnego projektu.
• Brak procesu wsparcia i aktualizacji testów automatycznych: „uruchomili i zapomnieli”.

Przykład z życia

Negatywny przypadek

Firma zdecydowała się automatyzować wszystkie testy ręczne jednocześnie, nie wydzielając oddzielnego zespołu i nie omawiając priorytetów. Kupiono modny instrument, ale nie obsługiwał części potrzebnych przeglądarek. W rezultacie połowa testów przestała działać po kwartale.

Zalety:

• Szybkie pierwsze wdrożenie, entuzjazm zespołu.

Wady:

• Ogromne koszty, szybko pojawiające się rozczarowanie, wydatki na szkolenie, słabe pokrycie naprawdę potrzebnych scenariuszy.

Pozytywny przypadek

Zespół ręcznie wybrał 10 najczęstszych scenariuszy regresyjnych. Przeprowadzono szkolenie w zakresie automatyzacji na Pythonie (Selenium), dodano testy do CI. Po pół roku 70% testów regresyjnych uruchamiało się automatycznie, testerzy ręczni zajmowali się kreatywnością.

Zalety:

• Rzeczywista oszczędność czasu, zespół wzrósł w ekspertyzie, zmniejszenie czynnika ludzkiego.

Wady:

• Koszty aktualizacji testów automatycznych przy zmianach interfejsu, długi czas uruchamiania.