1. Samochodem przez autostradę - miernik to za mało
Jedziesz samochodem po autostradzie, jako pasażer. Prędkościomierz wskazuje 60 km/h. Jedziesz za wolno, więc prosisz kierowcę o przyspieszenie – spieszysz się na spotkanie i zależy Ci, by dotrzeć na czas. Po chwili okazuje się, że samochód zwolnił – jedziesz już 40 km/h.
Patrzysz za okno i okazuje się, że zbliżasz się do wypadku. Jeżeli samochód przyspieszy, to stanie się częścią karambolu – tak więc kierowca zwalnia.
Powyższa sytuacja jest typową sytuacją z życia codziennego. Dlaczego zatem opisuję ją w kontekście podejmowania decyzji i mierników?
2. Podejmowanie decyzji
Wpierw prędkościomierz (miernik) pokazał 60 km/h (pomiar). Jeśli jesteś na autostradzie (kontekst), wiesz, że możesz jechać 110 km/h (punkt odniesienia) i bardzo zależy Ci by nie spóźnić się na spotkanie (efekt który chcemy osiągnąć), więc decydujesz się przyspieszyć (decyzja).
Jednak wypadek (uaktualniony kontekst) sprawił, że decyzja może być błędna. W nowym kontekście przyspieszenie sprawi, że możesz w ogóle nie dojechać (efekt). Czas na priorytetyzację - spóźnienie się na spotkanie (efekt) okazuje się być mniejszym problemem niż uczestniczenie w wypadku (efekt).
W świetle nowych priorytetów trzeba zatem zmienić oczekiwany punkt odniesienia – nie 110 km/h a 5 km/h. Tak więc trzeba zmienić decyzję – zamiast przyspieszyć, trzeba zwolnić aż pomiar będzie zbliżony do nowego punktu odniesienia.
Powyższy przykład jest kwintesencją podejmowania decyzji w oparciu o mierniki.
- Miernik dostarcza pomiar (prędkościomierz -> 60 km/h)
- Kontekst dostarcza punkt odniesienia (autostrada -> 110 km/h)
- Oczekiwany efekt dostarcza pytanie („czy jadąc 60 km/h zdążę na spotkanie?”)
- Połączenie powyższych pomaga nam podjąć decyzję („jeśli jadąc 60 km/h nie zdążę na spotkanie a mogę jechać 110 km/h, powinienem przyspieszyć”)
Nie wygląda to na szczególnie trudne, prawda?
Dlaczego zatem w firmach zbieramy setki różnorodnych danych, a jednak rzadko podejmujemy decyzje w oparciu o taką technikę jak w powyższym przykładzie?
Odpowiedź kryje się w wikipedii pod hasłem „Prędkościomierz”.
3. Co mierzy prędkościomierz?
Jakbym zadał pytanie „co mierzy prędkościomierz” najprawdopodobniej usłyszałbym coś w stylu „to oczywiste - prędkość. Ilość kilometrów na godzinę”.
W praktyce, za wikipedią: „Działają one [prędkościomierze elektryczne] za pomocą czujnika obrotów, który dostarcza impuls wraz z zakończeniem pełnego obrotu, a komputer przekształca przerwę między impulsami na wynik w postaci cyfr”.
Innymi słowy, prędkościomierz mierzy częstotliwość obrotów na osi koła. Dopiero potem jest to przeliczane na coś, co pomoże nam podjąć decyzje – na kilometry na godzinę.
Zgodnie z teorią informacji, prędkościomierz przekształca dane w informacje.
I to właśnie jest odpowiedź na pytanie „dlaczego firma zbiera tak dużo materiałów i tak trudno je wykorzystać do podjęcia decyzji”. Każda firma zbiera nieprawdopodobnie dużo danych, ale niekoniecznie przekształca je w informacje wspomagające podejmowanie decyzji.
Co więcej, jeśli nie wiesz jaki efekt chcesz uzyskać to nie jesteś w stanie podjąć decyzji nawet, jeśli masz przed oczami wszystkie potrzebne informacje. W zależności od efektu i decyzji potrzebny Ci jest inny zbiór informacji. Udowodnię to za moment na prostym przykładzie.
Swoją drogą, jeśli interesuje Cię podział na linii dane – informacje - wiedza to polecam ten artykuł gdzie jest to dobrze wyjaśnione.
4. Przykład decyzji – gdzie przyłożyć energię podczas testowania?
4.1. Gdzie przyłożyć energię?
Wyobraź sobie, że dowodzisz zespołem Quality Assistance w firmie programistycznej. Niedługo jest demo dla ważnego klienta. Od tego dema zależy czy tego klienta w ogóle pozyskacie. Masz 10 godzin pracy QA; do przetestowania całej aplikacji potrzebujesz około 200 godzin.
Gdzie przyłożyć te 10 godzin, by dostać maksymalny zwrot z inwestycji? Co należy sprawdzić? Gdzie należy spojrzeć przede wszystkim?
Spójrzmy na przykładową posiadaną przez nas miarę jakości.
„Code Coverage” (czyli pokrycie kodu testami) wynosi 75%. Ale wiesz też, że wszystkie najważniejsze obszary są pokryte – nie są pokryte Properties (Gettery i Settery). Czyli testy pokrywają większość najważniejszych funkcji aplikacji i większość warunków brzegowych.
Rozbijmy jednak to pokrycie kodu testami i zobaczmy, jak będzie to wyglądało wtedy.
4.2. Rozbicie pokrycia kodu testami na segmenty
95% funkcji biznesowych pokryta jest na poziomie testów jednostkowych i komponentowych, ale udało się wykryć, że jeden ze świeżo dopisanych modułów (o nazwie Krokus) ma jedynie 30% pokrycia kodu.
Dodatkowo, pokrycie kodu testami w tej firmie sprawdza jedynie poszczególne komponenty ale nie integrację między nimi (analogia: sprawdzamy osobno silnik, koła, skrzynię biegów, ale nie sprawdzamy czy one pasują do siebie jako samochód).
Jeżeli w przeszłości rzadko pojawiały się błędy w obszarach pokrytych testami, to mamy dwa podstawowe obszary ryzyka – integracja (czy wszystko działa jako całość) i moduł Krokus, który ma bardzo niskie pokrycie kodu testami. Te dwie rzeczy są kandydatami na przyłożenie większej uwagi.
Nadal jednak nie wiemy gdzie przyłożyć energię. To wszystko jest pułapką.
Nie wiemy bowiem na czym klientowi najbardziej zależy – co klient chce zobaczyć na demo. A jeśli nie wiemy jaki efekt chcemy uzyskać to nie wiemy co przede wszystkim musimy sprawdzić. Nadal nie wiemy, gdzie przyłożyć energię.
Okazuje się, że moduł Krokus nie jest na tym demie istotny. Jego w ogóle tam nie ma. To demo ma dotyczyć zupełnie innego modułu (o pięknej nazwie Pierwiosnek).
Jeśli tak, to skupmy całe 10 godzin na module Pierwiosnek i integracji Pierwiosnka z całością aplikacji - niezależnie od jego pokrycia testami.
Nadal wiemy za mało. Nie wiemy co klient będzie chciał zrobić z modułem Pierwiosnek. Tak więc, żeby określić na czym warto się skupić musimy wpierw określić kontekst samego modułu Pierwiosnek. Czego od Pierwiosnka oczekuje klient. Jak to demo będzie wyglądać.
4.3. Moduł Pierwiosnek
Po rozmowie z osobami odpowiedzialnymi za demo i za tego klienta dowiadujesz się kilku istotnych informacji:
- Demo będzie robione w języku niemieckim (a Pierwiosnek nigdy nie był testowany w tym języku – nie wiadomo, czy tekst zmieści się w etykietach)
- Demo będzie wykorzystywało niestandardową konfigurację software, inną niż w głównej i dobrze przetestowanej aplikacji. Ta konfiguracja nie miała do tej pory testów integracyjnych.
- Klientowi zależy na prędkości działania aplikacji; jest w stanie zaakceptować błędy (bo wierzy, że da się je skorygować), ale zależy mu na szybkiej odpowiedzi aplikacji. Okazuje się, że kiedyś już się sparzył na innym dostawcy – rozwiązanie było nieakceptowalnie wolne.
Po dopytaniu co to znaczy „szybka odpowiedź aplikacji” otrzymujesz liczbę - około 600 milisekund.
Gdzie zatem należy przyłożyć energię przy testowaniu tej aplikacji by demo się udało?
- Trzeba upewnić się, że Pierwiosnek w ogóle będzie działał w typowych przypadkach na nieco niestandardowej konfiguracji aplikacji; nie był w ten sposób nigdy testowany. Tu jest największy obszar ryzyka - integracja. Powiedzmy, 50% czasu.
- Trzeba upewnić się, że przed demo Pierwiosnek na tej konfiguracji jest w stanie działać poniżej 600 milisekund na różnych zestawach danych. 30% czasu.
- Trzeba upewnić się, że Pierwiosnek będzie sensownie wyglądał po lokalizacji na język niemiecki. Jeśli nie wygląda dobrze, można zaprezentować odpowiedni podzbiór stron lub obiecać korektę błędów potem. 15% czasu.
- Pewną ilość energii można przeznaczyć na wyrywkowe sprawdzenie czy Pierwiosnek działa jak oczekiwano; czy testy pokrywające kod faktycznie sprawdzają to co powinny, by nie było nieprzyjemnych niespodzianek. 5% czasu.
I - co najważniejsze – możemy zignorować wszystkie pozostałe moduły jak i typową konfigurację. Ważniejsze od „co testować” jest „czego nie testować” by nie marnować czasu.
Jeżeli pytanie brzmi „Gdzie mam przyłożyć energię, by się upewnić że demo zadziała prawidłowo i mam jedynie 10 godzin pracy QA” to odpowiedź powinna zawierać te rzeczy, na których zależy klientowi.
Gdyby w Pierwiosnku był obszar istotny dla klienta o niskim stopniu pokrycia kodu testami, tam też skupilibyśmy swoją uwagę. Jako, że nie było – jedynie sprawdzamy główne przejścia wyrywkowo.
Zauważ, że to, co testujemy rozbiło się o definicję „demo zadziała prawidłowo”. Bez doprecyzowania tego fragmentu testowalibyśmy zupełnie coś innego niż chcieliśmy. Bartek napisał o tym poprzedni artykuł z tej serii.
Innymi słowy, nie wiedząc co robimy nie wiemy, jakie informacje są nam potrzebne do podjęcia właściwej decyzji.
5. Pułapka zbyt mocno zagregowanych danych
W większości znanych mi projektów informatycznych jest mierzone coś takiego jak „pokrycie kodu testami” z powyższego przykładu. Tragedia polega na tym, że te rzeczy są naprawdę przydatne, ale często wykorzystywane są źle.
Gdy podzieliłem „pokrycie kodu” w przykładzie na „pokrycie typów testów” i „pokrycie poszczególnych modułów” to byłem w stanie na podstawie tych informacji podjąć decyzję odnośnie tego, jak należy testować moduł Pierwiosnek.
Gdy miałem „pokrycie kodu” jako 75%, było to coś całkowicie bezużytecznego. Nic z tym nie mogłem zrobić i w żadnym stopniu mi nie pomagało.
Inny przykład – wyobraźmy sobie, że w firmie rotacja w skali roku spadła z 10% do 8%. Co to Ci pokazuje?
A teraz powiem, że rotacja wśród bardzo doświadczonych pracowników wzrosła z 10% do 30% (!!!) a rotacja wśród niedoświadczonych pracowników spadła z 10% do 5% - a jako, że niedoświadczonych jest dużo więcej, to zaciemniło rotację ogólnofirmową. Czy widzisz teraz tą samą sytuację w innym świetle?
Tak więc nie wystarczy posiadać danych. Trzeba umieć jeszcze te dane przekształcić w pożyteczne informacje i wyciągnąć z nich wiedzę mającą usprawnić podejmowanie decyzji.
6. Kiedy pomiar jest przydatny
Wróćmy do prędkościomierza, bo jest łatwiejszy do wyobrażenia sobie niż pokrycie kodu.
Co daje Ci pojedynczy pomiar? Np. 35 km/h? Nic.
35 km/h może oznaczać „przyspiesz” jeśli jesteś na autostradzie lub „gwałtownie zwolnij” jeśli jesteś w garażu. Tak więc by pojedynczy pomiar miał dla Ciebie wartość, musisz mieć do niego jakiś punkt odniesienia (np. 110 km/h na autostradzie). Tak więc pomiar z punktem odniesienia daje wartość.
Ale co zrobić, gdy nie masz punktu odniesienia? W takim wypadku możesz spojrzeć na serię pomiarów w czasie i zrobić z nich punkty odniesienia. Możesz stworzyć trend. Np. jesteś na autostradzie i jedziesz 30 km/h -> 50 km/h -> 70 km/h. Jest to informacja, że wszystko jest pod kontrolą.
Możesz też podzielić pojazdy na kategorie. Jeśli średnia prędkość na autostradzie to 100 km/h, ale pojazdy osobowe jadą średnio 120 km/h a ciężarowe jadą średnio 80 km/h to podzieliliśmy właśnie pojazdy na dwa segmenty. Bardzo ciekawe odpowiedzi dostajemy łącząc segmentację z trendami: jakie są trendy w różnych segmentach danej populacji.
Innymi słowy, samo posiadanie danych to za mało. Np. dane o rotacji czy pokryciu kodu mogą same w sobie nie być cenne – ale segmentowane trendy pokrycia kodu mogą dać interesującą informację.
Załóżmy, że masz zespół w którym wymienił się lider i nagle w module za który ten zespół odpowiada pokrycie kodu zaczęło drastycznie spadać. Powiedzmy, w ciągu 4 miesięcy pokrycie kodu testami spadło z 80% do 60%.
Jeśli mierzysz po prostu „globalne pokrycie kodu testami”, nie zauważysz tego – więcej, może się okazać, że globalnie pokrycie kodu wzrosło z 75% do 77%. Ale w tym jednym zespole doszło do katastrofy.
Właśnie takie wykorzystywanie danych pomaga w podjęciu decyzji. Dlatego naciskam – nie podejmuj decyzji na bazie „wszystkich danych”, skup się na wydobyciu cennych informacji z tych danych. Wyjdź od pytania, od konkretnej decyzji – i znajdź dane które rozwiążą Ci problem.
7. Podsumowanie
W zależności od tego jaką decyzję chcesz podjąć potrzebujesz innego zestawu informacji. Informacje czerpiesz z danych, między innymi przy użyciu mierników. Jakkolwiek zmierzyć da się wszystko, nie wszystko mierzyć warto – w zależności od decyzji do podjęcia masz inny kontekst tej decyzji.
Jeżeli chcesz zbierać dane, pojedynczy pomiar jest bezużyteczny. Albo połącz pomiary w trend albo znajdź konkretny punkt odniesienia. Warto też zwrócić uwagę na różne segmenty interesującej Cię populacji.
Po podjęciu decyzji dalej monitoruj sytuację. Jeżeli pomiary wskazują na to, że zbliżasz się do celu w satysfakcjonujący dla Ciebie sposób, to Twoja decyzja – Twoja interwencja - była udana. Jeżeli pomiary jednak wskazują na to, że nie zbliżasz się do celu w satysfakcjonujący dla Ciebie sposób to musisz się przeorientować i podjąć dalsze działania korygujące.
To wszystko na dzisiaj. Powodzenia!
