Kiedy automatyzować historie użytkowników?

Jeśli pracowałeś w zwinnym środowisku jako QA, najprawdopodobniej natknąłbyś się na jakiś rodzaj automatyzacji testów. Nie mam na myśli automatyzacji testów jednostkowych, która jest zwykle działaniem skoncentrowanym na programistach, ale automatyzację testów akceptacyjnych funkcjonalnych, która jest zwykle wykonywana przez kontrolę jakości lub nową wymyślną rolę programisty w testach.

Najpierw przyjrzyjmy się niektórym kryteriom i powodom automatyzacji testów, które powinny odpowiedzieć na pytanie „Dlaczego testy powinny / nie powinny być zautomatyzowane”



Powtarzalność

Testy automatyczne powinny być powtarzalne, a dane wyjściowe powinny być spójne w każdym przebiegu, aby programiści mogli polegać na wynikach testów. Oznacza to również, że normalnie nie automatyzowalibyśmy testu, gdyby był uruchamiany tylko raz; jedynym wyjątkiem jest sytuacja, gdy przeprowadzasz test na bardzo dużej liczbie danych, na przykład sprawdzanie skryptu przekierowania linków z wieloma linkami.




Niezawodność

Testy automatyczne powinny naprawdę prawidłowo sprawdzać weryfikacje i być w stanie porównać rzeczywiste wyniki z ważnymi oczekiwanymi wynikami. Oznacza to również, że jeśli wyniki nie mogą być łatwo określone lub testy automatyczne podlegają problemom środowiskowym, które mogą powodować fałszywie pozytywne wyniki testów, to testy nie mogą być wiarygodne.



Czas

Testy automatyczne powinny również zaoszczędzić czas. Jeśli wykonanie prostego testu zajmuje 10 minut, ale ten sam wynik można określić ręcznie w ciągu 1 minuty, najlepiej nie automatyzować takich testów.




Sieć bezpieczeństwa

Testy automatyczne powinny zapewnić programistom sieć bezpieczeństwa, tak aby wszelkie odchylenia od dobrze działającego kodu, w wyniku zmian w bazie kodu, były szybko podkreślane i zgłaszane deweloperom.



Kiedy historie powinny być zautomatyzowane?

W typowym sprincie powiedzmy, że istnieje 7 historii, które są przeznaczone do sprintu, z których 5 jest dobrymi kandydatami do automatyzacji na podstawie powyższych kryteriów. Ale kiedy jest najlepszy czas, aby zautomatyzować te historie? Czy powinniśmy pisać testy automatyczne w trakcie opracowywania funkcji? Czy powinniśmy poczekać, aż funkcja zostanie opracowana, a następnie napisać testy automatyczne? Czy mamy czekać do końca sprintu, a potem zautomatyzować historie?

W niektórych przypadkach, gdy historie są poprawkami błędów lub niewielkimi modyfikacjami lub ulepszeniami istniejącej funkcji, sensowne jest pisanie testów automatycznych, ponieważ funkcja jest modyfikowana przez programistów. Może nawet istnieć istniejący automatyczny test modyfikowanej funkcji, w którym wystarczy dostosować skrypt, aby uwzględnić nowe zmiany.

W innych przypadkach, gdy historia dotyczy zaimplementowania nowej funkcji do aplikacji, skąd wiemy, jak będzie wyglądał produkt końcowy, aby móc wcześniej napisać testy? Nie mówię tutaj o plikach funkcji, które z wyprzedzeniem opisują testy akceptacyjne, ale o rzeczywistych urządzeniach lub testach selenu (implementacja testów), które działają na podstawie dostarczonego kodu.


Najważniejsze jest to, że każdy test, który ma być wykonany więcej niż jeden raz, powinien zostać zautomatyzowany. A które testy będziemy wykonywać więcej niż raz? Testy regresji. A co to są testy regresji? Testy, które określają, czy aplikacja przestała działać w wyniku nowych modyfikacji i funkcji.

Ale można napisać tylko dobre automatyczne testy regresji dla systemu, który jest stabilny, dobrze zrozumiany i deterministyczny pod względem zachowania ze znanymi danymi wejściowymi i wyjściowymi.

Problem z próbą napisania automatycznych testów dla funkcji w trakcie jej tworzenia polega na tym, że możesz poświęcić dużo czasu i dużo wysiłku na pisanie automatycznych skryptów przeciwko czemuś, co jest niestabilne i podlega ciągłym zmianom podczas sprintu. Co więcej, ile razy widzieliśmy, jak historia była zaangażowana w sprint, a później została wyciągnięta ze sprintu? Potem straciliśmy czas na pisanie skryptów, które nie trafiły do ​​systemu.

Niektóre organizacje narzucają nawet surową zasadę, że historia nie jest „gotowa”, dopóki nie zostanie w pełni zautomatyzowana! Czy zamierzamy przerwać publikację ważnej funkcji, ponieważ kontrola jakości nie zapewniła lub nie mogła zapewnić automatyzacji na czas z różnych powodów? Albo historia nie jest „gotowa”, ponieważ nie mamy automatycznego skryptu sprawdzającego istnienie przycisku na stronie. Poważnie?


Najlepszym celem testowania automatyzacji jest testowanie regresyjne, a testy regresyjne są zawsze uruchamiane w odniesieniu do znanego stanu i deterministycznego systemu, aby móc wykryć zmiany w linii bazowej i uzyskać znaczący wynik z testu automatycznego tylko wtedy, gdy test został uruchomiony i przynajmniej raz przeszedł ręcznie, dzięki czemu można porównać wyniki przebiegu automatycznego z wykonaniem ręcznym.

Zgodnie z tą definicją historie powinny być zautomatyzowane (implementacja) w ramach sprintu i tylko wtedy, gdy funkcja jest w pełni zweryfikowana ręcznie. Gdy historia jest kompletna i najpierw zweryfikowana ręcznie, jest to niezawodna funkcja i stabilny system, z którym można następnie zaprojektować i napisać zautomatyzowane testy. Po zaimplementowaniu testu automatycznego jest on dodawany do zestawu testów regresyjnych w celu monitorowania i wykrywania defektów regresji podczas opracowywania kolejnych funkcji.