Smoke testing i Sanity testing

Tagi: 3 komentarze do Smoke testing i Sanity testing

W tym tygodniu wzięliśmy pod lupę Smoke testing (zwane też testami dymnymi) i Sanity testing. Nazwy brzmią interesująco i z pewnością intrygują. Co to za testy, do czego się ich używa, jakie mają mocne i słabe strony i czym się od siebie różnią? Jeśli szukacie odpowiedzi na któreś z tych pytań, zapraszamy do zapoznania się z tym postem 🙂 .

Jesteście gotowi na garść piątkowej edukacji?

Smoke testing

Nie będzie to dla nikogo zaskoczeniem, jeśli do wyjaśnienia zjawiska posłużymy się definicją zawartą w Słowniku wyrażeń związanych z testowaniem, wersja 2.2 (2012), gdzie czytamy:

Test dymny: podzbiór wszystkich zdefiniowanych/zaplanowanych przypadków testowych, które pokrywają główne funkcjonalności modułu lub systemu, mający na celu potwierdzenie, że kluczowe funkcjonalności programu działają, bez zagłębiania się w szczegóły. Codzienne budowanie [wersji oprogramowania] i testy dymne stanowią dobre praktyki wytwarzania oprogramowania.

Co się dymi w tej nazwie?

Termin „testy dymne” pochodzi od testów sprzętów elektrycznych, w których urządzenie po włączeniu jest sprawdzane na obecność dymu lub ognia z jego elementów. Zapewnia to, że podstawowe elementy sprzętu działają poprawnie i nie stwierdzono żadnych poważnych awarii. Chodzi zatem o to, by sprawdzić oczywistą funkcjonalność sprzętu w łatwy sposób, jednocześnie nie tracąc zbyt dużo czasu na analizę.

Podobnie, gdy przeprowadzamy testy dymne aplikacji czy oprogramowania, upewniamy się, że nie pojawiają się żadne poważne awarie przed wydaniem kompilacji do dalszych testów np. obciążeniowych.

Pożar sprzęt kobieta gogle strażak

Użycie

Testy dymne wykonuje się, by upewnić się, że krytyczne funkcje aplikacji działają zgodnie z oczekiwaniami. Analiza nie jest pełna, a przypadki testowe ograniczone.

Ten rodzaj analizy może zostać przeprowadzony przez programistów przed udostępnieniem wersji testowej zespołowi testerów, a następnie przeanalizowany przez tych drugich, by upewnić się, że kompilacja jest wystarczająco stabilna do przeprowadzenia w dalszej kolejności testów szczegółowych. Testy dymne przeprowadza się na podstawie pozytywnych scenariuszy i wprowadzając prawidłowe dane. Swoim zakresem obejmują wszystkie podstawowe i ważne funkcje aplikacji, dlatego ich zasięg jest płytki, ale szeroki. Często opiera się na oczywistej ścieżce użytkownika i jest prosty do odwzorowania; zwykle smoke testy są dokumentowane lub skryptowane.

Zalety i wady stosowania

Zalety

  • Pomagają w znalezieniu błędów na wczesnym etapie testowania
  • Są przydatne w znajdywaniu problemów wywołanych przez integrację komponentów
  • Ułatwiają weryfikację problemów rozwiązanych w poprzedniej wersji, ale nie wpływają na główne funkcjonalności aplikacji
  • Do przeprowadzenia wymagają bardzo niewielkiej liczby przypadków testowych
  • Mogą być przeprowadzone w krótkim czasie

Wady

  • Nie obejmują szczegółowej analizy aplikacji czy oprogramowania
  • Analiza jest niepełna z niewielką liczbą przypadków testowych, z powodu których nie jesteśmy w stanie znaleźć innych krytycznych problemów

laptop ściana roślinka

Sanity testing

Sanity testy zwykle przeprowadzane są, gdy z kodu usunięty zostanie jakiś błąd  lub gdy nastąpiła zmiana w funkcjonalności. Jest to rodzaj testowania oprogramowania przeprowadzany głównie przez testerów, by zapewnić funkcjonalność zgodną z oczekiwaniami. Testy te stanowią podzbiór testów regresyjnych i zwykle nie są skryptowane.

Jeśli chcecie dowiedzieć się więcej o testach regresyjnych
zajrzyjcie do jednego z naszych wcześniejszych wpisów tutaj.

Użycie

Sanity testy przeprowadzane są na poziomie powierzchni, która oparta jest na wąskim i sięgającym głęboko podejściu, koncentrującym się na szczegółowej analizie konkretnych funkcji. W przeciwieństwie do testów dymnych koncentrują się na jednej lub dwóch funkcjach. Sanity test powinien dać odpowiedź na pytanie, czy logika aplikacji jest zgodna z wymaganiami biznesowymi produktu.

Po wprowadzeniu zmian czy poprawek w kodzie oprogramowanie oddawane jest w ręce testerów. Po instalacji buildów testerzy przeprowadzają sanity testy na zmienionej (naprawionej) funkcjonalności, zamiast wykonywać testy regresyjne całości, co zajęłoby więcej czasu. Taka analiza jest krótka i szybka, a jednocześnie zapewnia, że zmiany działają zgodnie z oczekiwaniami i dokumentami specyfikacji. Jednak jeśli poprawiony błąd i zmienione funkcjonalności wciąż nie spełniają założeń projektu, testerzy nie powinni zaakceptować kompilacji.

Zalety i wady stosowania

Zalety

  • Oszczędzają sporą ilość czasu i wysiłku, ponieważ koncentrują się tylko na jednym lub kilku obszarach funkcjonalności
  • Zaoszczędzają czas i energię, ponieważ nie wymagają prowadzenia dokumentacji (są nieskryptowane)
  • Pomagają w określeniu zależnych, brakujących obiektów
  • Pomaga sprawdzić, czy dana funkcjonalność nadal działa poprawnie po zaaplikowaniu zmiany

Wady

  • Koncentruje się wyłącznie na poleceniach i funkcjach oprogramowania
  • Poziom analizy nie dochodzi do poziomu struktury projektu, dlatego programistom może być ciężko rozwiązać problemy wykryte podczas testowania
  • Analiza wykonywana jest tylko dla niektórych ograniczonych funkcji, więc jeśli wystąpi problem z innymi funkcjami, może okazać się on trudny do wychwycenia
  • Zwykle nie są skryptowane, więc nie będzie się można do nich odnieść w przyszłości

Podsumowanie

Smoke testy

Sanity testy

Główne pole działania

Weryfikacja stabilności całego systemu, bez zbędnego zagłębiania się w szczegóły

Weryfikacja racjonalności systemu

Zastosowanie

Zapewnienie, iż podstawowe funkcje działają zgodnie z oczekiwaniami

Zapewnienie, że nowe funkcjonalności działają zgodnie z oczekiwaniami, a błędy zostały naprawione poprawnie

Podejście

Szerokie i płytkie

Wąskie i głębokie

Dokumentacja

Zwykle dokumentowane lub skryptowane

Zwykle nieskryptowane

Przeprowadzenie

Tester lub programista

Zwykle tester

Jest jak…

Ogólna kontrola stanu technicznego oprogramowania

Specjalistyczna kontrola stanu oprogramowania

Wykonanie

Wcześniej

Po testach dymnych

 

Mamy nadzieję, że przybliżyliśmy wam trochę Smoke i Sanity testy. Teraz już wiecie kiedy je stosować i do czego mogą być przydatne w pracy testera oprogramowania 🙂

DYSKUSJA

  1. Ogólnie lux wyjaśnione, a największe brawa za tabelkę z zestawieniem różnic!

  2. Skąd taka definicja “sanity test”? W “Słowniku wyrażeń związanych z testowaniem”, z którego zaczerpnięta jest definicja “smoke test”, “sanity test” kieruje na smoke test właśnie.

    1. W “Słowniku wyrażeń związanych z testowaniem” faktycznie nie ma definicji “Sanity test” jako takiej, a samo hasło odsyła do “Smoke test”. W poście nie jest podana informacja jakoby definicja “Sanity test” zaczerpnięta była ze wspomnianego źródła. Ze “Słownika…” pochodzi jedynie wyjaśnienie “Smoke test”. Definicja “Sanity test” inspirowana była opisem znajdującym się m.in. na stronie Software Testing Class.

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

wypróbuj

Zarejestruj się i zacznij działać!