Podziel się tym wpisem!

Czym są testy dymne (smoke tests)?
Testy dymne. Czym są i kiedy się je wykonuje?

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ę.

Znalazłeś błąd na tej stronie? Zgłoś mi go.
Formularz zgłoszenia błędu

Jeśli znalazłeś błąd w tekście lub na stronie to proszę, zgłoś mi go. Większość pól tego formularza nie jest wymagana. Jeśli chcesz zgłosić błąd tak, jak powinno się to zrobić, wypełnij je wszystkie.

W formularzu brakuje pola „dodaj załącznik”, ponieważ użycie tej formatki jest płatne. Jeśli jednak chcesz wysłać mi załącznik, prześlij go na e-mail waldemar.szafraniec.szkolenia@gmail.com, w tytule wiadomości napisz, że jest to załącznik do zgłoszenia błędu.

Podany e-mail będzie wykorzystany tylko w celu obsługi tego zgłoszenia - zostaniesz poinformowany, gdy błąd zostanie poprawiony. Podanie e-mail nie jest równoznaczne z zapisem na newsletter.
Tytuł powinien w sposób jasny i czytelny mówić co nie działa na stronie.
Ile prób odtworzenia błędu udaje się odtworzyć.
Dane opisowe błędu. Mogą to być informacje szczegółowe na temat tego, jaki komunikat się wyświetlił. Albo dodatkowe informacje początkowe, jakie muszą zaistnieć.

Podziel się tym wpisem!

Waldemar Szafraniec

Nazywam się Waldemar Szafraniec. Karierę testera rozpocząłem w 2012 roku. Od początku pracy w zawodzie wiedziałem, że będzie to coś więcej niż tylko praca. Obecnie praca jest również moim hobby. Jednym z moich obowiązków w obecnym miejscu pracy jest rekrutowanie nowych testerów oraz szkolenie ich. Sam stale podnoszę swoje kwalifikacje uczestnicząc w szkoleniach (ISTQB, ISTQB Advanced Level – Test Analyst). Szkolę ludzi w dziedzinie testów manualnych od 2014 roku. Jestem trenerem, ponieważ wiem, że dobrze mi wychodzi przekazywanie wiedzy, wiem jak praca testera wygląda oraz mam doświadczenie w rekrutacji.

Dodaj komentarz