poniedziałek, 19 stycznia 2015

Gimbaza testerów

Ten artykuł pojawił się w Quale 4 (grudniowym), ale ponieważ WordPress szwankuje, więc zapraszm Was także tutaj.
  
Trochę historii
 
Kiedy w latach 2002-2003 prowadziłem pierwsze w Polsce szkolenia, przygotowujące do egzaminów na certyfikat ISEB, poprzednika ISTQB, zainteresowanie było ogromne, a profil uczestników – nadzwyczaj zróżnicowany, mimo że wiedza, wymagana do tego zupełnie podstawowego certyfikatu, była zbyt płytka, zbyt powierzchowna dla wielu słuchaczy, mających w testowaniu spore czasem doświadczenie, jak i zbyt wąska dla osób pełniących funkcje kierowników projektów, albo analityków biznesowych; ograniczona tylko do małego w końcu zakresu wiedzy, dotyczącej projektowania, wykonywania i automatyzacji testów. Mimo tego, ci ludzie, zainteresowani zupełną nowością, jaką były wówczas te certyfikaty i szkolenia, chętnie brali w nich udział.
 
Od tego czasu, na powierzchni, nastąpiły ogromne zmiany. Dziesiątki tysięcy pracowników sektora IT definiuje swoją rolę jako „testerzy”, certyfikaty ISTQB stoją na drugim miejscu w rankingu popularności po kierowniczej falandze certyfikacji PRINCE 2, PMI, IPMA oraz ITIL. We Wrocławiu, w Krakowie, Gdańsku, Łodzi, Poznaniu, Bydgoszczy i Warszawie powstały lokalne organizacje osób zajmujących się testowaniem, konferencja „Testwarez” bez trudu gromadzi co roku kilkaset uczestników, a turniej testerów „TestingCup”, stał się prawdziwym przebojem w ciągu ledwo dwóch lat swego istnienia. Niemal każda firma szkoleniowa ma w swojej ofercie kursy testowania. Można śmiało powiedzieć, że nie tylko przestaliśmy być białą plamą na testowej mapie Europy, ale staliśmy się pod wieloma względami ważnym aktorem w tej branży. Ale…
    

W testerskich okopach

  
Wprawdzie testowanie lubi się nazywać „QA”, Quality Assurance, ale z zapewnieniem jakości w swojej obecnej formie ma bardzo niewiele. Owszem, testowanie, czyli kontrola jakości, może pośrednio spowodować wzrost jakości, ale często jest to najmniej skuteczna metoda. Warto podkreślić, że opisywane tutaj przeze mnie zjawiska nie są w żadnym razie polską specjalnością, nawet moda na mylące nazywanie testowania „QA” przyszła do nas z USA.
Większość uczestników szkoleń, konferencji i rozmaitych innych wydarzeń testowych, to ludzie młodzi, na niezbyt wysokich stanowiskach. Popularne wśród nich tematyki to przede wszystkim narzędzia i automatyzacja, testy urządzeń mobilnych, sposoby zdobywania popularnych certyfikatów, trochę kwestii organizacyjnych, zwłaszcza w kontekście agile, czyli… same sprawy niskopoziomowe, takie swoiste testerskie hakerstwo. Nic w tym złego, oczywiście, to sprawy przydatne, tylko mam pytanie, gdzie wobec tego dyskutowane są zagadnienia strategii testowej, jej roli w inżynierii jakości, w zarządzaniu, w udoskonalaniu procesów produkcji i, szerzej, procesów biznesowych? Czyżby w kręgach MBA, PMI, IIBA, PRINCE 2? Niestety, nie, tam mówi się o testowaniu/weryfikacji/walidacji same teflonowe banały: teflonowe, czyli niepodważalne, ale mało konkretne i mało przydatne.
   

Tester do wszystkiego


Na swoje usprawiedliwienie, za nieuzasadnione i mylące stosowanie skrótu QA, testerska gimbaza ma to, że w praktyce często rzeczywiście jest jedyną instancją dbałości o jakość. Nie, MBA ani PMI, ani IIBA, niczego godnego uwagi o testowaniu nie nauczają. Słowa Hansa Schefera, napisane przez dwudziestu laty, „tester nie jest odkurzaczem” (Hans miał na myśli, że tester nie powinien być odkurzaczem, choć nim zwykle bywa), nic niestety nie straciły na aktualności.
  
Obecność licznej rzeszy mądrych i technicznie sprawnych testerów, marzących o tym, aby wypróbować w praktyce swoje umiejętności i kompetencje w stosowaniu „Selenium”, czy „JMeter”, stwarza dodatkową pokusę dla kierownictwa, aby problemy likwidować, zamiast u źródła, to tylnymi drzwiami, od strony skutków.
   
Sam osobiście doświadczyłem tego nie raz, na przykład, trzy lata temu, pracowicie uruchamiałem „FoneMonkey” oraz „Squish”, narzędzia do automatycznego wykonywania testów na iPhone, w firmie, gdzie daremnie usiłowałem obronić i wdrożyć znacznie prostsze i tańsze usprawnienie, w formie przenoszenia wymagań opisanych artystycznie w… PowerPoint do arkuszy kalkulacyjnych.
  
Ogłoszenia „dam pracę testerowi”, wśród listy wymagań stawianych kandydatom, oprócz znajomości – oczywiście! – „Selenium”, „JMeter” oraz „HP Quality Center”, zwykle zawierają też coś na temat elastyczności, komunikatywności oraz umiejętności znajdowania, gromadzenia i porządkowania chaotycznie zabałaganionych wymagań dla oprogramowania. Pracodawca kalkuluje więc sobie, że kosztownego inżyniera wymagań / analityka biznesowego zastąpi tańszym testerem, którego w dodatku można będzie wykorzystać jako kozła ofiarnego, jeśli coś w projekcie się opóźni. Gimbaza!
   

Co prawnicy wiedzą o testowaniu?


Prawnicy dbają o to, aby do umów „wdrożeniowych” (czytaj – umów na zbudowanie, akurat w odniesieniu do produktów IT zwanych dziwacznie „wdrożeniowymi”), wpisać tak zwane kryteria odbioru, czyli te warunki, które produkt musi spełniać, aby móc uznać, że wykonawca zrealizował swoją część umowy, i ma prawo wystawić fakturę oraz żądać zapłaty. Jak sprawdzenie spełnienia kryteriów odbioru ma być dokonane, to już – słusznie – prawnika nie interesuje. Dominującą formą kontroli są „testy”, z reguły „testy odbiorcze”, na samym końcu projektu. Umowa może zawierać załącznik, określający precyzyjniej te testy i sposób ich wykonania, ale nie oczekujmy, ze znajdziemy tam dojrzałe i zaawansowane rozwiązania. Forma, którą zakłada wiele umów, to testy przy użyciu scenariuszy, napisanych… przez samego dostawcę!
    
Nie jest rolą prawników, ani tym bardziej prawa, dbać o merytoryczną stronę umów; mają zadbać o stronę formalno-prawną. Dobrze napisana umowa musi zawierać kryteria odbioru, ale nie jest rzeczą prawnika pomóc stronom określić, na ile sposób ich weryfikacji jest dobrze opisany! Tym bardziej, że choć umowa na budowę programu i umowa na budowę domku letniego mają bardzo podobną strukturę, o którą dba prawnik, to techniki testowania są zupełnie różne dla domów i dla aplikacji, więc powinny je znać i określać strony umowy, nie prawnicy!
   

Dyskusja o PKW, czyli festiwal ignorancji


Niestety, strony umowy, szefowie i dyrektorzy i zamawiającego, i wykonawcy, zwykle nie znają ani testowania, ani inżynierii wymagań. Wiedza na temat testowania pozwoliłaby im wszak unikać takich porażających wpadek, jak ta z systemem do wyborów samorządowych, a wiedza na temat inżynierii wymagań spowodowałaby, że załączniki do umów „wdrożeniowych”, zwane notorycznie „specyfikacjami funkcjonalnymi” (czemu „funkcjonalnymi”??), byłyby odrobinę lepsze, niż zwykle są.
   
Szczególnie niezasłużenie złą sławą cieszy się, niesłusznie, prawo zamówień publicznych, oskarżane o to, że jakoby powoduje historie w stylu ostatniej afery PKW. Powtarzany bezmyślnie i do znużenia, zarzut wobec tego prawa, że premiuje kryterium ceny, nie wytrzymuje krytyki. Po pierwsze, ostatnia aktualizacja tego prawa sugeruje stosowanie również kryterium jakości, a po drugie, jeśliby specyfikacja wymagań – SIWZ – była dostatecznie precyzyjna, określając dokładnie i przedmiot zamówienia, i warunki jego odbioru, w tym jakość, lub metody jej zapewnienia, i pomiaru, wówczas kryterium ceny byłoby zupełnie wystarczające! 
     
Oczywiście, to stawia wymagania wobec zleceniodawcy, którym zwykle nie jest on w stanie podołać, bo ani na testowaniu, ani na innych obszarach inżynierii jakości, nie zna się ani w ząb.
Znając krzywą Boehma, której znaczenie dla jakości musi znać każdy, kto ukończył choćby kurs podstawowy ISTQB, umiano by powszechnie wykorzystać - wybacz, Czytelniku, prawniczy język – artykuł 31a Prawa Zamówień Publicznych, zezwalający na stosowanie procedury tak zwanego dialogu technicznego:zwracając się o doradztwo lub udzielenie informacji w zakresie niezbędnym do przygotowania opisu przedmiotu zamówienia, specyfikacji istotnych warunków zamówienia (SIWZ) lub określenia warunków umowy.”
      
Dyskusja, która wybuchła wokół informatycznych aspektów afery PKW, ujawniła szokujący ogrom powszechnej niewiedzy, czym jest testowanie oprogramowania, ani co można przy jego pomocy osiągnąć. Wypowiadali się na jego temat rzekomi specjaliści od „cyberbezpieczeństwa” (?), od jakości kodu, od audytów. Zamiast „testowanie” pisano audyt, audyt bezpieczeństwa, testy bezpieczeństwa, dziwiono się, czemu nie przetestowano wszystkiego („to oczywiste, że trzeba było sprawdzić wszystko”, napisał jakiś młody, z wypiekami). Czyżby należało w szkolnej podstawie programowej wymienić jedną z wielu tam zalegających, bezużytecznych bzdur, na trochę nauki podstawowych zasad inżynierii jakości, nie tylko dla oprogramowania?
        

Suchar


Gimbaza testerska nie ma ograniczenia wieku. Wielu szacownych, znanych na świecie specjalistów jakości do późnych lat wciąż kręci się wokół tych samych zagadnień, jakby nigdy nie dorośleli. Przykładów takich siwowłosych gimbusów znam wiele… Na przykład, po raz pierwszy zetknąłem się z koncepcją automatyzacji testów przy użyciu słów-kluczy dwadzieścia lat temu. Znakomity pomysł, pomyślałem, pomyślało tak wielu, metodę zaczęto stosować szerzej. Wydawałoby się, że stanie się częścią powszechnej wiedzy, nie trzeba jej będzie już szerzyć i propagować jako nowości, ale gimbaza działa! Po pierwsze, dwie popularne metodyki automatyzacji stosowane w świecie agile, skupione wokół narzędzi „FitNesse” oraz „Cucumber”, 100% metody słów-kluczy, nawet tej nazwy nie wspominają; cóż, każde kolejne pokolenie widać musi się bawić na nowo tymi samymi zabawkami udając, że są wielką nowością. A jednocześnie, tej jesieni w Gdyni, niedługo przed odpłynięciem promu do Karlskrony, z zakłopotaniem słuchałem wykładu siwowłosej osoby, omawiającej tę metodę… na nowo. Nie wypada mieć tyle lat, i wciąż bawić tymi samymi, starymi zabawkami!
    

Beka


Beka musi być, inaczej trudno coś nawet sprzedać. Mania nowości i rozrywki, czyli kompulsja tego, co czterdzieści lat temu nazywano „byciem równym”, a dziesięć lat temu, „byciem cool”, ogromnie utrudnia samodzielne myślenie, odbiera odwagę wyjścia poza dozwolone i narzucone przez rówieśnicze środowisko ramy. To są społeczne zjawiska, nie nowe, ale dziś łatwiej niż dawniej stwarzające pozory myślenia, no bo przecież trudno jakoś spodziewać się, że na arcy-wysokotechnologicznej platformie ktoś będzie głosił zupełne głupoty.
    
Myślę, że nie musi ciągle być beka. Myślę, że testowanie powinno porzucić gimbazę i zacząć wdzierać się w obszary wyższe, niesłusznie w tej chwili zarezerwowane dla absolwentów MBA, IIBA i PMI, nie mających do niego kompetencji. Wydorośleć z fascynacji narzędziami i pseudo-nowinkami. Aby to się powiodło jednak, testowanie musi być dopuszczone na salony dorosłości. W tej chwili, aby być uważnie słuchanym na wyżynach, o testowaniu lepiej w ogóle nie wspominać! Tam mądrale mówią o architekturze korporacyjnej, o zgodności, o devopsie, o ładzie korporacyjnym, o roli CIO, o zarządzaniu kompetencjami, a sprawy podstawowe, testy oraz wymagania, brzmią tam jakoś niestosownie, dziecinnie. Dopóki nie zawali się system bankowy, rezerwacji biletów PKP, albo PKW; wtedy na chwilę wracają do łask, by wkrótce zniknąć ponownie.
      

Trollowanie


Boję się, że ten artykuł może mnie narazić na zarzut trollowania. Pozwólcie mi się bronić na zapas. Ironiczny styl nie ma służyć obrażaniu – obrażałbym przecież także sam siebie – lecz ożywieniu dialogu, zbyt często oziębłego i suchego w branży technicznej. Nie wymyślam, jak rasowy troll, kontrowersji na siłę, żeby mieć okazję zabłysnąć, tylko odnoszę się do sytuacji, która, choć chronicznie utrwalona, jest kuriozalna i zła.  Wiadomo, jak dobrze realizować przedsięwzięcia IT, ta wiedza jest w licznych opracowaniach, w książkach i w głowach wielu mądrych ludzi, specjalistów inżynierii oprogramowania, w tym testerów. Niestety, często nie ma jej tam, gdzie zapadają decyzje, ani tam, gdzie realizuje się projekty. Bywa, że nie ma jej ani w głowach biznesowych zleceniodawców, ani w głowach wykonawców projektów. Zróbmy coś, żeby była!
Trzeba nauczyć się działać dobrze. Porzuciwszy na zakończenie poetykę gimbusową, powiem: potrzeba więcej praktycznej prakseologii – umiejętności skutecznego działania.

Brak komentarzy:

Prześlij komentarz