czwartek, 17 lipca 2014

Fajna dyskusja :-) i 8 pomysłów o testowaniu


Jak doszliśmy tutaj:

1. 17 i pół testerskich mitów. Świat mitów i legend w testowaniu wynikiem fejsbukizacji wiedzy. Social networking jest złą wyrocznią, chyba że w sprawach mody.

2. Agile Academy w Szwecji to szkoła policealna. W testowaniu potrzeba mniej inżynierów, a więcej techników. Czy testowanie powinno być więc wykładane w szkołach policealnych?

3. Jak projektować testy wg grafów, rachunku logicznego, teorii zbiorów oraz kombinatoryki, czyli pierwszy pełny i prawdziwy podział metod formalnych - z licznymi odniesieniami, jak ma się on do popularnej taksonomii ISTQB.

4. Zanik dobrej wiedzy testerskiej: czego nie wiemy, jakie modne słowa wyparły jakie dobre metody? Kto nie wie, kim był Boris Beizer?

5. Czy w świecie Continuous Integration projektowanie testów na podstawie wymagań jest archaiczne?

6. Ilościowe metody szacowania opłacalności testów.

7. Tak, testerzy są odkurzaczami i co to naprawdę znaczy? Kiedy lepiej porządkować, zamiast nie śmiecić? 

8. Możliwa rewolucja testowania uwzględniającego kontekst (context-driven testing) oraz HTSM

Pierwszy pomysł

Ostatnio dużo występuję tu i tam, i obserwuję:

  • Masową obsesję pseudo-tematami; nazwałbym to zjawisko "fejsbookizacją wiedzy", takie "fitnesse+cucumber+agile+eksploracyjne+android", w stylu "co i jak tam robiłem i jak użyć narzędzia XX". Trzeba żyć, więc i o tym opowiadam ;-)
  • Widzę też silny opór przed naprawdę ważnymi tematami, np. (a) jak szacować opłacalność testów; (b) na ile testy NIE są sensowną alternatywą dla rozsądniejszych metod zapewnienia jakości, a kiedy - rzadziej niż zwykle myślimy - są; (c) jak projektować testy wg grafów, rachunku logicznego oraz kombinatoryki, czyli prawdziwy podział (metod formalnych), zamiast tej bałaganiarskiej sieczki a la ISTQB. Próbuję, ale nikt nie chce tego słuchać - i ma rację, bo ani tym kolegom-testerom nie zaimponuje, ani pracodawcy nie przekona, bo teraz i pracodawcy chcą być "agile" (wyjaśniam - jestem entuzjastą agile, a wrogiem "agile"). A że lepiej by testował - kogo to obchodzi, ani tym się kariery nie zrobi, ani TestingCup nie wygra.
  • Smutne (a może wesołe?), że w kółko można tłuc te same tematy, a jak się ma znane nazwisko, to gadając to samo od 30 lat można to powtarzać i powtarzać (vide keynotsi na Testwarez, banalni aż zęby bolą, i nie jest to pretensja do organizatorów, sam bym ich wziął robiąc konferencję, ciemny lud to kupi ;-)
  • A lud faktycznie jest ciemny - po prostu nikt się niczego tak naprawdę nie uczy, to co odkryto w latach 70-ych albo wyparły metody gorsze, albo trzeba o tym co pokolenie (2-3 lata) każdemu opowiadać od początku. Ostatnio w opowiadałem o MBT (model-based testing), i to była dla słuchaczy taaaka nooowość (ale Cucumber nie był już dla nich nowością). Nie mam pretensji do słuchaczy, skąd mieli się tego nauczyć, skoro serwuje im się modne gadki i modne narzędzia zamiast wiedzy?
  • Jest silne parcie na modne nowinki, np. ostatnio wyczytałem, że w świecie Continuous Integration "inżynieria wymagań jest archaiczna" ;-)
  • Lekceważenie naprawdę cennych nowin: wielbiona jest ideologia eksploracyjna (= gadki-szmatki że "specyfikacje są złe") i ładne nazwy ("rapid testing"), natomiast mało kto rozumie i uwzględnia istotną wartość filozofii context-driven oraz autentycznie genialny wynalazek Jamesa Bacha, jakim jest HTSM.

Kontra
  • Preferowalibyśmy formy pozbawione złośliwości względem innych przekonań, metodyk czy organizacji. Można zaprezentowac temat kontrowersyjny w taki sposób, by nikogo nie urazić a zachęcić do refleksji. Na takim podejściu chcielibyśmy bazować. Czysta merytoryka bez polityki.

Re-kontra!
  • Stylistyka mojej propozycji faktycznie była kabaretowa, co mam nadzieję nikogo nie uraża - przynajmniej nie było takich intencji. Jeśli kogoś mimo braku intencji uraziła, to ubolewam, ale w takim razie byłby to problem psychologiczny, a nie związany z moją żartobliwie-sarkastyczną formułą tych słów. Psychologiczny dlatego, że przekonania/metodyki/organizacje, do których się tak odniosłem, same stosują podejście o wiele ostrzejsze, wręcz agresywne wobec opinii lub nawet faktów niezgodnych z ich światopoglądem.
  • O "fejsbukizacji" jako społecznym wręcz kryminogennym niekiedy fenomenie i jego negatywnych skutkach pisze praca codzienne, jest to zjawisko powszechnie znane i nie jest to formuła złośliwa wobec facebooka, a wyłącznie wobec zjawisk, jakie powoduje. 
  • Fakt, że wymienione przeze mnie przykładowo naprawdę ważne tematy są systematycznie odrzucane albo przez rady programowe, albo przez rynek (ludzie "chcą słuchać" innych rzeczy), to fakt. Że to, co jest ważne, nie jest często tym, czego chcą słuchać, jest do dowiedzenia i chętnie się tego podejmę na spotkaniu / łamach.
  • "Bałaganiarska sieczka a la ISTQB" jest formą  jak na mnie faktycznie dość ostrą, choć bardzo delikatną w porównaniu z poziomem debaty publicznej na te tematy na forach, ale też adekwatną do dwóch bardzo ważnych zjawisk: (1) tego, że prezentowana przez sylabusy ISTQB klasyfikacja technik projektowania testów jest zasadniczo błędna, niepełna i oparta na zupełnie nieumotywowanych założeniach; (2) że brak jest jakichkolwiek możliwości merytorycznej krytyki wobec założeń ISTQB, spowodowany monopolistyczną pozycją tej organizacji, i nieprzejrzystością jej działań oraz wymogami konformizmu. To zasługuje na bardzo mocną krytykę.
  • Odmowa mocnej dyskusji pod pretekstem bycia "urażonym" w sytuacji, gdy rzeczona organizacja i jej agendy prowadzi politykę mocarstwową i niedemokratyczną, przypomina stylistykę - proszę o wybaczenie określenia, którym znów ktoś może się poczuć urażony - debatę zagraniczną Rosji w sprawach wschodniej Ukrainy, czyli odwracanie kota ogonem. Jeśli ktoś (ISTQB) korzysta z uprzywilejowanej pozycji, nie może udawać wrażliwca, którego uraża mocna dyskusja. I uwaga - polityka bywa przedmiotem merytorycznym. Polityka ISTQB jest niemerytoryczna, lecz polityczna, ale działa obiektywnie na jakość wiedzy testerów. 
  • Zjawisko, że ludzie o modnych nazwiskach opowiadają na konferencjach wciąż te same rzeczy, a powodem ich udziału jest wyłącznie ich nazwisko, nie merytoryka, jest powszechnie znane i ma negatywne konsekwencje. W Polsce dochodzi niestety także - po 25 latach normalności - nadal moda na "zagraniczność" (na seminarium IPMA parę m-cy temu prelegent trafnie to opisał słowami "mówiłem to przez 5 lat, nikt nie słuchał, aż przyjechał jakiś Mike i nagle się wszyscy zafascynowali"). 
  • "Ciemny lud" - ostre i gorzkie słowa. Ponieważ uzyskałem niezależność poglądów i przynależności, i podjąłem decyzję, że nie będę dla uzyskania profitów nikomu schlebiał, nie muszę utrzymywać fikcji, że jesteśmy coraz mądrzejsi i dzielni. Mogę te słowa z łatwością uzasadnić setkami przykładów, albo wręcz udowodnić organizując egzamin. Mogę się powołać np. na wystąpienia Lee Copelanda (CzechTest 2013) i Martina Pola (HUSTEF 2013).
  • Określenie, że wobec "CI inżynieria wymagań jest archaiczna" nie jest moje, bo się z nim nie zgadzam, lecz je cytuję je. To kolejny przykład, jakiego to języka (a w tym blogu było to najłagodniejsze określenie, były też dużo gorsze) używają inni publicznie, masowo.
  • "Gadki-szmatki" - jak wyżej. Arogancja i agresywność Jamesa Bacha i Mikaela Boltona są legendarne, widoczne na forach dyskusyjnych, gdzie oni nieustannie obrażają, co ich nie wielbią. Ja mimo to treść części poglądów Bacha bardzo, bardzo sobie cenię.
Ostateczna propozycja

1. 17 i pół testerskich mitów. Świat mitów i legend w testowaniu wynikiem fejsbukizacji wiedzy. Social networking jest złą wyrocznią, chyba że w sprawach mody.

2. Agile Academy w Szwecji to szkoła policealna. W testowaniu potrzeba mniej inżynierów, a więcej techników. Czy testowanie powinno być więc wykładane w szkołach policealnych?

3. Jak projektować testy wg grafów, rachunku logicznego, teorii zbiorów oraz kombinatoryki, czyli pierwszy pełny i prawdziwy podział metod formalnych - z licznymi odniesieniami, jak ma się on do popularnej taksonomii ISTQB.

4. Zanik dobrej wiedzy testerskiej: czego nie wiemy, jakie modne słowa wyparły jakie dobre metody? Kto nie wie, kim był Boris Beizer?

5. Czy w świecie Continuous Integration projektowanie testów na podstawie wymagań jest archaiczne?

6. Ilościowe metody szacowania opłacalności testów.

7. Tak, testerzy są odkurzaczami i co to naprawdę znaczy? Kiedy lepiej porządkować, zamiast nie śmiecić? 

8. Możliwa rewolucja testowania uwzględniającego kontekst (context-driven testing) oraz HTSM

Brak komentarzy:

Prześlij komentarz