Pięć tajemnic sukcesu, czyli znów o testowaniu

10 lat testowania w Polsce

Podsumowanie

Jacek Fedorowicz  
Jacek Fedorowicz określił cel jednej ze swoich książki jako: "przez namolność do pedagogicznego sukcesu". Podzielam ten cel, bowiem droga, jaką rozwija się IT, nie jest ani drabiną stromo wznoszącą się ku górze, jak chcą naiwni techno-entuzjaści, ani też ścieżką prowadzącą w dół, ku ostatecznej klęsce, jak głoszą ekolodzy, weganie i inni współcześni millenaryści. Ta droga ma kształt sinusoidy, gdzie po latach prosperity nadchodzą lata chude i pewne sprawy trzeba od początku przypominać i o rozsądek wołać, choć wydawało się, że raz na zawsze zostały wyjaśnione i powszechnie zaakceptowane.

Rok 2013 jest dobrym pretekstem, aby przypomnieć o testowaniu. Minęło już ponad 10 lat od powstania ISTQB (International Software Testing Qualifications Board, istqb.org), w którego narodzinach wziąłem bezpośredni udział, a wkrótce dziesiątą rocznicę założenia obchodzić będzie także polskie Stowarzyszenie Jakości Systemów Informatycznych (SJSI, sjsi.org), powstałe z inspiracji autora tego artykułu w maju 2003 roku (computerworld.pl/news/54983/Ku.lepszemu.oprogramowaniu.html).
Jest pięć prostych zasad, niezbędnych, aby projekty informatyczne kończyły się biznesowym sukcesem. Te zasady wielokrotnie już omówiono i opisano, weszły w skład podstawy programowej nauczania dla zawodowców IT, ale wciąż okazuje się, że co kilka lat trzeba zaczynać od początku. Zaczynajmy więc.

1. Jakość jest za darmo

Książka Crosby'ego pod tytułem Quality is Free ("Jakość nic nie kosztuje") została wydana... trzydzieści cztery lata temu, w roku 1979. Były też dowcipy: o drwalu, co tak pracowicie rąbał drzewo, aż nie miał kiedy naostrzyć siekiery i o tym, że nigdy nie ma się środków, aby zrobić coś porządnie, ale zawsze znajduje się czas, aby to później poprawiać. Jedna z dyskusji na ten temat odbyła się blisko dekadę temu, podczas konferencji IDG w 2004 roku. Niestety, zwyciężył wniosek, że jakość jednak nie jest za darmo. Boję się, że gdyby głosować, zamiast liczyć, czy dwa plus dwa równa się cztery, przewaga głosów wskazałby może SIEDEM.

Od tego czasu niewiele się zmieniło. W działach IT nieliczni jajogłowi nadal muszą walczyć o uznanie zasady, że warto na przykład najpierw stworzyć specyfikację wymagań, zamiast zaczynać kodowanie bez kierunku, bez celu i bez planu. Jakość nadal wielu widzi jako zbędny luksus, z którego można zrezygnować, podczas gdy jeśli naprawdę mamy kryzys, to jesteśmy zbyt biedni, by pozwolić sobie na rozrzutne niechlujstwo: potrzeba nam zdyscyplinowanego oszczędzania, czyli jakości.

2. Monopole szkodzą przedsiębiorczości, a ludzka chciwość daje lepsze jutro

Rewolucja
Jak każda rewolucja, kiedy biedni i ciemiężeni obalają i grabią bogatych, by sami także zdobyć udział w majątku i władzy, tak rewolucja testowa, która do Polski przyszła w latach 2002-2003, spowodowała, że niedostrzegane wcześniej testowanie i kontrola jakości zdobyły - nominalnie - uznaną pozycję w krajobrazie IT, ale stało się to kosztem rezygnacji ze swego ich podstawowego przesłania, jakim jest oszczędność i zysk przez mądrze dozowaną jakość. Zamiast tego, testowanie - jak wcześniej programowanie i zarządzanie - stało się lunaparkiem narzędzi o pokracznych nazwach, dziwacznych pseudo-skutecznych metod i groźnie rozrosłych, martwych, zamkniętych, nie podlegających żadnej kontroli systemów certyfikacji, które więcej kosztują, niż dają. Fora dyskusyjne testerów intelektualnie zamarły, dominują tam dzisiaj reklamy obowiązkowych, wciąż tych samych szkoleń certyfikacyjnych tych samych firm, trochę detalicznych pytań o narzędzia, i na tym koniec. Niektórzy młodzi, kierując się albo autentycznym zawodowym entuzjazmem, albo chęcią zrobienia kariery, dołączają tam, gdzie bezpieczny monopol i zmowa cenowa pozwala i na zyski, i na zaistnienie jako fachowiec bez większego ryzyka i wysiłku.

PKP? PZPN? Monopole są aroganckie, pewne siebie i ograniczają konkurencję, albo dbają, by nie rozkwitła. Wydaje się, że w branży IT, gdzie istnieje mit samotnego programisty w garażu, co w ciągu roku staje się miliarderem, zagrożenie monopolizacją jest mniejsze? Niestety, nie jest. Dobrowolnie tolerujemy monopole. Pora na facebook.com/antysjsi w szkoleniach IT? Proszę nie liczyć na mnie - już kilka razy znalazłem głowę zabitego konia (sjsi.org/index.php?m=12&page_1=8&) na kołdrze - boję się.

3. Jakość jest warunkiem wydajności

Panuje przekonanie, że jakość to kosztowny luksus, na który stać najbogatszych. To taki sam nonsens jak wiara, że tylko bogatych stać na zdrowy tryb życia.

Jeśli celem działań jest abstrakcyjnie pojmowane "podniesienie jakości", możliwa jest tylko przegrana. Albo pro-jakościowe działania szybko ulegną dominującej w IT kulturze sztukowania i łatania dziur zamiast mierzenia, projektowania i planowania, albo jakość - zbiurokratyzowana i nieskuteczna - wprawdzie zostanie, ale jako dokuczliwa, z trudem akceptowana otoczka, jako dodatkowa robota, która nie przyczynia się do wzrostu wydajności, a wręcz przeciwnie.

Należy więc zacząć od przeciwnego końca: nie dbać o jakość, starać się tylko zwiększyć wydajność. Niech za pół roku pięciu programistów w dwa miesiące umie zrealizować pracę, która dzisiaj dziesięciu programistom zajmuje pół roku! Jak to osiągnąć?

Popatrzmy, co naprawdę robią w pracy programiści? Trochę programują, a poza tym? Po pierwsze, dużo czasu poświęcają na przerabianie tego, co już raz i drugi zrobili, bo tak zwany "biznes" nie potrudził się, aby swoje potrzeby precyzyjnie określić, a wymagania opisać. Byłem niedawno w firmie produkującej programy na smartphone'y i tablety, która chciała usprawnić czasochłonne testy, automatyzując je. Automatyzacja jest skomplikowana i wymaga sporo pracy, więc zaproponowałem im usprawnienia tańsze i szybsze: pisanie prostych specyfikacji wymagań w formie tabeli w Excelu zamiast historyjek obrazkowych i opowieści tworzonych w PowerPoint, oraz półautomatyczne tworzenie z nich uporządkowanych scenariuszy testowych, mogących zastąpić kreatywną i czasochłonną testową eksplorację. Moje podejście nie wzbudziło - oczywiście - entuzjazmu, automatyczne testy są zabawniejsze.

Drugie marnotrawstwo czasu to tak zwane debugowanie - szukanie w kodzie defektu, który - od czasu do czasu - powoduje awarię. Można bardzo poważnie - o pięćdziesiąt procent i więcej - obniżyć potrzebę debugowania, wdrażając proste, automatyczne lub pół-automatyczne środki zapobiegawcze, na przykład tak zwaną analizę statyczną i automatycznie generowane testy jednostkowe. Czytelniku, nie wiesz, co to? I uważasz, że nie potrzebujesz, bo "Computerworld" to pismo dla kadry kierowniczej, a nie dla technicznych hakerów? Cóż, skoro tak, nie zależy Ci na ukrytych w tych egzotycznych nazwach dużych pieniądzach, a oczekując, że hakerzy sami zaproponują te usprawnienia, będziesz czekał długo, bo - jak powiedział Martin Tornquist, właściciel dużej brazylijskiej firmy specjalizującej się w testowaniu oraz inżynierii wymagań, do propozycji ulepszeń łatwiej mu często przekonać CFO niż CIO klienta, bo ten pierwszy za złą jakość płaci, podczas gdy ten drugi na niej pasożytuje.

Trzecie marnotrawstwo to zbędne gadanie. Nie gadanie dla rozrywki i przyjemności - to warto popierać, bo człowiek zadowolony pracuje dużo lepiej i wydajniej, niż człowiek zestresowany do granicy bólu. Chodzi o konieczność gadania - bezpośredniego, mailem, sms-em, telefonem czy społecznym medium - w celu uzgadniania, zdobycia informacji, potwierdzenia, zarezerwowania dostępu, skonfigurowania, przyniesienia lub odzyskania - czegokolwiek. Tam, gdzie synchronizacja oraz administrowanie odbywa się przy pomocy gadania, zamiast procesu i narzędzia, tam marnujemy nieskończenie wiele czasu. Duże pieniądze można zarobić, usuwając chaos - na przykład - przy pomocy prostego narzędzia do tak zwanego śledzenia powiązań wymagań.

I tak dalej. Działania nakierowane nie na nudną, moralizatorsko brzmiącą jakość, tylko na ostrą, egoistyczną i kapitalistyczną wydajność, zapewnią i jedno, i drugie.

4. Taniej jest zapobiegać niż leczyć

Kiedyś sądzono, że projekt IT mogą zrealizować niemal sami programiści, kierowani przez jedną-dwie osoby z żyłką do interesów. Stopniowo przekonano się, że taki przekręt, owszem, od czasu do czasu się udaje, ale jego koszty zwykle wielokrotnie przekraczają pozorne korzyści. Te koszty to rozgniewani klienci, przemęczeni programiści, ogromne wydatki  na na usuwanie skutków nieoczekiwanych awarii i nerwowe naprawy z pistoletem terminów i odszkodowań przystawionym do skroni, czego łatwo uniknąć, jeśli przed wdrożeniem oprogramowanie przyzwoicie sprawdzić (przetestować). Tak zaczęła się kariera testerów, których rację bytu przemysł zaakceptował, tak jak akceptuje się i nawet ceni istnienie policji, straży pożarnej czy pogotowia ratunkowego.

ADP
Nauczywszy się gasić pożary, można z czasem wpaść na dalej idący pomysł, że jeszcze lepiej byłoby nauczyć się pożarów unikać. Dlatego przed kilku laty pojawiła się idea ADP - Automated Defect Prevention - prosta, logiczna, elegancka i niesamowicie skuteczna. Kilka artykułów na jej temat napisaliśmy także w "Computerworld", organizowaliśmy wykłady, seminaria (darmowe, ze śniadaniem!), ale daremnie. Uwagę konsumentów popularnej rozrywki i efekciarskich rozwiązań pochłonęła rzekoma nowość - "chmura" - polecam computerworld.pl/artykuly/364434/Picceria.czyli.antropologia.IT.html oraz skuteczne czasem, ale przede wszystkim hałaśliwe i epatujące młodych pseudo-radykalizmem, metody zwinne (agile). Nikt z nas nie ma skłonności do tego, aby stać się ubogim prorokiem w imię samej prawdy, więc odłożyliśmy ADP do lamusa, podejmując bardziej popłatne przedsięwzięcia.

Tymczasem IT nadal bardziej podziwia odpornych na stres, dzielnych strażaków, zamiast tych, którzy mówią, że jest czas najwyższy - jak w każdym innym przemyśle cywilizowanego świata - porzucić XVIII-wieczną manufakturę - debugowanie i dokręcanie śrubek w trakcie jazdy - na rzecz XX-wiecznej taśmy produkcyjnej, gdzie błędów i defektów przede wszystkim się unika, a nie gorączkowo poprawia w gotowych produktach. Zamiast heroicznego debugowania i odporności na stres proponują trochę dyscypliny i kontroli procesu. Prosta prawda, ale wciąż nie mogąca się przebić do świadomości ludzi w czasach lewackiego przechyłu w stronę agile oraz testów eksploracyjnych.

5. Lepiej wcześniej niż później

Tak, oczywiście, że każda złotówka wydana na inżynierię wymagań przynosi dziesięć razy większy zysk, niż złotówka wydana na selenium - ruby - capybara - cucumber - fitnesse - phyton, ale temu  tematowi poświęciliśmy niedawno pięć artykułów w "Computerworld", więc zbyt wcześnie jest jeszcze, by do niego wracać 

Historia się powtarza

Inspiracją do napisania tego artykułu była, zakończona niedawno w Pradze, konferencja CzechTest 2013 (czechtest.com). Dwa wygłoszone tam wykłady były dobrym podsumowaniem ostatnich dwudziestu lat rozwoju inżynierii oprogramowania, i punktem wyjścia do przewidywania, jakie możliwe scenariusze wydarzeń zrealizują nadchodzące lata.
Wybitny, choć mało w Polsce znany, specjalista w dziedzinie opłacalności oraz jakości w IT, Lee Copeland z USA, wymienił nazwiska: Beizer, Myers, Hetzel, Crosby, Fagan, aby sprawdzić, czy zgromadzeni na sali je znają. Podniosło się bardzo niewiele rąk, nie dlatego, że przedawniły się głoszone przez nich proste zasady, jak oprogramowanie tworzyć szybko i dobrze, a nie źle i powoli, lecz dlatego, że dobrą wiedzę chwilowo wyparła gorsza pseudo-wiedza, modne bzdury, niby-technologiczna nowomowa (selenium - ruby - capybara - cucumber - fitnesse - phyton) i szarlataneria w stylu chińskiej rewolucji kulturalnej (agile - mapy umysłu - TDD - eksploracja - kontekstowość).
Inny VIP tej konferencji, Martin Pol z Holandii, pokazał ewolucję podejścia do jakości oraz testowania: od pierwotnego chaosu sprzed półwiecza, poprzez rozwój standardów i dyscypliny w latach 1970-1995, aż po współczesny nacisk na interakcje i kreatywność zamiast otaczania się zwałami dokumentacji, czego wyrazem jest między innymi tegoroczna, dwudziesta już, konferencja EuroSTAR w Goeteborgu (listopad 2013): kontekstowa, eksploracyjna i anty-establishmentowa aż do bólu. Dziś, twierdzi Martin Pol, wiedza i zdrowy rozsądek inżynierów jakości z trudem szukają drogi między konserwatywną prawicą, ukrytą za potężnymi murami monopolistycznych, zamkniętych standardów i systemów certyfikacji (ISTQB, PRINCE 2, ITIL, PMI), a rewolucyjną lewicą, głoszą, że nauka i wiedza na temat inżynierii oprogramowania to burżuazyjna bzdura, że wystarczy entuzjazm, inspirujące interakcje, kreatywność, wiara w guru i media społeczne, aby bez nauki i trudu zdobyć potrzebne umiejętności.
PODSUMOWANIE

1. Proste inwestycje w jakość zwracają się nawet już po kilku dniach, a nie - jak większość innych inwestycji - dopiero po latach.

2. Aby dramatycznie zwiększyć wydajność, wystarczy kilka prostych ulepszeń organizacyjnych, ograniczających kosztowny bałagan.

3. Taniej jest zapobiegać, niż leczyć: szkodliwy mit zwinnego debugowania warto zastąpić staroświecką dyscypliną.

4. Lepiej wcześniej niż później: kluczem do zysku jest inżynieria wymagań, a nie wypasione narzędzia i modne technologie.

5. Monopole szkodzą wszystkim - najlepsze oprogramowanie jest dostępne w formie wolej i otwartej, pora na to samo w szkoleniach i certyfikacjach IT. Ale uwaga na modne bzdury!