Środowisko testowe musi wskazywać konkretny build
Informacja „testowano najnowszą wersję” szybko traci znaczenie. Każde uruchomienie powinno być powiązane z identyfikatorem commita, wersją pakietu albo niezmiennym tagiem obrazu. Dzięki temu błąd można odtworzyć po kolejnej publikacji i ustalić, czy poprawka rzeczywiście zmieniła zachowanie aplikacji.
Identyfikator wersji powinien być widoczny również dla testera, na przykład w stopce aplikacji, endpointcie diagnostycznym lub pliku umieszczonym na VM. Osoba zgłaszająca problem nie powinna szukać tej informacji w historii wdrożeń. W raporcie warto zapisać także wersję przeglądarki, runtime i usług, jeśli mogą wpływać na wynik.
Dane startowe są częścią scenariusza
Test funkcji biznesowej wymaga znanych kont, ról i rekordów. Zestaw danych powinien obejmować przypadki typowe, graniczne oraz błędne, ale nie może być przypadkową kopią produkcji. Dane syntetyczne są łatwiejsze do opisania, bezpieczniejsze i pozwalają celowo przygotować sytuacje, które rzadko występują w rzeczywistym systemie.
Jeśli kilka osób testuje równolegle, nie powinny zmieniać wspólnego stanu. Oddzielna instancja aplikacji, schemat bazy lub tenant dla każdego użytkownika zapobiegają sytuacji, w której jeden test usuwa warunek potrzebny drugiemu. Wybrany model zależy od architektury, ale zasada pozostaje ta sama: rezultat ma wynikać z testowanej funkcji, a nie z działań innej osoby.
Reset musi być deterministyczny
Mechanizm resetu powinien odtwarzać ten sam zestaw kont, danych i ustawień niezależnie od liczby wcześniejszych uruchomień. Skrypt, który tylko dopisuje rekordy, po kilku próbach zacznie generować inne wyniki. Dobry reset usuwa stan roboczy, wykonuje migracje i ładuje wersjonowany seed, a na końcu potwierdza gotowość aplikacji.
Snapshot całej VM przyspiesza powrót do stanu bazowego, szczególnie gdy scenariusz zmienia pakiety lub konfigurację systemową. Przy częstych testach lepiej jednak utrzymywać automatyczny bootstrap. Pokazuje on jawnie, z czego składa się środowisko, i można go uruchomić również po zmianie obrazu.
Dobry raport łączy objaw z danymi diagnostycznymi
Zrzut ekranu pokazuje efekt, lecz zwykle nie wyjaśnia przyczyny. Raport błędu powinien zawierać oczekiwany i rzeczywisty rezultat, minimalną ścieżkę odtworzenia, identyfikator buildu, użyte konto lub rolę, znacznik czasu oraz dane wejściowe. W aplikacji sieciowej przydaje się również request, response i correlation ID prowadzący do właściwych logów.
Logi muszą być dostępne bez nadawania testerowi szerokich uprawnień administracyjnych. Może to być wydzielony podgląd, plik z odpowiednimi prawami albo pomoc prowadzącego. Hasła, tokeny i dane osobowe powinny być maskowane. Laboratorium ma ułatwiać diagnozę, nie tworzyć kolejnej kopii informacji wrażliwych.
Test i demonstracja mają inne kryteria
Podczas testu celowo szuka się błędów i sprawdza zachowanie na niepoprawnych danych. Demonstracja ma pokazać ustalony przebieg w przewidywalny sposób. Przed spotkaniem z klientem trzeba więc zamrozić wersję, przygotować czytelne dane, przejść scenariusz od początku oraz wyłączyć elementy, które nie są częścią prezentacji.
Izolowana VM może obsłużyć oba zastosowania, ale nie powinna robić tego jednocześnie na tym samym stanie. Najbezpieczniej utworzyć osobną kopię demonstracyjną z kontrolowanym dostępem. Testerzy zachowują wtedy swobodę, a działania wykonywane w tle nie zmieniają ekranu prezentera.
Środowisko izolowane ma swoje ograniczenia
Pojedyncza VM dobrze nadaje się do testów funkcjonalnych, API, instalacji i kompatybilności. Nie odtwarza automatycznie zachowania systemu pod dużym obciążeniem, awarii wielu węzłów ani opóźnień rozproszonej infrastruktury. Takie pytania wymagają osobnej topologii, generatora ruchu i obserwacji usług po obu stronach testu.
Różnice względem produkcji trzeba opisać. Inna baza, lokalny magazyn obiektów czy atrapa zewnętrznego API mogą być właściwym wyborem, jeśli test dotyczy logiki aplikacji. Nie wolno jednak na tej podstawie wyciągać wniosków o wydajności lub niezawodności integracji, której środowisko nie zawiera.
Po zakończeniu zostaje dowód, nie przypadkowa maszyna
Wartość testu tworzą raporty, poprawki, automatyczne przypadki testowe i opis środowiska. Przed wyłączeniem VM należy zachować te artefakty w systemie źródłowym, usunąć tymczasowe poświadczenia i zdecydować, czy próbka danych ma pozostać do regresji. Sama maszyna nie powinna być jedynym nośnikiem wiedzy.
Przykład bardziej rozbudowanego laboratorium opisuje scenariusz testów funkcjonalnych i API. Jeżeli potrzebne jest krótkie środowisko dla pojedynczego testu lub demonstracji, punktem wyjścia może być także Sandbox VM z uzgodnioną konfiguracją.