Wiarygodność wyników testowania aplikacji zależy w dużej mierze od tego, w jakim stopniu dane testowe odpowiadają danym produkcyjnym.

Testowanie to jeden z najważniejszych etapów produkcji oprogramowania. Od jego wyników zależy, czy program będzie zachowywał się prawidłowo i działał zgodnie z oczekiwaniami w trakcie jego codziennego, biznesowego stosowania. Najlepiej byłoby zrobić testy w warunkach takich samych, jakie występują w procesie użytkowania i na rzeczywistych danych znajdujących się w firmowych zasobach.

Jakie dane wybrać?

Oczywiście, z wielu przyczyn jest to niewykonalne. Zazwyczaj więc szuka się sposobów sprawdzenia prawidłowości funkcjonowania aplikacji w oparciu o specjalnie przygotowany zestaw danych testowych, pobranych w mniej lub bardziej ograniczonym zakresie, z funkcjonującej w przedsiębiorstwie bazy. Nie jest to jednak zadanie łatwe. Pół biedy, gdy baza danych jest mała - wtedy rzeczywiście, bez większego problemu można wygenerować zbiór danych testowych odpowiadających danym produkcyjnym. Co natomiast zrobić, gdy baza danych jest duża lub bardzo duża? Trudno wówczas wygenerować bazę testową, która by zachowała wszystkie relacje i powiązania istniejące w bazie pierwotnej. A one są kluczowe dla sprawnego funkcjonowania przygotowywanej aplikacji.

Nie zawsze też firma zamawiająca oprogramowanie chce wypuścić z ręki jakiekolwiek dane znajdujące się w jej posiadaniu, nie mówiąc o tych, które uważane są za kluczowe czy wręcz strategiczne. Wtedy trzeba jeszcze dodatkowo zatroszczyć się o ich anonimizację. A ten zabieg jeszcze bardziej zaciera faktyczne relacje między poszczególnymi danymi i obiektami. Zagubiony zostaje również rzeczywisty rozkład danych.

Na dodatek bywa i tak, że kluczowe dla sprawnego działania aplikacji relacje między danymi zawarte są nie w samej bazie danych, lecz właśnie w obsługującej ją aplikacji. Sama znajomość struktury bazy i istniejących wewnątrz niej powiązań nie wystarczy. Dopiero aplikacja "wie", jakie dane z jakimi danymi mają być połączone dla właściwego zrealizowania określonego zadania.

Zawsze też pozostaje do rozstrzygnięcia pytanie o reprezentatywność danych do testowania: jak duża w stosunku do pierwowzoru ma być baza testowa, by zapewniała osiągnięcie miarodajnych wyników? Jaki odsetek danych pobranych do testowania będzie wystarczający do sprawdzenia rzeczywistych parametrów przygotowywanej aplikacji? Czy jeżeli będzie działała dobrze na 100 wybranych rekordach, to będzie działała tak samo również na całej bazie? Czy też, żeby mieć pewność, co do jej sprawności, trzeba poddać ją testowaniu na tysiącu, a może nawet na 50 tys. rekordów?

Znajomość połączeń

Inne podejście do przygotowywania danych testowych proponują twórcy pakietu Optim firmy IBM. Głównym jego elementem jest silnik relacji. Pozwala on na określenie, co z czym i w jaki sposób jest połączone - jaka dana z jaką daną, która tabela z którą tabelą itd. Co ważne, relacje są rozpoznawane na gruncie aplikacji, a nie samej bazy danych.

Optim "uczy się" relacji w odniesieniu do konkretnej bazy danych, która ma być podstawą do testowania aplikacji. Jeżeli mamy do czynienia z gotowymi rozwiązaniami bazującymi na systemach Oracle czy Siebel, to są dostępne gotowe pakiety do automatycznego rozpoznawania relacji. Gdy w grę wchodzi unikalne, własne oprogramowanie, to trzeba najpierw przygotować model obiektów biznesowych i powiązań między nimi. Potem wszystko też już odbywa się automatycznie.

Korzyści z zastosowania programu Optim widać wyraźnie, na przykład w sytuacji konieczności wykorzystania do testowania danych osobowych, które podlegają ścisłej ochronie. Testowanie na danych abstrakcyjnych nie jest efektywne, nie uwzględnia bowiem wszystkich niezbędnych warunków. Rozwiązaniem jest przeprowadzenie testów na danych anonimowych, ale przy zachowaniu wszystkich prawdziwych relacji występujących w rzeczywistej bazie z danymi osobowymi. To samo można zrobić w sytuacji, gdy w trosce o bezpieczeństwo swoich zasobów klient nie chce dać producentowi oprogramowania dostępu do żadnych autentycznych danych ze swojej bazy.

Oprócz funkcji anonimizacji Optim posiada także możliwość selekcjonowania danych do testowania. Można przygotować zestaw testowy obejmujący całą bazę, lub - w zależności od tego, co chce się testować - ograniczyć się tylko do określonych tabel czy pól. W każdym przypadku zostaną odzwierciedlone właściwe dla danej bazy i obsługującej ją aplikacji relacje i powiązanie między danymi. To pozwoli sprawdzić rzeczywiste parametry funkcjonowania tworzonego oprogramowania, zawczasu zauważyć występujące problemy i jeszcze w okresie produkcyjnym znaleźć sposoby ich rozwiązania.

Oczywiście, zawsze jeszcze pozostaje kwestia kosztów: czy opłaca się nabywać gotowe, dedykowane rozwiązanie do automatycznego przygotowywania danych testowych, czy też lepiej zlecić przygotowanie zestawu testowego administratorowi danych lub zdać się na własne, proste, przygotowane ad hoc narzędzie do generowania danych testowych z bazy. W tym ostatnim przypadku nie bez znaczenia będzie odpowiedź na pytanie o koszty utrzymania i rozwoju własnego narzędzia - szczególnie w sytuacji realizacji dużej ilości projektów.

Im większa baza i większy system do przetestowania, tym więcej zapewne argumentów na rzecz skorzystania z gotowego, specjalizowanego narzędzia. Taką decyzję każdy dział IT musi jednak podjąć we własnym zakresie. Najważniejsze, żeby udało mu się zapewnić wysoką jakość tworzonego na potrzeby biznesu oprogramowania.

Dla Computerworld komentuje Radosław Smilgin, współautor portalu testerzy.pl, członek Stowarzyszenia

Dane testowe muszą możliwie precyzyjnie odpowiadać danym produkcyjnym. Jest kluczowe, aby zachować dane w formacie, w jakim mogą pojawić się w rzeczywistym środowisku pracy aplikacji. Aby dane testowe odzwierciedlały środowisko pracy oprogramowania, ważne jest spisanie wymagań klienta oraz rozmowy z potencjalnymi użytkownikami. Oczywiście czasami wystarczą standardy. Dane do aplikacji księgowych będą zazwyczaj takie same. W żadnym przypadku nie można zapomnieć o znakach specjalnych. Większość narzędzi generuje dane w języku angielskim. Mogą się one okazać zupełnie niepotrzebne na polskim gruncie, ponieważ nie zawierają typowo polskich znaków "ą, ć, ę, ł, ń, ś, ó, ź".

Generowane lub tworzone dane testowe powinny pokrywać nie tylko pozytywne, ale i negatywne testy. Oczywiście, wszystkie dane mogą być w wymaganym przez aplikację formacie, ale nie sprawdzimy wtedy, jak aplikacja zachowa się, gdy dane nie zostaną wprowadzone poprawnie. Przykładowo, możemy założyć, że każdy użytkownik aplikacji wprowadzi datę swojego urodzenia w formacie "dd-mm-yyyy". Co więcej, poprzez specjalne mechanizmy możemy to nawet wymusić. Czy nasza aplikacja wychwyci jednak błąd daty "00-12-1990" lub "12-13-1990", jeśli nie sprawdzimy tego odpowiednimi danymi testowymi?

Dużą pokusą jest generowanie losowych ciągów znaków. Należy pamiętać o dużej nieadekwatności takich danych i ich niskiej przydatności. Czy adres email "[email protected]" w jakikolwiek sposób jest reprezentatywny dla większości adresów? Zdecydowanie nie.

Jest wiele narzędzi do generowania danych testowych. Każda szanująca się, komercyjna aplikacja do testowania oprogramowania ma wbudowany generator danych. Tak jest z narzędziami Rational, tak jest z narzędziami Visual Studio. Podobnie mamy niezliczone narzędzia open source do tworzenia danych. Niestety, w większości przypadków generowane są dane typowe dla języka angielskiego lub w formacie, który nie odpowiada założeniom testu.

Firmy powinny więc samodzielnie tworzyć i zbierać dane potrzebne do testów. Przygotowanie prostej aplikacji do generowania danych zajmuje zazwyczaj dużo krócej niż rozmowa o niej. Okazuje się, że raz przygotowana baza danych testowych przydaje się na bardzo długi czas, jeśli jest odpowiednio konserwowana. Dane testowe mogą pochodzić z różnych źródeł - mogą być pobrane z Internetu, np. baza imion; mogą być realnymi danymi, zniekształconymi w taki sposób, aby uniemożliwić identyfikację; mogą zostać wygenerowane, uwzględniając standardy językowe.