Środowisko testowe to odizolowana instalacja systemu przeznaczona do testów: własna baza danych, konfiguracja i integracje odwzorowujące produkcję na tyle wiernie, by wyniki testów były miarodajne - ale bez ryzyka dla prawdziwych danych i użytkowników. Typowy łańcuch środowisk: deweloperskie → testowe → staging/UAT → produkcja.
Analityk biznesowy zderza się ze środowiskami przy planowaniu testów (zwłaszcza UAT) i specyfikowaniu integracji: które systemy zewnętrzne będą podpięte naprawdę, a które jako atrapy. Druga sprawa to dane testowe - muszą być realistyczne, inaczej testy nic nie wykryją, ale w systemach z danymi osobowymi nie mogą być zwykłą kopią produkcji.
W MediFlow środowisko testowe e-rejestracji to kopia konfiguracji produkcyjnej z dwiema istotnymi różnicami. Po pierwsze, dane pacjentów zanonimizowano: prawdziwa struktura i wolumen (180 tysięcy rekordów), ale wygenerowane nazwiska, numery PESEL i telefony - wymóg RODO, nie fanaberia. Po drugie, bramka SMS podpięta jest jako atrapa, która loguje wiadomości zamiast je wysyłać. Ta decyzja zapadła po historii, którą opowiedział wdrożeniowiec dostawcy: u innego klienta test masowych przypomnień na środowisku z prawdziwą bramką wysłał w nocy 3 000 SMS-ów do prawdziwych pacjentów o nieistniejących wizytach.
Częsta pomyłka: testowanie na produkcji, „bo środowisko testowe akurat nie działa". Jednorazowy skrót wchodzi w nawyk i kończy się modyfikacją prawdziwych danych. Druga: środowisko testowe odjechane od produkcji o trzy wersje i pół konfiguracji - testy świecą na zielono, a produkcja się sypie, bo testowano de facto inny system. Trzecia: kopiowanie produkcyjnych danych osobowych na testy bez anonimizacji. To naruszenie RODO, które wychodzi przy pierwszym audycie.
Jak nazywają się środowiska w projekcie i jak czytać te nazwy?
Łańcuch z definicji wyżej (deweloperskie, testowe, staging/UAT, produkcja) to układ typowy, spotkasz też inne. W jednej firmie środowisk są dwa, w innej siedem, a to samo miejsce potrafi mieć inną nazwę w dziale IT i inną u dostawcy. Analityk, który wchodzi na projekt, słyszy zdania w rodzaju „to jest już na SIT-cie", „wrzućcie na preprod" albo „odświeżcie mi UAT-a" i ma je rozumieć bez pytania po raz trzeci. Poniżej mapa nazw, z którymi się zderzysz.
| Nazwa (PL / EN / skrót) | Do czego służy | Kto na nim pracuje | Jak brzmi w rozmowie |
|---|---|---|---|
| deweloperskie / development / dev, local | budowanie i pierwsze uruchomienie zmiany | deweloper, często na własnym komputerze | „u mnie działa" |
| testowe / test, QA | sprawdzanie zmian przez zespół testowy | testerzy; analityk przy weryfikacji kryteriów akceptacji | „jest na teście, można klikać" |
| integracyjne / SIT (system integration testing) | zderzanie systemu z innymi systemami, prawdziwymi albo atrapami | testerzy, integratorzy | „na SIT-cie HIS nie odpowiada" |
| akceptacyjne / UAT | odbiór przez biznes na scenariuszach z codziennej pracy | użytkownicy biznesowi; analityk jako organizator | „UAT startuje w poniedziałek" |
| staging, preprodukcyjne / pre-production / preprod | kopia produkcji tuż przed wydaniem, ostatni przystanek | zespół wdrożeniowy, czasem biznes | „na stagingu stoi wersja z wtorku" |
| produkcyjne / production / prod | prawdziwi użytkownicy, prawdziwe dane | wszyscy, ale nikt nie testuje | „to już jest na prodzie" |
| sandbox dostawcy | środowisko testowe cudzego systemu, z którym się integrujesz | deweloperzy; analityk przy czytaniu API | „w sandboxie płatność zawsze przechodzi" |
Kilka zwrotów, które nie są nazwami środowisk, ale bez nich nie da się czytać rozmowy. „Niższe środowiska" (lower environments) to wszystko poniżej produkcji. „Promocja" albo „przerzucenie wyżej" to przeniesienie tej samej wersji dalej w łańcuchu. „Odświeżenie" (refresh) to wgranie na środowisko testowe świeżej kopii danych z produkcji, po anonimizacji, jeśli w grze są dane osobowe. Skrót UAT ma dwa znaczenia, fazy i środowiska, i to rozróżnienie znajdziesz w haśle o UAT.
Czym różni się środowisko testowe od stagingu?
Odpowiedź zależy od firmy i to nie jest wykręt. W większych organizacjach zwykle rozdziela się je na dwa miejsca (obserwacja z projektów, nie reguła). Środowisko testowe dostaje zmiany wcześnie i często, testerzy pracują na nim codziennie. Staging jest kopią produkcji, na którą trafia dopiero wersja kandydująca do wydania, i robi się na nim ostatnie, krótkie sprawdzenie przed wgraniem na prod, w stylu smoke testu. W małym zespole jedno środowisko pełni obie role. Lista DoD z lekcji o DoR i DoD w naszym minikursie o historyjkach mówi to jednym tchem: „funkcja wdrożona na środowisko testowe (staging)", co sugeruje, że tam to jedno miejsce.
Dla analityka ważniejsze od nazwy jest to, co dane środowisko odwzorowuje. Staging z prawdziwą konfiguracją integracji i zanonimizowaną kopią danych powie Ci więcej niż „test" z pustą bazą, niezależnie od tego, jak je nazwano.
Co analityk musi ustalić o środowisku testowym, zanim zaplanuje testy?
Góra hasła mówi, gdzie analityk zderza się ze środowiskami: przy planowaniu UAT i przy specyfikowaniu integracji. Tu jest lista pytań do zadania, zanim wpiszesz cokolwiek do planu testów. Każde ma adresata, bo „ktoś z IT" adresatem nie jest.
| Pytanie | Po co je zadajesz | Kto zwykle zna odpowiedź |
|---|---|---|
| Ile jest środowisk i które z nich jest do testów akceptacyjnych? | żeby scenariusze UAT nie wylądowały tam, gdzie równolegle testuje QA i co godzinę wchodzi nowa wersja | lider testów, osoba od wdrożeń |
| Które integracje są prawdziwe, a które atrapy? | atrapa bramki SMS nie wyśle wiadomości, więc scenariusz „pacjent dostaje przypomnienie" sprawdza się inaczej niż na produkcji | architekt, deweloper od integracji |
| Skąd są dane i czy przeszły anonimizację? | bez realistycznych danych testy nic nie wykryją, a kopia produkcji z danymi osobowymi łamie RODO; reguły w haśle o danych testowych | administrator danych, inspektor ochrony danych |
| Jakie konta i role testowe istnieją? | scenariusz rejestratorki wymaga konta z jej rolą, bo administrator widzi wszystko | osoba utrzymująca środowisko |
| Która wersja tam stoi i kto ją wgrywa? | testowanie wersji sprzed trzech tygodni daje wynik o systemie, którego już nie ma (druga pomyłka z definicji wyżej) | deweloper od wydań, lider testów |
| Kiedy środowisko jest dostępne i kto może je zepsuć? | wgranie nowej wersji w środku UAT unieważnia połowę wyników | osoba od wdrożeń |
| Jak zgłosić, że środowisko nie działa? | „nie działa" to blokada testów, nie defekt systemu: zgłaszasz ją osobie utrzymującej środowisko i zapisujesz w dzienniku testów jako blokadę | lider testów |
Odpowiedzi wpisz do planu testów, w sekcji o środowiskach i danych. Jeśli ktoś mówi, że to szczegół techniczny, przypomnij, że pierwsza pomyłka z definicji wyżej, testowanie na produkcji, zaczyna się dokładnie w chwili, gdy nikt nie wie, na którym środowisku ma testować.
Gdzie środowisko testowe pojawia się w dokumentach analityka?
W większej liczbie miejsc, niż sugeruje nazwa. Poniżej sześć takich miejsc z naszych lekcji i wpisów.
Założenia w wycenie. W lekcji o modelach rozliczeń założenie „środowisko testowe po stronie klienta gotowe przed startem developmentu" figuruje w wycenie ze stałą ceną obok terminów dostarczenia treści i logotypów. Jeśli klient środowiska nie dostarczy, założenie upada, a to jest podstawa do wniosku o zmianę, nie do cichego przesuwania terminu.
Estymacja. Ten sam mechanizm wraca przy szacowaniu: podajesz liczbę dni, zakładając, że dokumentacja API jest aktualna i że dostęp do środowiska testowego dostaniesz do piątku. Wpis o estymacji w analizie biznesowej pokazuje, jak takie założenie zapisać obok liczby, żeby zmiana estymaty nikogo nie zaskoczyła.
Definicja ukończenia. Punkt „funkcja wdrożona na środowisko testowe" najłatwiej docenić po wpadce. W minikursie o historyjkach wygląda ona tak: deweloper na demie mówi „przełożenie wizyty zrobione", Marek, biznesowy właściciel produktu, klika, działa. Potem wychodzi, że funkcja nigdy nie trafiła na środowisko testowe rejestratorek i nikt nie sprawdził, czy stary termin wraca do puli. Jak zbudować DoD, w którym taki punkt ma sens, opisuje wpis o Definition of Done i Definition of Ready.
Wymagania niefunkcjonalne. Wymaganie, że numer karty nie jest logowany, a w logach jest maskowany do ostatnich czterech cyfr, ma w naszej lekcji o wymaganiach niefunkcjonalnych pod integracje osobną kolumnę z metodą weryfikacji: audyt logów na środowisku testowym. Środowisko jest tu miejscem dowodu. Bez niego wymaganie zostaje deklaracją. Jak pisać takie wymagania razem ze sposobem sprawdzenia: wymagania niefunkcjonalne.
Plan przełączenia. W lekcji o monitorowaniu i doskonaleniu wydajności analizy z kursu Wprowadzenie do analizy biznesowej, na przykładzie wdrożenia systemu magazynowego, jeden z rezultatów pracy analityka brzmi: plan i lista kontrolna przełączenia, przetestowane na środowisku testowym co najmniej dwa tygodnie przed uruchomieniem. Próba generalna migracji na produkcji nie istnieje.
Umowa i dane. Lekcja o NDA i danych klienta daje zasadę minimalizacji: jeśli analiza nie wymaga produkcji, proś o zanonimizowaną próbkę albo o środowisko testowe. Zmniejszasz zakres umowy powierzenia i własną odpowiedzialność. Podstawy opisuje hasło RODO, a sprawdzić się możesz w teście wiedzy z RODO i compliance dla analityka.
Co to jest sandbox dostawcy i czym różni się od Twojego środowiska testowego?
Gdy system łączy się z cudzym API (operator płatności, bramka SMS, węzeł krajowy do logowania), dostawca często udostępnia własne środowisko testowe, nazywane sandboxem. Sandbox leży poza Twoim łańcuchem środowisk, u dostawcy i na jego regułach: testowe klucze, testowe karty, które „zawsze przechodzą", limity wywołań, czasem zachowanie inne niż na produkcji dostawcy.
Dla analityka sandbox ma jedno zastosowanie, którego nie zastąpi żadna dokumentacja: zdobycie prawdziwej odpowiedzi. W lekcji o tym, czym jest API, drugi krok analizy integracji brzmi: poproś dostawcę o dostęp do środowiska testowego i wyślij przykładowe żądanie w Postmanie. Dopiero z prawdziwą odpowiedzią w ręku wiesz, jakie pola wracają i w jakim formacie. Wpis API dla analityka rozwija temat integracji z tej perspektywy, a hasło API porządkuje pojęcia.
Cudze środowisko bywa też źródłem rozjazdów w estymatach. W ćwiczeniu z lekcji o planning pokerze historyjka o logowaniu pacjenta przez Profil Zaufany dostaje trzy różne wyceny: developerka frontendu widzi przycisk i przekierowanie, backendowiec widzi integrację z węzłem krajowym, środowisko testowe i certyfikaty, a tester pyta, jak to w ogóle testować bez prawdziwych tożsamości. Każde z tych spojrzeń jest prawdziwe i każde widzi inny kawałek tego samego środowiska. Taki rozjazd jest dla analityka sygnałem do rozmowy; więcej w haśle planning poker.
Jak czytać „zrobione", gdy w grze jest kilka środowisk?
Słowo „zrobione" bez nazwy środowiska nic nie znaczy. „Działa u mnie" znaczy: na komputerze dewelopera. „Jest na teście" znaczy: testerzy mogą zacząć. „Na UAT-cie nie ma tej wersji" znaczy: biznes testuje coś starszego, niż zespół myśli. Każde z tych zdań opisuje inny stan projektu.
Dwa nawyki, które to porządkują. Pierwszy: w zgłoszeniu defektu środowisko i wersja mają własne pole; hasło o defekcie pokazuje szablon zgłoszenia, w którym „Środowisko" ma własną linię. Drugi: przegląd sprintu robi się na środowisku testowym, na scenariuszu z pracy. W lekcji o przeglądzie i retrospektywie zespół MediFlow pokazuje odwoływanie wizyt właśnie tak, na środowisku testowym i na prawdziwym scenariuszu, i dopiero wtedy kierowniczka przychodni zauważa przypadek, którego nikt wcześniej nie zgłosił. Środowisko, na którym się pokazuje, decyduje o tym, co ludzie zobaczą.
Czy analityk potrzebuje własnego dostępu do środowiska testowego?
Tak, z trzech powodów. Po pierwsze, weryfikacja kryteriów akceptacji. Fragment DoD zespołu MediFlow z lekcji o artefaktach Scruma brzmi: „kryteria akceptacji zweryfikowane na środowisku testowym", a w nawiasie pada pytanie „kto weryfikuje?" i odpowiedź z imienia: najczęściej Ania - w materiałach o MediFlow to analityczka biznesowa zespołu (minikurs o historyjkach obsadza ją jako Annę, BA). W Twoim zespole to imię powinno być Twoje. Bez dostępu ten punkt DoD wykona za Ciebie ktoś, kto kryteriów nie pisał. Po drugie, przygotowanie UAT. Scenariusze trzeba przejść samemu, zanim dostaną je użytkownicy, inaczej pierwszy dzień testów akceptacyjnych schodzi na odkrywaniu, że konto testowe nie ma uprawnień. Jak to zorganizować, opisuje wpis o testach akceptacyjnych UAT. Po trzecie, czytanie cudzego API w sandboxie, o którym wyżej.
Dostęp nie oznacza uprawnień administratora. Konto z rolą użytkownika biznesowego, na środowisku, które nie jest produkcją, wystarcza do dwóch pierwszych i mieści się w zasadzie minimalizacji z lekcji o NDA. Do sandboxa dostawcy potrzebujesz testowych kluczy od dostawcy - poproś o nie razem z deweloperem od integracji.
Jeżeli chcesz przećwiczyć tę część roli, załóż darmowe konto - w wersji bezpłatnej dostajesz pierwszą lekcję każdego kursu, trzy podejścia do testów w miesiącu i plan na 30 dni.
Gdzie iść dalej
- Testowanie systemowe i testowanie integracyjne - co dzieje się na środowisku testowym, zanim wejdzie biznes.
- Smoke testing - kilkanaście minut po każdym wdrożeniu na test albo na produkcję.
- Continuous Integration i DevOps - kto i jak wgrywa wersje na kolejne środowiska.
- Diagram wdrożenia - rysunek, z którego wyczytasz, gdzie fizycznie stoi każde środowisko i jego dane.
- Testowanie wymagań - weryfikacja, zanim cokolwiek trafi na jakiekolwiek środowisko.