Firma zamawia przypomnienie o płatności wysyłane mailem. Wykonawca chce zobaczyć, jak wygląda wiadomość, więc sprawdza funkcję na systemie, na którym firma pracuje. Klika „wyślij” i przypomnienie dostają prawdziwi klienci, także ci, którzy zapłacili tydzień temu. Potem są telefony i przeprosiny.

Bywa też ciszej. Faktura próbna zajmuje numer w numeracji, a po miesiącu ktoś pyta, skąd w kartotece klient „asdf”. Śmieci po testach kosztują mniej niż mail do klientów, ale ktoś musi je znaleźć i wyjaśnić, a do tego czasu raporty pokazują nieprawdę.

Poniżej najczęstsze pytania o to, jak testować bez takich przygód.

Gdzie w ogóle powinno się testować?

Na osobnej wersji testowej. Ma własny adres, jest schowana za hasłem i nie pokazuje się w wyszukiwarkach. Hasła ma inne niż system, na którym pracuje firma, więc dostęp do testu niczego więcej nie otwiera. Gdzie trzymać hasła i jak je zmieniać, piszemy w artykule Hasła, które zostają po ludziach. Nowych rzeczy nie wypróbowuje się na prawdziwym systemie. Eksperyment, który coś tam zepsuje, zatrzymuje pracę całej firmy.

Czy test może korzystać z prawdziwych danych?

Może, i często daje to najlepszą próbę. Prawdziwe dane mają błędy i nietypowe przypadki, których nie wymyśli nikt, kto pisze dane testowe. Kopia to jednak te same dane osobowe w drugim miejscu. Dlatego wersję testową chroni się tak samo jak prawdziwy system, a kopię robi się wtedy, gdy jest potrzebna. Tam, gdzie dane są szczególnie wrażliwe, lepiej użyć danych wygenerowanych, nawet jeśli próba jest przez to trochę mniej prawdziwa.

Czy kopię da się zrobić bez danych osobowych?

Tak, i to dobry kompromis. Przy kopiowaniu dane osób zamienia się na zmyślone: imiona, nazwiska, e-maile, telefony i adresy. Zostaje ich budowa, czyli długość, format i polskie znaki, więc nietypowe przypadki dalej wychodzą w testach. Ważne, żeby robiła to stała procedura uruchamiana przy każdej kopii. Ręczne poprawki po fakcie zależą od tego, czy ktoś pamiętał.

A jeśli wykonawca skopiuje bazę na swój komputer?

Wtedy dane osobowe klientów są w miejscu, nad którym firma nie ma żadnej kontroli. Laptop może zginąć, a kopia trafić na prywatny dysk w chmurze. Za dane klientów odpowiada przy tym firma. Najlepiej ustalić na początku, czy dane firmy mogą w ogóle opuścić jej serwer, i zapisać to w umowie.

W którą stronę mogą płynąć dane?

Tylko z prawdziwego systemu do testu. Nigdy odwrotnie. Wtedy nic, co ktoś wpisał na próbę, nie trafi przypadkiem do danych, na których pracuje firma. Kopię robi się na wyraźne polecenie, nigdy automatycznie.

Jak nie wysłać maila do klientów z wersji testowej?

Kopia prawdziwych danych ma prawdziwe adresy klientów. Dlatego zanim powstanie pierwsza kopia, trzeba ustalić, czy i dokąd wersja testowa może cokolwiek wysłać. Dotyczy to maili i wiadomości, ale też połączeń z bankiem czy urzędem. Przy połączeniach z systemami państwowymi korzysta się z ich środowisk testowych i wymyślonych danych.

W jakiej kolejności wprowadza się zmianę?

Najpierw na komputerze wykonawcy, na danych wygenerowanych, potem na wersji testowej, na końcu w prawdziwym systemie. Za każdym razem zaczyna się od małej próbki. Polecenie, które coś zmienia w danych, najpierw pokazuje, co zmieni, a zmienia dopiero na wyraźne potwierdzenie. Jak w ten sposób zmienić dane w systemie, na którym ludzie właśnie pracują, opisujemy w artykule Wdrożenia bez przestojów.

Kto sprząta po testach?

Ten, kto testował. Testy automatyczne mogą zakładać własną, tymczasową bazę i usuwać ją na koniec. Wersję testową po próbach odświeża się z anonimizowanej kopii, żeby nie zostały ślady, które ktoś kiedyś weźmie za prawdziwe dane.

Od czego zacząć?

Od jednej rozmowy, zanim powstanie pierwsza kopia danych. Trzeba w niej ustalić, gdzie stoi wersja testowa, czy dane firmy mogą opuścić jej serwer i czy z testu może wyjść cokolwiek do klientów, banku albo urzędu. Najlepiej, żeby odpowiedzi trafiły do umowy.