Cześć!

Przy lekturze kilku zagranicznych blogów o tematyce automatyzacji oprogramowania, zauważyłem że dość często jest poruszana koncepcja “piramidy automatyzacji testów”, która opisuje trzy poziomy automatyzacji testów, ich relacje oraz względne znaczenie. Zdecydowanie podoba mi się to podejście, dlatego chciałbym się nim z Tobą podzielić!

Żeby być oryginalnym zrezygnuję z schematu piramidy na rzecz smakowitego burgera 🙂 zobacz poniżej:

Warstwa podstawowa: testy jednostkowe

Testy jednostkowe stanowią podstawę każdego solidnego podejścia do testowania automatycznego. Można je napisać stosunkowo szybko z porównaniem do raportu o błędzie (otrzymanym np. od testera), który zwykle brzmi „funkcja X i Y nie działa, kiedy wpisuję A lub B, napraw to proszę itd. itp.” Często taka forma wymaga większej analizy (odtworzenie, debugowanie), zatem wymaga więcej czasu od programisty na naprawienie problemu. Zaletą testów jednostkowych jest to, że nie tylko można je szybko napisać, ale także wykonanie testów jest bardzo szybkie, co w rezultacie daje deweloperowi natychmiastową informację zwrotną.

Wady testów jednostkowych polegają na tym, że koncentrują się głównie na małych fragmentach kodu (metodach, klasach) i dlatego nie są w stanie wykryć błędów na poziomie integracji lub systemu.

Warstwa środkowa: testy integracyjne/API

Większość współczesnych aplikacji oferuje pewnego rodzaju API (poprzez rzeczywisty interfejs programistyczny lub przez usługę sieciową udostępniającą funkcjonalność na zewnątrz), może ono być użyte przez testera do testowania aplikacji. Testy te są często znacznie “stabilniejsze”, ponieważ interfejsy API zmieniają się znacznie rzadziej niż testy interfejsu użytkownika i są wykonywane znacznie szybciej z mniejszą liczbą fałszywie negatywnych wyników.

Górna warstwa: testy na poziomie interfejsu użytkownika

Najlepiej jest minimalizować testy w tej warstwie, ponieważ często są one najbardziej “kruche” i zajmują najwięcej czasu zarówno podczas tworzenia przypadków testowych, jak i wykonywania testów. Uważam, że ta forma automatyzacji testów powinna być używana tylko wtedy, gdy faktycznie testowany jest interfejs użytkownika, a nie podstawowa funkcjonalność systemu, lub wtedy gdy nie ma innej alternatywy.

Podsumowanie:

Spróbuj zrozumieć mechanizm stosowania poszczególnych testów i ich praktyczne wykorzystanie, przyglądaj się innym deweloperom -> co testują i jakie pokrycie jest osiągane w pisanych testach jednostkowych. Co do testów, które nie są objęte testami jednostkowymi, spróbuj dowiedzieć się -> czy testowana aplikacja oferuje interfejs API, na którym można wdrożyć testy automatyczne. Początkowo testowanie „pod maską” bez interfejsu użytkownika do przeprowadzania testów może wydawać się trudne, ale korzyści dla projektu są warte włożonego trudu.

Pomimo, że kształt burgera automatyzacji testów powinien być mniej więcej zachowany, to pamiętaj składniki i proporcje burgera muszą być dobrane odpowiednio dla gustów zamawiających klientów -> dokładnie tak jak w przypadku proporcji stosowania odpowiednich testów w zależności od projektu informatycznego (indywidualne podejście).

Przestrzeganie powyższych sugestii znacznie pomoże Ci w uzyskaniu idealnego burgera automatyzacji testów. 🙂