Redakcja
Kiedy testujemy system, widoczność statusu jest krytycznie ważna. System może zachowywać się różnie w zależności od wcześniejszych wymuszeń oraz ich kolejności. Zazwyczaj testy wykonujemy na tzw. czystej konfiguracji. Restart systemu jest przygotowaniem do większości przypadków testowych. Błędy mogą jednak wynikać z działań wykonywanych przez system lub użytkownika w czasie poprzedzającym samo wykonanie testu. Doskonale to widać w testach niezawodności, gdzie test wykonywany jest w przedziale czasu i przy zadanej ilości działań. Nikt nie oczekuje, że awaria wystąpi zaraz po uruchomieniu oprogramowania. Drugim przykładem może być realne użycie aplikacji. Od użytkowników nie oczekuje się, że przed każdym działaniem będą restartowali system. Wyobraź sobie jak w takim wypadku musiałaby wyglądać instrukcja obsługi np. telefonu: "Jeśli chcesz wykonać połączenie telefoniczne najpierw zrestartuj telefon (...). W innym przypadku wytwórca nie gwarantuje poprawności działania."
Na podobny problem natrafiamy przy próbie odtworzenia niektórych błędów. Testujemy. Pojawia się błąd. Próbujemy reprodukcji i ... działa. Restartujemy system, powtarzamy działania i ... działa. Kluczem do zrozumienia problemu jest więc analiza czynności poprzedzających wystąpnie problemu.
Co zrobić więc, aby nasze testy były możliwie najbardziej realne? Musimy wiedzieć w jakim stanie aktualnie znajduje się system i co wydarzyło się do tego momentu.
Możliwości jest kilka:
1) zapis wideo wcześniejszych działań - metoda skuteczna jedynie dla widocznych na ekranie działań i czasochłonna w odtwarzaniu nagrania i jego analizowaniu
2) logowanie działań w systemie w oparciu o logowania zachowań użytkownika / testera - narzędzi i metod jest wiele w zależności od typu platformy jaką testujemy, od prostego logowania klawiszy i kliknięć po generowanie kodu bezpośrednio z działań użytkownika (rejestruj - odtwórz)
3) pozyskiwanie statusu systemu bezpośrednio z testowanego systemu - część aplikacji zapisuje każde ze zdarzeń w logu, czym więcej informacji jest przechowywanych tym łatwiej określić zdarzenia poprzedzające wystąpienie awarii, ale i sam log staje się wtedy mnie czytelny.
Uzyskanie informacji o statusie systemu lub też automatyczne "doprowadzenie" systemu do danego stanu podnosi efektywność testowania i procesu zarządzania zdarzeniami. Warto o tym pamiętać kiedy mamy wpływ na to jak budowana jest aplikacja i jak projektowana jest środowisku samego wykonania testów.
