Dane testowe to dane przygotowane specjalnie do weryfikacji systemu: na tyle realistyczne, by testy odzwierciedlały produkcję, na tyle kompletne, by pokryć przypadki brzegowe, i na tyle bezpieczne, by nie łamać prawa.
Rola analityka jest tu większa, niż się wydaje. To BA wie, jakie scenariusze biznesowe system musi obsłużyć - więc to on powinien zdefiniować, co dane testowe mają pokrywać. Tester zaprojektuje przypadki testowe, ale listę sytuacji biznesowych wartych sprawdzenia zna ten, kto pisał wymagania.
Przykład z MediFlow - zestaw danych do testów rejestracji online musi zawierać m.in.: pacjenta z polskimi znakami i nazwiskiem dwuczłonowym (kodowanie, długość pól), próbę rejestracji drugiego pacjenta na ten sam PESEL (walidacja unikalności), wizytę o 23:59 i 0:00 (granica doby w raportach), dwóch pacjentów rezerwujących ostatni wolny slot równocześnie (race condition) oraz pacjenta bez numeru telefonu (co z przypomnieniem SMS?). Każdy z tych rekordów istnieje po coś - testuje konkretne wymaganie.
Teraz część prawna, w ochronie zdrowia bezwzględna: produkcyjne dane pacjentów nie mogą trafić na środowisko testowe bez anonimizacji. RODO nie zna wyjątku „ale tak szybciej". W praktyce stosuje się anonimizację (nieodwracalną - dane przestają być osobowe) lub generatory danych syntetycznych; pseudonimizacja to za mało, bo dane wciąż są osobowe.
Częsta pomyłka: testowanie wyłącznie na „Janie Kowalskim" z poprawnie wypełnionymi polami. Produkcja jest brudna - NULL-e, duplikaty, daty „01.01.1900", spacje na końcu nazwisk. Dane testowe, które tego nie odwzorowują, dają fałszywe poczucie bezpieczeństwa.
Pojęcia powiązane: przypadek testowy, anonimizacja, środowisko testowe, przypadki brzegowe.