Dzisiejszy krótki wpis chciałem zadedykować jednym z przyjemniejszych testów, jakie wykonujemy w procesie wytwarzania oprogramowania, przynajmniej według mnie. Mowa tutaj o testach dymnych.
Czym są testy dymne?
Odpowiedź jest stosunkowo prosta – są to po prostu wszystkie najważniejsze ścieżki potwierdzające, że główne funkcjonalności aplikacji działają poprawnie. Mówiąc to jeszcze prościej, sprawdzamy, czy nasza aplikacja w najważniejszych jej obszarach i sposobach użycia działa jak należy. Pamiętać trzeba, że z założenia testy dymne (Smoke Tests) nie mają na celu bardzo dokładnego testowania. Nie służą znalezieniu błędów w funkcjonalnościach.
Kiedy stosujemy testy dymne?
W zasadzie możemy takie testy wykonać w każdym momencie i zawsze dadzą nam one oczekiwaną odpowiedź przy stosunkowo małym koszcie/nakładzie pracy, jaką będziemy musieli na nie przeznaczyć.
Jeśli czytasz mojego bloga regularnie, to zapewne wiesz, że sporo czasu w swojej karierze spędziłem na pracy w zespołach Scrumowych. Dlatego najbliżej jest mi do podawania przykładów wykonania takich testów na podstawie moich doświadczeń.
To kiedy stosowałem tego typu testy?
Przeważnie wykonuję je, gdy prace nad nową funkcjonalnością aplikacji są skończone. Smoke testy wykonuję również na funkcjonalnościach wcześniej ukończonych po każdym kolejnym zakończonym zadaniu. Dzięki temu miałem pewność, że zadanie nie psuło wcześniej ukończonych.
Teraz pewnie jesteś zdziwiony, ponieważ wcześniej napisana definicja odnosiła się do sprawdzenia, czy najważniejsze funkcje w naszej aplikacji działają poprawnie. Smoke testy odnoszą się również do poszczególnych modułów w aplikacji.
Czy możemy sobie jakoś ułatwić robotę?
Oczywiście, że tak! Akurat ścieżki dedykowane do testów dymnych wydają mi się jednymi z tych, które powinno się ustawić na liście „Do automatyzacji” stosunkowo wysoko. Powody są przynajmniej dwa.
Pierwszy jest taki, że jakby nie było, sprawdzamy tutaj, czy nasza aplikacja działa poprawnie, zatem automaty powinny przechodzić bez problemu.
Drugi mówi o wydajności i czasie, a raczej jego skracaniu. Zautomatyzowane ścieżki potwierdzające działanie najważniejszych funkcjonalności możemy uruchomić w dowolnym czasie. Nie obciążają budżetu, skracają natomiast czas na taką właśnie weryfikację.
dziękuję za piękne wytłumaczenie 🙂