Agile BI – TDD

Data: 2015-07-19
Autor: Sebastian Konkol
Agile BI – TDD

W projektach informatycznych realizowanych w trybie agile wykorzystywane są praktyki pozwalające na skuteczną realizację takich projektów. Pośród praktyk, które mają „najwyższe notowania” występuje TDD (Test-Driven Development). Czy w projektach BI także można stosować taką praktykę?

Podstawą praktyki TDD jest tworzenie modułów oprogramowania w trybie, w którym – zanim napisana zostanie pierwsza linia kodu modułu – tworzony jest zbiór testów weryfikujących poprawność działania tego modułu. Testy te są automatyzowane, aby pełną weryfikację poprawności działania modułu można było przeprowadzić w pełni automatycznie. Rzecz jasna, zanim moduł nie zostanie napisany, takie testy wykazują błąd, ale w miarę powstawania modułu testy zaczynają być użyteczne. Wraz z rozbudowywaniem modułu pojawia się coraz więcej takich testów.

Tworzenie testów wraz z tworzeniem oprogramowania ma także głębszy sens filozoficzny. Wymagania mówią, co ma robić moduł. Testy natomiast mówią, jakie jest oczekiwane zachowanie modułu. Opis testów jest więc komplementarny do opisu wymagań – razem dają znacznie większe zrozumienie tego, jak powinien „wyglądać” moduł oprogramowania, aby spełniał oczekiwania.

W projektach BI najważniejszą rzeczą są dane – źródłowe i wynikowe. Im bardziej złożony charakter projektu BI, tym więcej danych należy przetwarzać – danych pochodzących z różnych źródeł, podlegających własnym cyklom życia, często niezsynchronizowanym z innymi. Jeśli więc chcemy oceniać jakość wyników realizacji projektu BI, musimy patrzeć na dane. Ogólny „przepis” na stosowanie TDD w projekcie BI jest następujący. Wiemy, w jakich strukturach danych mają być przechowywane dane będące wynikiem przetwarzania. Można więc pisać testy (np. w zapytania SQLu) przetwarzające dane w tych strukturach. Można zacząć od weryfikacji wypełniania atrybutów obowiązkowych, dziedzin zmiennych czy zgodności ze słownikami. W następnym kroku można dodawać testy dotyczące powiązań między poszczególnymi atrybutami. W jeszcze kolejnym można tworzyć już zaawansowane testy spełniania złożonych reguł biznesowych. Każdy taki test daje się łatwo automatyzować, więc zbiór testów staje się merytoryczną podstawą środowiska weryfikacji jakości danych. Po każdej zmianie oprogramowania przetwarzającego dane można uruchomić pakiet testów, aby sprawdzić, czy wprowadzone zmiany zapewniają wykonanie tego, co miały zrobić i czy czasem nie popsuły czegoś, czego popsuć nie miały.

Takie podejście do budowy rozwiązań BI ma jednak jeszcze jedną ciekawą cechę. Wraz z rozbudową testów rozbudowywane jest zrozumienie danych i zależności między danymi. Każdy projekt BI jest w pewnej części projektem badawczo-odkrywczym. Na początku wydaje się, że wiemy o danych źródłowych wszystko. Po kilku próbach pracy z danymi okazuje się jednak najczęściej, że jest wiele przypadków „brzegowych”, w których dane wyglądają zupełnie inaczej, niż – wydawałoby się – powinny. Budowanie testów w trybie TDD daje możliwość weryfikacji takich sytuacji i odróżniania znanych przypadków brzegowych od błędnych danych. Każdy taki zaawansowany test wskazuje na rosnące zrozumienie danych, zależności i reguł rządzących danymi.

W tym rozumieniu, testy wytworzone w ramach TDD mogą być rozbudowywane w ramach przygotowań do akceptacji rozwiązania BI (testy akceptacyjne, UAT), w dużej części mogą być wykorzystane dla prowadzenia bieżącej oceny jakości danych, już po produkcyjnym uruchomieniu systemu BI. Myślę o tym podejściu jak o pewnej zmianie paradygmatu, w którym ten sam mechanizm może być wykorzystywany jako precyzyjny pomiar jakości rozwiązania BI w całym cyklu życia takiego systemu.

Pozostaw komentarz