Większość z nas pewnie pamięta, jak mBank wysłał wiadomości zawierające testowe dane do klientów banku. Zrzut wiadomości był udostępniony szeroko, mBank również odniósł się do sytuacji. Postanowiłem się pochylić nad tematem i opowiedzieć wam małe co nieco na temat danych testowych, ponieważ wydaje mi się, że to zagadnienie jest jednym z ważniejszych w świecie testów.
Dane testowe – definicja.
Zgodnie z definicją, którą znaleźć możesz znaleźć w „Słowniku wyrażeń związanych z testowaniem”:
Dane, które istnieją (przykładowo w bazie danych) przed wykonaniem testu, i które mają wpływ na testowany moduł lub system, lub na które wywiera wpływ testowany moduł lub system.
Jak widzisz dane testowe, są to dane przechowywane przykładowo w bazie danych. Sięgamy po nie w celu przetestowania funkcjonalności i sprawdzenia, czy działa ona poprawnie.
Jestem fanem gier komputerowych. Dlatego przykład tego, jak możemy wykorzystać dane testowe, omówię w kontekście gry Football Manager. Jest to gra symulująca prowadzenie drużyny piłkarskiej. Wcielamy się w trenera zespołu piłkarskiego.
Jako trener mam wgląd w dane piłkarza takie jak imię, nazwisko, narodowość, parametry fizyczne takie jak wzrost, waga, szybkość, parametry czysto piłkarskie oraz psychologiczne.
Gdybym jako tester miał za zadanie przetestowanie tej gry, jednym z zadań, jakie bym sobie wyznaczył, byłoby stworzenie pliku lub bazy danych zawierających dane piłkarzy. Jednym słowem, żeby przetestować taką aplikację, musimy stworzyć kawał pliku zawierający bardzo dużo zmiennych. Już nie wchodzę w kwestie testów wartości brzegowych. Tego, że piłkarz może się rozwijać itp. itd.
Tworzenie danych testowych może prowadzić do utworzenia bardzo skomplikowanego pliku, jeśli weźmiemy w nich pod uwagę bardzo wiele zmiennych, zależnych od siebie w różny sposób.
Jakie warunki można brać pod uwagę podczas tworzenia danych testowych?
- Długość przyjmowanych znaków z zakresu od x do y.
- Typ danych, jakie przyjmuje pole (tylko litery, liczby).
- Jakich danych pole nie powinno przyjąć.
- Czy to pole łączy się logicznie z innym polem i mogą mieć tylko takie, a nie inne dane?
Tak naprawdę tutaj tych zmiennych może być całkiem sporo i nie wiem, czy nawet gdyby to było moim celem to, czy udałoby mi się je wszystkie spisać, bo pewnie ktoś wpadłby na coś jeszcze i śmiało mógłby dopisać to do listy.
Jak tworzyć dane testowe?
Kojarzycie ten moment, kiedy wiecie, że wasza praca jest z góry skazana na porażkę, a mimo to próbujecie? Syzyfową pracą w branży IT jest tłuczenie jak tworzyć dane testowe.
Teraz pewnie część z was przeżywa spory szok „Jak to skoro to takie proste to, czemu trzeba coś tłuc w kółko do głowy TYM ludziom z wymarzonego IT”. Przyczyn jest kilka. Czasami chodzi o lenistwo, wyrobiony nawyk, jeszcze inni robią tak, nie inaczej bo inni tak robią.
Chodzi mi tu o tworzenie poprawnych danych testowych. Kto nie słyszał o danych testowych „dupa dupa”, niech pierwszy rzuci kamieniem.
Dane testowe powinny być dobrej jakości.
Przejdźmy do powodów. Dlaczego nie warto używać pozornie śmiesznych danych testowych? Powodów jest kilka, ja przytoczę dwa.
- Od czasu do czasu możemy mieć konieczność pochwalenia się aplikacją naszpikowaną „dupa dupa” naszemu klientowi. Wyczyszczenie takiej bazy danych może kosztować bardzo dużo czasu. Czasami prościej jest zaorać bazę danych, a gorzej, jeśli nie możemy tego zrobić.
- Możemy się pomylić ze środowiskami i puścić testy na produkcji. W takim wypadku naszą wtopę zobaczy dużo osób. No, chyba że podchodzimy do tego na zasadzie sławy – jakby nie było w tym momencie flesze będą skierowane na nas. 😀
Przykład z mojego podwórka
Pozwolę sobie opisać Wombo Ccombo, jakie mi się zdarzyło przy okazji pracy nad jednym projektem. W tym projekcie wyjątkowo pracowałem po stronie odbiorcy aplikacji. Koledzy testerzy od strony dostawcy przesłali nam dane testowe, które zawierały zdanie „Twoja stara miesza bigos łokciem”.
Zdanie to było częścią maila, jakie aplikacja wysłała do mnie i innych osób zaangażowanych po stronie klienta. Zapewne się domyślacie, że moje nastawienie, jak i osób, które otrzymały tego samego maila, nie było takie jak na początku naszej współpracy. Sytuacja została wyjaśniona, nie było żadnych zgrzytów. Po obu stronach byli testerzy i rozumieliśmy, że mogło się zdarzyć. Co, jeśli byłyby to testy akceptacyjne i osoba decydująca o odbiorze aplikacji otrzymałaby takiego e-maila?
Teraz już pewnie widzicie, że wiadomości wysłane przez mBank nie były aż taką wtopą, bo zawsze mogło być gorzej.
Jakie powinny być zatem dane testowe?
Napisałem, jakie są złe praktyki tworzenia danych testowych. Jak w takim razie podejść do stworzenia tych dobrych? Dużo tu zależy od aplikacji, jaką mamy testować, bo tak jak wyżej wspomniałem tych czynników, jakie dane przygotowujemy, a jakie będziemy wyświetlać w aplikacji może być bardzo wiele ze względu na złożoność aplikacji i możliwości przyjmowanych danych przez system.
Jednym z ważniejszych elementów stworzonych danych ze względu na to, że czasami musimy ich tworzyć naprawdę dużo, jest ich czytelność. Co za tym idzie, lepiej się czyta „Jacek Kowalski z Poznania” niż „ dsafd zxcvczxv, zxcvcxzvcvzxcvcxz”, zwłaszcza jeżeli takich Jacków stworzymy 10-15.
W tworzeniu danych testowych mogą nam pomóc różnego rodzaju generatory danych. Uwaga! Nie wszystkie działają super, postaram się zrobić o tym wpis w jakimś sensownym czasie. Przykładowym generatorem danych jest strona https://danetestowe.pl/.
Kolejną rzeczą powiązaną z czytelnością danych jest sensowność tych danych. W mojej opinii każdy test powinien być robiony po coś i tak samo powinno być z tworzonymi danymi. Każda z nich powinna dawać nam odpowiedź na zadane w teście pytanie np. „jak aplikacja się zachowa, gdy przechowuje dane poprawne w poprzedniej wersji aplikacji, ale po update będą one niepoprawne”.
To są takie moje drobne rady wynikające z doświadczenia przy tworzeniu danych testowych. 🙂
Powodzenia
Waldemar
