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.

poniedziałek, 12 stycznia 2015

Lepiej, szybciej i zupełnie inaczej: radykalne ulepszanie procesu biznesowego

[może napiszę o tym książkę, jak namówię któreś wydawnictwo]

Innowacje, postęp i sukcesy w biznesie

Popularny niegdyś film „Walka o ogień” (Quest for fire, 1981) pokazuje – pomińmy pewne niezgodności obrazu z aktualną wiedzą naukową – świat sprzed 80.000 lat. Poprzez fikcyjną, ale prawdopodobną fabułę, przedstawia czas dramatycznej zmiany w dziejach ludzi na planecie Ziemi, kiedy nasi przodkowie nauczyli się wykorzystywać ogień.

http://pl.wikipedia.org/wiki/Walka_o_ogie%C5%84_%28film%29

Od tego czasu, pojawiły się dziesiątki, setki tysięcy nowych technologii i wynikających z nich zmian sposobów życia i działania. Wobec tego, cóż to za wielka nowina, to BPR?  Czemu pojawiła się dopiero w latach 90-ych zeszłego wieku? Definicja BPR w polskiej Wikipedii brzmi tak: „koncepcja biznesowa polegająca na wprowadzaniu radykalnych zmian w procesach biznesowych. Celem zmian jest osiągnięcie maksymalnej efektywności organizacji oraz redukcja kosztów” – a to przecież pasuje znakomicie, jako podsumowanie filmu, o którym piszę poprzednim akapicie. Czyżbyśmy mieli do czynienia z kolejną, przemijającą modą, kolejnym sloganem, niewiele wnoszącym do praktyki?

Otóż nie: BPR, czyli poszukiwanie i wdrażanie radykalnych ulepszeń, wprawdzie na wiele sposobów rzeczywiście uprawiano w praktyce od tysięcy lat, ale koncepcja BPR, jako teorii, jako „inżynierii wprowadzania radykalnych zmian w procesach” jest czymś zupełnie nowym. Oficjalnie, za datę narodzin re-engineeringu biznesowego uważa się opublikowanie artykułu, napisanego przez profesora informatyki MIT, Michaela Hammera, w roku 1990 w „Harvard Business Review”. Artykuł nosił tytuł „Reengineering Work: Don't Automate, Obliterate” (Re-engineering pracy: nie automatyzuj, zlikwiduj). Później, sławę przyniosła autorowi książka „Reengineering the Corporation: A Manifesto for Business Revolution”, którą napisał razem z Jamesem A. Champy.

Oczywiście, Hammer to nasz człowiek :-)

Michael Martin Hammer was born in Annapolis, Md., on April 13, 1948, the only child of Henry and Helen Hammer, who had arrived from Poland after surviving the Nazi [German Nazi - BB] concentration camps. Henry Hammer was a cantor. (NYT 2008)


Cóż takiego ma do powiedzenia profesor informatyki na temat procesów biznesowych, czego by wcześniej nie wyartykułowali ekonomiści, specjaliści zarządzania i guru marketingu? Bardzo wiele: to samo, co każdy współtwórca rewolucyjnej technologii, którą na początku biznes stosuje do wzmacniania, przyspieszania starych sposobów pracy, zamiast do tworzenia zupełnie nowych. Kiedy się okazuje, że dana technologia naprawdę może otworzyć nowe perspektywy, nowe – mówiąc językiem marketingu – biznesowe błękitne oceany, wówczas znajomość tej technologii może stać się cennym źródłem biznesowych inspiracji.

Komputery wynaleziono siedemdziesiąt lat temu. Początkowo, miały zastosowanie wyłącznie niszowe, wykorzystywano je jako ultra-szybkie liczydła, nie wydawało się, że zmienią kształt naszej cywilizacji tak radykalnie, szybko i wszechstronnie, jak to się stało. Kiedy Steve Jobs i Bill Gates zaczęli się bawić komputerami pod koniec ósmej dekady ubiegłego stulecia, były to zabawki fascynujące, ale najzupełniej, wydawało się, bezużyteczne do poważnych, biznesowych zastosowań.

http://pl.wikipedia.org/wiki/Apple_I

Te firmy, które, intuicyjnie stosując zasady BPR, jeszcze wtedy nie opisane, umiały wynaleźć sposoby wykorzystania tych zabawek do radykalnej zmiany swojego sposobu pracy, wygrały. Firmy, które tego nie umiały, musiały potem gonić peleton, lub zupełnie wypadły z gry. A więc, BPR się opłaca!

Re-engineering jest do pewnego stopnia intuicyjny i stosuje się go, lepiej lub gorzej, od tysiącleci, ale znajomość uporządkowanych, opisanych i szczegółowo opracowanych zasad BPR pozwala na większą skuteczność i daje dużą, konkurencyjną przewagę. A więc, BPR, to znacznie więcej niż modny, trzyliterowy skrótowiec.

Nie każda nowa technologia otwiera drzwi do radykalnych zmian procesów biznesowych. Układ scalony, kiedy po raz pierwszy ujrzał światło dzienne w 1958 roku, był – z perspektywy historii – wielkim wynalazkiem, ale nie stwarzał bezpośrednio nowych możliwości sposobu pracy. Natomiast pewne wynalazki o szczególnie szerokim zakresie zastosowań: ogień kilkadziesiąt lub kilkaset tysięcy lat temu, druk w XV wieku, maszyna parowa w XVIII stuleciu, programowalne komputery, stały się fundamentem prawdziwie rewolucyjnych przemian. Chcąc osiągnąć sukces w biznesie, trzeba je umieć wykorzystywać, w czym walnie pomóc może znajomość zasad re-engineeringu biznesowego (czy nazwać to po polsku re-inżynierią?), czyli BPR.

Teoria BPR powstała na początku lat 90-ych, a rozpowszechniła się i zaczęła wywierać znaczący wpływ na realia korporacyjnego biznesu, pod koniec tysiąclecia. Co to za daty? Oczywiście, to początki Internetu i systemu dostępnych w nim usług, WWW. Tkwiąc w środku tej rewolucji, nie w pełni dostrzegamy jej ogrom i radykalizm, ale za kilkadziesiąt i za kilkaset lat, w podręcznikach historii, trzydziestolecie 1990 – 2020 na pewno doczeka się osobnego rozdziału. Przesłanki do sformułowania zasady „nie automatyzuj – zlikwiduj”, zaistniały już wprawdzie wcześniej wielokrotnie: ogień, druk, silnik parowy, telefon – ale pomysł ten doczekał się sformułowania dopiero w 1990 roku.

Nazwa „re-engineering procesów biznesowych” nieco nadużywa słowa „inżynieria”. Prawdziwa inżynieria, taka jak budowanie samochodów, domów czy mostów, składa się z precyzyjnych zasad, algorytmów konstruowania, których stosowanie niemal gwarantuje osiągnięcie celu, zbudowanie zamierzonego urządzenia. „Inżynieria biznesu”, to zestaw heurystyk, których stosowanie wprawdzie znacząco zwiększa szanse powodzenia, ale niczego nie gwarantuje. Przykładowo, gdybyśmy wiedzieli, że stosowanie opisanych w tej książce zasad BPR podnosi szansę na sukces w danym biznesie z 20% na 45%, to jest to różnica bardzo istotna; to dobry argument na rzecz tezy, że BPR warto poznać i warto stosować. Niemniej, nawet 45% prawdopodobieństwa sukcesu oznacza przecież 55% prawdopodobieństwa klęski, z czego trzeba sobie zdawać sprawę i nie traktować najlepszych nawet heurystyk jako magicznej różdżki, prowadzącej prostą drogą do szczęścia i bogactwa.

Eksplozja bańki internetowej i jej spektakularna implozja 1997-2000 dobitnie pokazuje obie strony medalu BPR. Z jednej strony, zupełnie nowe formy internetowego biznesu, które wtedy powstały z niczego, dziś, czternaście lat później, rzeczywiście dominują, wypierając lub zmuszając stare formuły do głębokich zmian. Z drugiej strony, dziesiątki firm, wtedy histerycznie przecenionych przez giełdy, zbankrutowało. Czym się różnili się bankruci od tych, którzy osiągnęli sukces? Niewątpliwie, czasem decydował przypadek. Na przykład, jedną z przyczyn spektakularnej klęski – bankructwa w maju 2000 roku – słynnego swego czasu sklepu internetowego Boo.com, był trudny do przewidzenia czynnik zewnętrzny, nagłe wyschnięcie źródeł kapitału inwestycyjnego, na których dostępności firma budowała swoją bardzo agresywną i kosztowną politykę ekspansji. Z drugiej strony, portal sklepu Boo.com był klasycznym wręcz przykładem fatalnie zaprojektowanej interakcji i złego doświadczenia użytkownika.


Na wagę czynnika doświadczenia klienta BPR kładzie wielki nacisk. Nie czytali, widać, książki Hammera... jak wiele firm, do dziś ;-)

Pokazaliśmy, że BPR było cennym wkładem do rozwoju myśli biznesowej oraz innowacyjności w latach 90-ych. A co teraz – czy koncepcja już się wypaliła, czy może na tyle zintegrowała się z powszechnie stosowanymi praktykami, że publikowanie dzisiaj książki na jej temat, to anachronizm? Nie, upowszechnienie wiedzy na temat re-engineeringu biznesowego jest i potrzebne, i aktualne.

Internetowa rewolucja nie skończyła się ani w roku 2000, ani w 2010, lecz trwa w najlepsze. Ponieważ jest to rewolucja w zarządzaniu wiedzą i komunikowaniu się ludzi, można przypuszczać, że spowoduje ona kolejne rewolucje, niekoniecznie związane z IT. Nie potrzeba do nich nawet żadnych spektakularnych nowych technologii, zmiany mogą mieć charakter czasowy oraz ilościowy. Ani „Facebook”, ani „Instagram”, ani „Twitter” nie są niczym szczególnym z punktu widzenia techniki, ale mimo tego skutecznie zmieniają paradygmaty relacji międzyludzkich, obiegu informacji, marketingu i reklamy. Nie znamy przyszłości, ale umiejętność radykalnego zmieniania sposobów działania w sytuacji zmian, pozwoli lepiej sobie radzić z przyszłymi wyzwaniami.

BPR, to dziedzina w najwyższym stopniu interdyscyplinarna: jeśli w firmie są dziesiątki procesów, każdy z nich może być przedmiotem zmian. Jak wiele obszarów interdyscyplinarnych, także BPR jest ogromnie niedoceniany – zamiast niego, omawia się, opisuje i dyskutuje tematy węższe, bardziej konkretne, bardziej specjalistyczne… i znacznie modniejsze.

Zamiast więc uprawiać dyscyplinę całościową – re-inżynierię procesów biznesowych – częściej angażujemy się i specjalizujemy w dyscyplinach specjalistycznych – prawie, finansach, zarządzaniu, w czynnikach miękkich, w sprzedaży, w marketingu, i wielu innych. O nich pisze się książki, o nich urządza się konferencje, na specjalizacji w nich robi się kariery. Cierpi na tym BPR. W inżynierii wymagań - innej, podobnie jak BPR niedocenianej, interdyscyplinarnej dziedzinie – popularny jest poniższy rysunek:

https://nobudgettravel.wordpress.com/2008/11/27/thursday-photo-friday-13/

Niewidomi, badający słonia, widzą tylko jego część i na tej podstawie tworzą sobie najzupełniej fałszywy obraz całości. Nie neguję znaczenia dyscyplin takich jak finanse, kadry, produkcja, sprzedaż, marketing, zarządzanie infrastrukturę itp. dla funkcjonowania każdego biznesu; jednak dla zarządzania strategicznego konieczne jest widzenie całościowe. Takim podejściem jest re-engineering procesów biznesowych, czyli BPR.

piątek, 9 stycznia 2015

Dla kogo jest ta książka ("Techniki testowania")?

Patrze także: spis treści projektowanej książki
Patrz także: literatura i inne źródła 
 
For Whom and Why Is This Book Needed?

What Is It Needed for?
Testers need to know how to design test cases.
Testers' main responsibility is to choose from infinite, or at least prohibitively huge number of possible combinations of paths and data values, those few - terrifyingly few - test cases that will really be exercised during test execution and thus be the final bulwark  of defence against risk of failure, loss and catastrophe.
If this was not for test design, testing would be just requirements engineering turned upside-down, plus some knowledge in how to manage bug reports, plus a handful of tools with funny names; a kind of last resort fire brigade, needed only when error prevention fails. But it is not so, because testing means test design. Test design (and analysis, which always precedes design) is the very essence of testing, is what makes it a separate, special set of skills. 
However, no fully comprehensive book on test analysis and design techniques is available. There are three main reasons for this.
One reason is, testers and their employers alike typically look for information that is needed here and now, and which provides immediate relief. Therefore, many books, web pages and other information sources on testing, are in this respect sadly similar to job advertisements: they value detailed technical or domain knowledge more than sound, generic test knowledge. Advertisements  for "test analyst with Selenium skill and insurance industry experience" are incomparably more common than those seeking specialists with general test knowledge, capable and willing to learn required domain and technical skills fast. The result of this is, many testers learn test design techniques on the fly and only within given technology and domain boundaries, and fail to see the whole picture.


Who cares? Well, everybody should, because this way the transfer of knowledge and skill is minimal. Next time, the tester who had already learned designing test cases based on UML activity diagrams for a banking system, will need to learn designing test cased based on UML state transition diagrams for an embedded system from scratch. This way, the waste of time and money is maximal!

I can understand, even if not completely forgive, such approach in hasty, we-need-it-tomorrow project situations, but the is definitely wrong approach to learning and teaching testing. If we want really good practitioners, we need effective textbooks for them. These textbooks must not mix up test design skills with everything else, including technology and domain knowledge. Even if test practitioners need to mix these topics in project realities, they must not mix them in their heads!

The second reason is that readers', authors' and publishers' short-sighted motives take prevalence over far-sighted approach, when they choose to put together test design, test organization, test management and even test automation knowledge in one volume or on one web site, or in one presentation. This sells better, probably because it gives an impression of no-nonsense pragmatism, while treating these subjects separately may give an impression of being theoretical and academic. Again, in order to become really high-quality professionals, capable of applying our skills in many different situations, we should learn - and teach - theses areas separately. Professionals need to be able to use their skills multi- dimensionally, not only as one or two or even ten specific sequences.
The third reason is, more than half of the book market for testing is monopolized by ISTQB-based textbooks. There is only a limited number of test book copies people can buy, and since books with "ISTQB" on the title page are safer bet for the publishers, they dominate. Good-bye to serious test design! 
And of course, the main main reason is, THICK VOLUMES SELL BAD!
By learning test analysis and design techniques separately, you'll be able to use them more effectively, and really efficiently, within different test strategies, processes and test organizations, equally well for various technologies, and in all conceivable domains and businesses.

What Is Available, and What is Not?
I searched the phrase "test design techniques" in amazon.com, and what I got highest up on the list was... "Exploratory Software Testing: Tips, Tricks, Tours, and Techniques", and "Agile Testing: A Practical Guide for Testers and Agile Teams", and some more such titles :(. Even keeping my general reservations about exploratory and agile approaches aside for a while, these books were not what I was looking for: not comprehensive textbooks on test design techniques. The ones I found mix test design with many other issues, and do not make any attempt to cover all available techniques. And of course, "tips, tricks and tours" are always easier to sell than boring lectures.
Let the search go on, back to good old names. Boris Beizer's "Software Testing Techniques" and "Black Box Testing" by the same author are very good, yet far from complete. Glenford Myers' "The Art of Software Testing" (first published as early as 35 years ago!) still is and always will be the ultimate in describing some techniques, but definitely not all that are worth knowing.
Then of course there is Lee Copeland's "A Practitioner's Guide to Software Test Design". Great book, in my opinion one of the best there is on this subject. However, it is still not fully what I believe testers need today; it does not offer a really comprehensive view. Saying this, I do not mean just omitting a few rather exotic and unimportant techniques; I mean omitting a lot. For example, UML contains fifteen types of models, which are extremely useful for designing test cases; Lee's book covers two of them use case diagrams, and state transition diagrams. That was the author's choice, and I respect it, but I think more is needed by many testers.

There are books based on the world's most popular test certification scheme: ISTQB Advanced Level syllabi for test analysts and technical test analysts. Even keeping my general reservations about the contents and structure of ISTQB syllabi aside for a while, the simple truth is, design techniques with ISTQB blessing present just a smallish part of the total amount of test design techniques. For example, they hardly cover techniques specific for non-functional testing, and they are mostly limited to test design for dynamic test execution, leaving out almost completely the rules of static testing.

Paul C. Jorgensen's "Software Testing: A Craftsman's Approach" is exceptional since it refers to mathematical concepts and logical reasoning. At last a book that dares use the words "discrete math" and "graph theory"! To tell the truth, I find it hard to understand why all other books choose to teach test design without mathematics. Perhaps because context-driven school pretends testing is more a social skill than anything mathematical? However, Paul's book is very much focused on functional testing, and formal test design: good, but I believe non-functional testing, or experience-based testing must not be left to intuitive magicians, but taken care of in the same volume. 
Last but not least, one must not forget Geoff Quentin's worthwhile attempt "The Tester's Handbook", whose chapter 7 "Specific Test techniques" contains the most comprehensive list of test techniques available now. However, I find it not complete, either.

This Book Fills a Market Gap
Please note: I do not criticize these books, nor do I think I am somehow wiser then their authors. On the contrary, I will use the knowledge they have already provided maximally. My wish is to fill a market and educational gap, not a knowledge gap.

That is it: my ambition is to provide the missing link. Not for the sake of theory, nor for the sake of academic ambitions - I will hardly present anything that is not already known and described somewhere. My goal is to provide a fully practical handbook, gathering in one place the as many as possible - not just chosen few - good techniques for designing test cases. This book will help testers of all kinds, exploratory and scripted, agile and traditional, waterfall and iterative, manual and automatic. It should be equally useful for regression-testing and for confirmation-testing, for unit-level and system-level, for testing embedded and database systems, written in object-oriented or in assembly language, static and dynamic, testing software, design, for models and for documents.

Let us disregard the misleading dichotomies of white-box versus black-box, formal versus informal, web testing versus database testing, etc. There are some issues specific for some domains, but first of all, there are test design techniques common for all of them. In project realities, domain and technology knowledge helps, but the lack of general test design knowledge kills. All testers all need to make the same kind of decisions: what to actually check, and what to leave alone. This book will help them to make the right decisions.