blog.testowka.pl

Archiwum wiadomości z Kwiecień, 2012

Do the right it

opublikowany przez 05, Kwi, 2012, w kategoriach Agile, Testowanie, Zarządzanie

Zbyt długo testowanie traktowane było jako oddzielna dziedzina procesów wytwarzania oprogramowania. Certyfikacje, szkolenia, proces, procedury, modele etc. – wszystko fajnie tylko pozostaje podstawowe pytanie: po co? Odpowiedź wydaje się być oczywista, potrzebujemy skomplikowanych modeli wytwarzania oprogramowania takich jak np. Model V bo standardowy Waterfall, gdzie testowanie było odseparowane od kodowania się nie sprawdzał. Szybko okazało się, że nie ma czasu na testy w Waterfallu – stąd pomysł na Model W będący rozwinięciem Modelu V, którego celem było przesunięcie testów jak najwcześniej – dzięki temu możemy równolegle testować i kodować. Wszystko fajnie. To działa! Ale…

Źródło: Wikipedia

Ale testowanie nadal zajmuje dużo czasu, programowanie zajmuje jeszcze więcej i… nadal pojawia się wiele błędów… Testujemy więc jeszcze więcej i jeszcze lepiej – ale to wymaga czasu. Wymyślamy więc różne metryki, które mają nam powiedzieć czy testujemy wystarczająco dobrze – pokrycie kodu, pokrycie wymagań etc. Zaczyna się zabawa w przesuwanie naszego targetu wewnątrz Żelaznego Trójkąta Managementu lub przy odrobinie szczęścia w Kwadracie zawierającym także jakość. Zgadzamy się więc na obniżanie naszych docelowych metryk wspomnianych powyżej lub nie zgadzamy się i manipulujemy czasem. Czasem zdarza się że trójką z płaskiego przybiera trzy lub więcej wymiarów zaginając czasoprzestrzeń – gdzie według raportów wszystko zostało dostarczone na czas i zostało odpowiednio przetestowane, ale… w rzeczywistości w kartce z naszym trójkątem pojawiło się wiele dziur.

Zaraz, zaraz o czymś zapomnieliśmy – scope – możemy manipulować jeszcze zakresem wytwarzanej funkcjonalności – dlaczego tego nie robimy? Bo Scope jest święty – podpisaliśmy kontrakt z klientem i musimy się z niego wywiązać. „Podpisaliśmy?” – ktoś z marketingu/sprzedaży/zarządu podpisał oczywiście nie pytając nas o zdanie – nieważne, stało się kontrakt podpisany i wszystko musi być dostarczone. „Wszystko” – słowo klucz, czy klient na prawdę potrzebuje „wszystkiego” co jest w kontrakcie? Zastanówmy się nad tym dlaczego „wszystko” jest w kontrakcie. Co by się stało gdyby klient chciał dodać coś do wymagań? Teraz pewnie się spodziewacie, że podłoże się oskarżając standardowe metodyki o to że nie można wprowadzać zmian w wymaganiach co oczywiście prawdą nie jest – mamy przecież coś takiego jak całe procesy i procedury zatytułowane „Change Managment” – czy też zarządzanie zmianą. Oczywiście, klient może zmienić wymagania ale kontrakt jest dwustronny więc będzie go to kosztowało więcej, mało tego zapewne wiele kosztowało będzie samo wprowadzenie zmian w dokumentacji i te wszystkie procedury i akceptacje przez wszystkich świętych… Jaki klient przy zdrowych zmysłach wpakował by się w zmianę wymagań? To wszystko zostało wymyślone po to by umożliwić ewentualne zmiany w wymaganiach ale by do nich maksymalnie zniechęcić. Co więc robi klient – klient głupi nie jest więc stara się z wyprzedzeniem zabezpieczyć ładując w wymagania „wszystko” co mu przyjdzie do głowy. Przy odrobinie szczęścia „wszystko” zostanie dostarczone i w tym co akurat będzie wartościowe nie będzie znaczących defektów.

Jim Johnson. The Standish Group International Inc. 2002.

Przez ostatnich kilkanaście lat coraz popularniejsze w „świecie Agile” i nie tylko stawało się stwierdzenie „Do it right” wskazujące na to by wszystko co robimy robić maksymalnie dobrze. Niestety to nie zawsze wystarczało, często dobrze oznaczało długo. Jakiś czas temu pojawił się nowy postulat obok starego „Do it right” coraz częściej pada stwierdzenie „Do the right it”. Jakość można polepszać nie tylko poprzez rozciąganie projektu w czasie (czy też rozciąganie czasu – co podobno jest możliwe). Zastanówcie się o ile mniej potrzeba by było testów gdybyśmy w ogóle nie dopuścili do wytworzenia funkcjonalności nadmiarowej? Zgodnie z zasadą Pareto 80% (potwierdzoną na rysunku obok) funkcjonalności będzie używana rzadko albo wcale co oznacza, że nie będzie zarabiać. O ile zmalała by ilość błędów gdyby funkcjonalności używanej nigdy i rzadko nie było? O ile skrócił by się czas przeznaczony na poprawki błędów w funkcjonalności nieużywanej?

Jak już wielokrotnie powtarzałem jakość nie wynika z testowania, nawet nie z jakości i ilości testowania. Testowanie jest wartościowym elementem weryfikacji jakości, ale na etapie testów, gdy znajdziemy błąd to jest już za późno – pierwotnie zaimplementowana funkcjonalność była słabej jakości, teraz możemy tylko to poprawiać, co jest dużo bardziej czasochłonne i trudniejsze. Pozostaje też pytanie co tak na prawdę będziemy poprawiać – czy po znalezieniu buga poprawiamy jakość czy tylko poprawiamy buga często wprowadzając jeszcze większe zamieszanie i obniżając jakość całości projektu. Mówi się o jakości wymagań i specyfikacji – super, tylko co jeśli ta nawet genialna i wyśmienita specyfikacja opisu wspomniane wyżej 80% funkcjonalności nie przynoszącej zysków? Jesteśmy ludźmi i popełniamy błędy, więc zapewne zaimplementujemy ich kilka a presja czasu prędzej czy później sprawi, że dbanie o jakość pójdzie w niepamięć. O wizji produktu i wyznaczaniu celów już pisałem więc powtarzać się nie będę, pozostaje kwesta jakości tych celów.

Zadanie domowe – spróbujcie dowiedzieć się ile z funkcjonalności nad którą pracujecie faktycznie jest/będzie używane w Waszych projektach. Jak się dowiedzieć – nie wiem, to Wasze projekty :). Będę wdzięczny za komentarze.

Dodaj komentarz więcej...