wtorek, 29 grudnia 2015

RE@BPM


Pełny artykuł w BPMstandard.pl
Ponadto, osoby zainteresowanych tematyką, zapraszam 23 marca 2016 na darmowe seminarium Stowarzyszenia Inżynierii Wymagań pod nazwą "RE@BPM".


W tytule proponuję trudne do zaakceptowania połączenie skrótów. „RE” to skrót od angielskiej nazwy inżynierii wymagań (requirements engineering), a BPM, jak doskonale wiecie, to skrót angielskiej nazwy zarządzania procesami biznesowymi (business process management). Na pozór, w codziennej praktyce, te dziedziny nie mają ze sobą wiele wspólnego, nawet nazwy zdają się należeć do różnych światów [...]

W rzeczywistości i w praktyce, obie te dziedziny łączą się ze sobą bardzo blisko, a ci, którzy jako pierwsi to dostrzegą i będą umieli wykorzystać, osiągną znaczną przewagę.


Kilka słów wprowadzenia do inżynierii wymagań

Inżynieria wymagań, to – według definicji ISO/IEC/IEEE 29119 – dziedzina interdyscyplinarna, zajmująca się metodami pozyskiwania, analizy, modelowania i konsolidacji wymagań, czyli założeń, które ma realizować konstruowany system informatyczny. [...]

Niezależnie od preferowanej nazwy, większość przyzna, że to dziedzina często zdumiewająco zaniedbywana, a dokładniej – realizowana jakby cichaczem, dyskretnie, ukryta za plecami innych. [...] Jakim cudem wobec tego sukcesem, czy choćby względnym sukcesem, kończy się jakikolwiek projekt? Otóż rolę analityka, lepiej lub gorzej, wykonują inni: kierownicy projektów, którzy muszą przecież choć w przybliżeniu znać cel działań, które nadzorują; programiści, mający niezwykły dar zarówno trafnego domyślania się, jak i talent do przeinaczania zleconych im do realizacji wymagań; wreszcie testerzy, których zadaniem, kiedy wszyscy inni zawiedli, jest zarówno zdobycie wymagań, jak i sprawdzenie, na ile testowany system je spełnia. [...]


Gdzie w BPM jest inżynieria wymagań?

Definiowanie procesów „as is”

Pierwszy krok BPM, czyli opis, czy diagnoza, aktualnego procesu biznesowego (as is), to niemal dokładnie ta sama czynność, którą analiza / inżynieria wymagań nazywają „pozyskiwaniem i wymagań”. [...]

W porównaniu z typowymi projektami IT, przedsięwzięcia BPM są w luksusowej sytuacji. Po pierwsze, decyzje o podjęciu BPM podejmowane są zwykle na wysokich szczeblach zarządzania, więc mają zasoby i poparcie, o których twórcy pojedynczych aplikacji mogą sobie tylko bezskutecznie pomarzyć. [...]

Negocjowanie wymagań

W inżynierii wymagań nie zapominamy, że różni interesariusze systemu IT zwykle mają także zróżnicowane poglądy na wymagania dla tego systemu – niekiedy wręcz przeciwstawne. [...]

Definiowanie procesów „to be”

Drugi obszar, gdzie technologie inżynierii wymagań mogą przydać się w zarządzaniu procesami biznesowymi, to projektowanie nowych, lepszych procesów, procesów zwanych przez BPM „które mają być”, czyli „to be”. Tak bowiem dzieje się w niejednym projekcie informatycznym, że kiedy klientowi przyjdzie do głowy, aby wesprzeć swój biznes jakąś aplikacją, systemem, to podczas zamawiania, a nawet – niestety - o wiele później, okazuje się, że tak naprawdę nie bardzo wiadomo, jakie procesy ten system ma wspomagać, albo że wymagają one przeróbek, poprawienia. [...]

Od wymagań do Javy w mgnieniu oka

Celem większości przedsięwzięć BPM jest najpierw zbudowanie, a potem modyfikowanie, ilekroć zajdzie potrzeba, kompleksowego, zintegrowanego systemu IT sterującego procesami biznesowymi, zwanego „BPMS” (Business Process Management System). Droga od modelu procesu, zapisanego w graficznym języku BPMN, do działającego systemu, prowadzi przez język BPEL (business process execution language, odmiana XML) do serwera, na którym skrypty BPEL są wykonywane, zwanego czasem „motorem BPEL” (BPEL engine). [...] trzeba więc wrócić na ścieżkę tradycyjną, skonstruować oprogramowanie w języku takim jak Java, C#, czy jednym w wielu innych. Opisując wymagania dla tych aplikacji, zwykle nie posługujemy się ani BPMN, ani BPEL, tylko – o zgrozo – językiem naturalnym, lub innymi językami modelowania, zwykle należącymi do rodziny UML. [...]


Nie tylko RE@BPM, ale także BPM@RM

Potencjalne korzyści współpracy idą w obu kierunkach. IT cierpi od początku swego istnienia, więc już blisko 70 lat, na problem z niejasnymi, niejednoznacznymi, często niespójnymi wymaganiami. Jest wiele przyczyn tego stanu rzeczy, ale głównym ich źródłem jest, moim zdaniem, nasze przywiązanie do języka naturalnego jako medium do porozumiewania się. Według wielu antropologów, powstanie języków wśród naszych przodków 100 – 50 tysięcy lat temu służyło głównie utrzymywaniu spójności grup hominidów, czyli relacjom, wzajemnemu „iskaniu się”, jak zabawnie wyrażają to badacze naczelnych. [...]


Jakość procesów

Podejście BPM zwykle – jeśli nawet nie w teorii, to w praktyce – bardzo wąsko widzi optymalizację procesów, którą stara się zrealizować na drodze od „as is” do „to be”. Dominuje nacisk na redukcję kosztów, którą zwykle osiąga się poprzez wyeliminowanie rzekomo zbędnych kroków i zadań procesu, zmniejszenie liczby uczestniczących w nim osób, lub likwidację czasowych wąskich gardeł.
Nie negując, że czasem procesy zawierają zbędne kroki czy zbędne zawiłości, aż proszące się o eliminację, to koszty są wyłącznie jednym z wielu atrybutów jakości procesu. Tutaj BPM może nauczyć się od inżynierii wymagań szczególnie dużo. [...]


Ulepszanie procesów w IT

Stare przysłowie „szewc bez butów chodzi”, w odniesieniu do procesów IT sprawdza się w 100%. Z jednej strony, IT dostarcza technologii, pozwalających na szybkie, elastyczne zmiany, na ulepszanie i automatyzację najbardziej nawet tradycyjnych procesów. Jednocześnie, swoje własne procesy, procesy wytwarzania oprogramowania, zwykle traktuje metodami z epoki kamienia łupanego. Standardy i sylabusy, popularne i autentycznie przydatne: PMI, PRINCE 2, ITIL, IPMA, IIBA, IREB, ISTQB, ISO 12207 – opisują swoje procesy… słowami. Rozbudowane metodyki oceny dojrzałości – np. CMMI, SixSigma, ISO 15504 („SPICE”), TMMi czy TPI oferują „jedynie słuszne” kryteria jakości procesów, ignorując potrzebę ich dostosowania do kontekstu. Nawet rodzina metodyk agile, choć akceptuje fakt, że wzorcowy proces nie musi, nie powinien nawet być zbyt szczegółowy, lecz oferować raczej minimalistyczne rusztowanie (framework) [...]

Pod tym względem BPM jest narzędziem, które – zastosowane do procesów samego IT – może stać się motorem jakże potrzebnej w IT zmiany.

sobota, 26 grudnia 2015

Pytanie do SJSI

Mam pytanie do SJSI... i myśl, czemu nikt go nie zadał wcześniej? Jak rozliczane są pytania egzaminu na certyfikat zaawansowany ISTQB?
 
Zadałem poniższe pytanie. A teraz zadaję to pytanie SJSI: jakie zasady obowiązują?

Concerning ISTQB CTAL exams, there is an unclear point, to which there is no answer to be found. Therefore, I kindly request you to clarify the following:

For those questions, to which TWO or THREE statements from the list constitute the right answer, what is the algorithm for calculating the number of points scored?
 

Examples:

If the choice of THREE statements is required, and the questions yields three points, and the examinee chooses only one correct one, and does not make the second and the third choice, then does she or he receive 0 or 1 point?
 

If the choice of THREE statements is required, and the questions yields three points, and the examinee chooses only two correct ones, and does not make the third choice, then does she or he receive 0, 1 or 2 points?

I presume, that when the choice of THREE statements is required, and the questions yields three points, and the examinee chooses two correct ones, and one incorrect, she or he receive 0 points.

In other words, if you are sure about two statements, but unsure about the third one, what is the right strategy for the examinee:

        (A) choose a probable third option, or
        (B) abstain from choosing it?

Strategy (A) is the only correct one, provided the answer to my question 2. above is "zero points", otherwise the examinee may choose between strategies (A) and (B), as both make sense.


Dostałem na nie następujące odpowiedzi:

Hi Bogdan, this is indeed an issue for clarification by the Exam WG. I have redirected your mail to Carol.

Te reguły są wyjaśnione w dokumentach egzaminacyjnych ISTQB. Na ich stronie są zasady punktacji.

[Mój komentarz: na portalu ISTQB są, owszem, pliki "Advanced Level Exam Information Sheet" oraz "ISTQB - 2012 Advanced Level Syllabi Exam Structure and Rules", ale żaden z nich pożądanej informacji nie zawiera]


Hi Bogdan,

If your board applies partial marking for multiple-answer (pick-n) questions, these are the rules as to how the marks are assigned. You need to check with your local board though as some boards were strongly opposed to partial marking and may not apply these rules (hence the reason it isn't in any public documents).



Carol

poniedziałek, 21 grudnia 2015

Życzę Wszyskim Miłości i Obfitości :)

Wesołych Świąt - życzę Wszystkim miłości i obfitości :)

Merry Christmas! I wish you all love and plenty :)
 
God Jul! Jag önskar er alla kärlek och myckenhet :)

Po co modelowanie wymagań?

Po co modelowanie wymagań? Po co testy integracyjne?

" Z treści pozwu złożonego w jednym z kalifornijskich sądów wynika, że luka, która byłą przyczyną błędów po raz pierwszy została odkryta w 2012 roku, krótko po premierze iPhone'a 5 oraz systemu operacyjnego iOS 6. Defekt związany był z interakcją pomiędzy systemem, a jednym z elementów nowego układu A6, odpowiedzialnym za bezprzewodową transmisję danych. W efekcie dochodziło do sytuacji, gdy iOS samoczynnie przełączał iPhone'a z trybu Wi-Fi do płatnego trybu mobilnej transmisji danych.

Z treści pozwu wynika również, że firma z Cupertino o problemie wiedziała już w 2012 roku, ale przez dwa lata w żaden sposób go nie rozwiązała. Dopiero wydany w październiku iOS w wersji 8.1 naprawił błąd."

(reszta tutaj)

Ciekawostka dla smakoszy ISTQB: "luka", "defekt", "problem" i wreszcie "błąd" :)

niedziela, 6 grudnia 2015

J’accuse!, czyli atak usterkowy

Uwaga: pełną wersję tego artykułu (czyli wprawdzie nie złagodzoną, ale nadal ocenzurowaną - nie chcę kłopotów) dostarczam (a) na życzenie mailem do bogdan.bereza@victo.eu; (b) uczestnikom moich kursów.

Mylę się? Proszę o kontakt: bogdan.bereza@victo.eu


Wstęp

   
Po raz siódmy w życiu :), napisałem niedawno nowe materiały do kursu podstawowego ISTQB.

Ostatnia wersja – sprzed kilku tygodni – udała mi się naprawdę! Sporo w niej szyderstw oraz kpin, ale również konstruktywnych wskazań, jak na tej glebie można jednak zasadzić i wyhodować przydatną, dobrą wiedzę. Że mi się dobrze to udało, mam twarde dowody:

Ankiety ze szkoleń, które z tymi materiałami prowadziłem, dają mi maksymalne oceny, a co ważniejsze – uczestnicy wysoko oceniają też wzrost własnej wiedzy, uzyskany w wyniku szkolenia. I świetnie zdają egzaminy – uśmiechami witając spodziewane, wcześniej przetrenowane, pytania typu „Podaj NAJWAŻNIEJSZĄ korzyść niezależnego testowania” :).

Śmiech śmiechem, ale patrząc z perspektywy 15 lat, trudno nie popaść w pesymizm. Może przesadą byłoby powiedzieć, że jest coraz gorzej - jest równie źle, jak było. Jednak w tym czasie, jak głosi ISTQB, blisko 400,000 osób zostało nakarmionych takim, pełnym bugów, zestawem wiadomości.
  
Bardzo chcę uniknąć ponownego narażenia się na kpiny, że narzekam – jakoby – zawodowo i na wszystko:
   
OCENZUROWANO, luty 26th, 2014 on 15:05
    
Dobrze podsumowane. Pan Bereza od dłuższego czasu kreuje się na krytyka wszystkiego. Z jednej strony to takie polskie, z drugiej gdzieś musi być granica. Myślę, że strasznie brakuje w jego publikacjach pokory. Coraz bardziej wygląda to na bajdurzenie dziadka: „w moich czasach [wstaw dowolne] było lepsze”.
      
Więc, nie chcąc narażać się mocarzom, wolałbym nie krytykować nawet ewidentnych „mądrości inaczej”, ale są granice. Po prostu sylabus poziomu podstawowego naprawdę zawiera tak wiele, tak oczywistych i tak poważnych błędów, że aż szokuje, a szkodliwość tego stanu rzeczy jest oczywista. Ponadto, przygnębiająca jest zupełna odporność ISTQB na zgłaszanie propozycji poprawek i zmian (po prostu nie istnieje żaden mechanizm ich zgłaszania, a maile w tych sprawach nie przynoszą efektów) – i nie można nawet mieć nadziei, że cokolwiek zmieni się na lepsze.

Domniemanie


Po pierwsze, boję się, że ten tekst zostanie zwyczajnie przemilczany. Przemilczeć go mogą ci wszyscy, co wprawdzie świetnie wiedzą, że mam rację, ale ZŁAGODZONE. Gorzej, że nie wezmą go sobie do serca również ci, którzy – dumni ze zdobytego z wysiłkiem certyfikatu, nie zechcą uwierzyć, że ZŁAGODZONE.

Czy nie widzę, jakie wybitne nazwiska autorów i współautorów zdobią sylabus, zaraz poniżej spisu treści? Czyżby oni wszyscy byli w błędzie, a Ty, robaczku, byłbyś jedynym sprawiedliwym?

Otóż nie jestem jedynym sprawiedliwym, a wielu – w tym cały świat kontekstowy, eksploracyjny – atakowało sylabus znacznie ostrzej niż ja, nie tylko wskazując pojedyncze defekty, lecz w ogóle podważając sens tego typu certyfikacji – z czym się nie zgadzam. Nie sądzę też, abym był o wiele mądrzejszy niż OCENZUROWANE. Winny jest nie „ktoś”, osoba, lecz niesprawny proces, nie dający szans na krytykę i poprawki, i ta specyficzna subkultura, gdy wszyscy legitymizują istniejący stan rzeczy.
   
Dlaczego więc reaguję dopiero teraz? Otóż reagowałem, pisałem – między innymi w „Professional Tester” – teksty rzeczowo krytykujące sylabusy ISTQB. Wysyłałem maile, na które mi czasem ktoś odpowiadał (np. w 2001 roku, jeszcze wówczas chodziło o podobne błędy w sylabusie ISEB, nie ISTQB), ale nic, z tego nie wynikało. W latach 2009-2011 byłem atakowany za krytyczne pod OCENZUROWANO adresem uwagi.
    
Przez długi czas postanowiłem dać nerwom odpocząć, zajmowałem się wieloma innymi dziedzinami i tematami. Ale klienci wciąż domagali się ode mnie, abym dostarczał im także wiedzę à la ISTQB, więc wróciłem do tego, i uświadomiłem sobie ponownie, z jeszcze większą ostrością, zły stan merytoryczny sylabusów, zwłaszcza podstawowego. Kiedy jeszcze wypróbowałem te moje najnowsze materiały, pełne uszczypliwości wobec sylabusa, i okazały się one cieszyć dużą popularnością i uczyć lepiej, niż dawne, spokojne, wówczas zdecydowałem się przerwać milczenie.
   

Temat główny

  
Napiszę to w punktach: nie chodzi mi o płynność wywodu, którą ktoś będzie mógł łatwo odrzucić, jako rzekomą przesadę, lecz o trudniejsze do zanegowania konkrety. Certyfikacja ISTQB, a w każdym razie jej sylabusy, wymaga głębokiej, radykalnej reformy.
   
      Sylabus kilkakrotnie odwołuje się do mocno staroświeckiej normy IEEE 829, ani słowem nie wspominając o ISO/IEC/IEEE 29119[1]. Inicjatora tej normy, OCENZUROWANE, można nie lubić, ale źle jest z tego powodu nie informować studentów o istnieniu tej normy.
     
           Rozdział 1.1 Dlaczego testowanie jest niezbędne? – testowanie nie jest „niezbędne”, tylko po prostu przynosi wiele korzyści, zaś jego brak jest ryzykowny. Cele propagandowe – chęć podniesienia statusu testowania – przeważyły widać w tym miejscu. Oczywiście, ten błąd (przepraszam, „usterka”) bierze się stąd, że sylabus najzupełniej pomija, lub wspomina tylko półgębkiem, kluczową prawdę, że testowanie jest tylko jedną z wielu metod zapewnienia jakości, często najmniej skuteczną i najdroższą. Podobnie jak ignoruje oczywistą biznesową prawdę, że wybór – mniej czy więcej testów – zależy też od przyjętej strategii ryzyka. Testować mało, a nuż nam się uda! – takie podejście może być słusznym, acz ryzykownym, wyborem.

1.1.1 Kontekst systemów softwarowych – uzasadnienie, że testy są ważne, bowiem IT jest bardzo rozpowszechnione, społecznie i cywilizacyjnie, jest słuszne, trywialne, i ostentacyjnie usiłuje dodać sobie powagi użyciem mądrze brzmiącego, ale zupełnie zbędnego (w tym kontekście :)), trudnego do zrozumienia, słowa „kontekst”.
     
o   [PL] Tłumaczenie polskie: „systemy softwarowe”? Czemu nie „oprogramowanie”, albo „systemy IT”, lub „systemy zawierające oprogramowanie”?
    
o   [PL] Tłumaczenie polskie: „usterki” w znaczeniu „defekty, bugi” budzą śmiech na każdym kursie, jaki prowadzę, bowiem po polsku to słowo znaczy „defekty (lub awarie) mało ważne, niegroźne”. Zaś o „pluskwach” chyba mało kto, poniżej 40 roku życia, słyszał.

            [PL] Tłumaczenie angielskiego „development” jako „rozwój” jest niezręczne. Zgoda, że to błąd powszechny. Zgoda, że forma językowa, początkowo błędna, z czasem staje się normą, ale tłumacze sylabusa nie powinni stać w awangardzie tych zmian, biorących się wszakże początkowo z niewiedzy. Angielskie słowo „development” ma dwa znaczenia, którym po polsku odpowiadają dwa najzupełniej różne słowa: (1) samoistny rozwój, ewolucja, przemiana (np. „rozwój gospodarczy” albo „rozwój intelektualny”), oraz (2) tworzenie, konstruowanie, budowanie. Oczywiście, „software development” oznacza konstruowanie, tworzenie oprogramowania, a nie „rozwój (samoistny) software’u”.
         
           Co autorzy sylabusa mieli na myśli, jako funkcję testów podając „podniesienie zaufania” (1.1.4), trudno zgadnąć. Jasne, że odczucia, emocje, takie jak ufność i spokój, mogą się pojawić w następstwie solidnie wykonanych testów, ale nie są one chyba celem testów? Celem, może być redukcja ryzyka, a towarzyszące temu uczucia raczej nas w tym kontekście nie interesują.
     
1.4.4 napisano: „Testowanie powinno być zintegrowane z innymi działaniami w ramach zapewnienia jakości (np. standardami kodowania, szkoleniami i analizą defektów)” – to dziwaczne twierdzenie jest – można się domyśleć – próbą wyrażenia tego, co zapomniano powiedzieć wyraźnie na początku, mianowicie, że testowanie jest tylko jedną z wielu czynności służących zapewnieniu jakości, i powinno „być zintegrowane” z inżynierią wymagań, z procesem zarządzania konfiguracją i zmianami, ze sposobami zarządzania projektem, z projektowaniem architektury systemów. Wymieniać w tym kontekście „standardy kodowania”, a zwłaszcza „szkolenia”, to podnosić jakieś najzupełniej nieistotne, uboczne aspekty, zamiast sedna sprawy.
     
1.1.4 ISO 9126? ISO 25010, które zstąpiło 9126, istnieje od kilku dobrych lat!
     
      „Weryfikacja podstawy testów przez projektowanie testów” (1.2) jest wprawdzie ogromnie ważna, ale to niezręczne i zawiłe sformułowanie wybitnie utrudnia słuchaczom zrozumienie tej prawdy. Kiedy wykonam już taniec świętego Wita, niezbędny do wytłumaczenia tego wyrażenia, i o co w nim naprawdę chodzi, na twarzach uczestników szkoleń pojawia się zrozumienie i mówią „aha, projektowanie testów według dokumentów testuje te dokumenty”! Trudno ująć to trafniej i prościej.
    
      1.3 Ogólne zasady testowania: tytuł sugeruje, że to jakieś naprawdę istotne, podstawowe, powszechne i najważniejsze zasady, a potem można jeszcze odnieść wrażenie, że jest ich dokładnie siedem – nie sześć ani nie osiem. Natomiast treść tego rozdziału, to jakieś drobiazgi, poniekąd prawdziwe, ale ogólnikowe, dość bezużyteczne, i na pewno nie najważniejsze. Od biedy, zaakceptowałbym treść rozdziału, gdyby jego tytuł brzmiał „kilka luźnych uwag o testowaniu”.
     
o   „Testowanie ujawnia usterki” (pominę terminologiczne pułapki, które sylabus zastawia i sam w nie wpada, bo testowanie, jak już wiemy, nie ujawnia usterek, lecz awarie) – to prawda, i także prawdą jest to, że zapominanie o tym czasem powoduje błędy w szacowaniu pracochłonności testów, ale to należy napisać w rozdziale „Planowanie i szacowanie”, a nie tworzyć jakąś rzekomą „ogólną zasadę”.
    
o   „Wczesne testowanie” oznacza, że – zgodnie z krzywą Boehm’a – zwykle warto testować wcześniej, a nie później. Dotyczy to zresztą nie tylko testowania, a wszelkich zmian. Można by tę zasadę wyrazić lepiej, jako np. „opłaca się testować wcześniej”, ale wtedy pasowałaby do rozdziału pod tytułem, „ekonomika zapewnienia jakości”, a nie jakieś „ogólne zasady testowania”.
    
o   „Paradoks pestycydów” wymyślił, o ile dobrze pamiętam, Boris Beizer. On miał prawo do swego swoiście kwiecistego języka, różnych zabawnych określeń, cytowanych obficie w „softwarequotes.com”, ale naprawdę, naprawdę prościej tę zasadę wyrazić słowami np. „kiedy zmienia się przedmiot testów, powinny się także zmieniać testy”, no i nie robić z tego truizmu rzekomej „ogólnej zasady”.
    
o   „Testowanie zależy od kontekstu” – to, że Cem Kaner, James Bach i Bret Pettichord kochają słowo „kontekstowy”[2] nie oznacza, że sylabus musi tę słabość podzielać. Można powiedzieć prościej: „to, jak testujemy, zależy od tego, co testujemy, po co i od rodzaju projektu”, albo skierować  czytelników wprost do HTSM James’a Bacha[3]. No i nie robić z tej oczywistości jakiejś pseudo-ważnej pseudo-zasady. Wszystko w tym świecie zależy od kontekstu, więc szerzenie mądrości typu „rodzaj noszonych spodni zależy od kontekstu”, to zwykłe upajanie się słowami.
   
o   „Mylne przekonanie o braku błędów” – kiedy w tym miejscu tłumaczę uczestnikom szkolenia różnicę między weryfikacją i walidacją, znaczenie celów biznesowych oraz inżynierii wymagań, jako dziedzin ważniejszych niż „testowanie”, to – kiedy to szybko zrozumieją – zastanawiają się, czemu tę zasadę wyrażać dziwnymi słowami „mylne przekonanie o braku błędów”?
   
o   PS. Oczywiście, nie „błędów”, lecz „defektów” :(
    
   1.4 Podstawowy proces testowy – sylabus opisuje go z wielkim namaszczeniem, i zapomina wyraźnie podkreślić, że to tylko przykład, skądinąd całkiem niezły, model dla celów dydaktycznych, a nie żaden „podstawowy”, wzorcowy proces testowania. Angielska nazwa „fundamental” jest jeszcze bardziej myląca. Rozdział powinien nazywać się „przykładowy proces testowy”.
     
    1.4.2 „Tworzenie dwukierunkowego śledzenia pomiędzy podstawą testów oraz przypadkami testowymi” jest zbędnie zawiłe w angielskim oryginale, a [PL] w polskim tłumaczeniu w ogóle nie wiadomo, o co chodzi? Oczywiście, zacny trener to studentom wytłumaczy, tak, jak dobry terapeuta, tylko może lepiej napisać sylabus od razu poprawnie, dobrze i jasno?
      
    1.4.3 Implementacja i wykonanie testów – trzeba naprawdę solidnej chęci, aby te dwie najzupełniej odrębne czynności, odrębne tak, jak np. smażenie kotletów różni się do ich zjadania, wrzucić do jednego worka. Zwłaszcza, że poziom zaawansowany rakiem wycofuje się z tego i znów – jak niegdyś sylabus ISEB – implementację i wykonanie traktuje oddzielnie.
      
    W tymże akapicie pojawia się „jarzmo testowe”. Już po angielsku, „test harness” robi dostatecznie wiele zamieszania i szkód, które niweluję, mówiąc, że to taka marketingowa nazwa, która jest nadużywana i znaczy cokolwiek, na przykład… i tutaj podaję listę przykładów, w miejsce namaszczonych elukubracji sylabusa. [PL] No, a romantyczno-średniowieczne „jarzmo”, dostarcza nam wiele zdrowego śmiechu, ale mało korzyści. Wg słowników, „harness” to zbroja, uprząż, szelki, zespół przewodów, albo nicielnica (!), więc można było to przetłumaczyć mniej śmiesznie. Ja – jeśli słuchaczami są programiści – mówię im o mockach i mock-upach…
      
     Mamy w tym rozdziale „procedury testowe” i „zestawy testów”, ale powszechnie używane określenie „scenariusze testowe” autorom sylabusa jakoś umyka :(. Szkoda.
     
   1.4.4 Ocena spełnienia kryteriów zakończenia i raportowanie – wyrażenie: „kiedy można zakończyć testy?” byłoby dużo, dużo prostsze, ale mniej imponujące. Co w tej fazie robimy? „Sprawdzanie w logach, czy kryteria są spełnione” – szukam ludzi, którzy kiedykolwiek grzebali w tym celu w jakichś logach (?!), ale jeszcze ich nie znalazłem.
    
o   „Ocena, czy potrzeba więcej testów” to Mount Everest niejednoznaczności: może znaczyć, czy trzeba więcej testów zaprojektować, czy też więcej – jeszcze niewykonanych – testów wykonać, czy może jeszcze raz wykonać regresję? Zastanawianie się, czy „potrzeba więcej testów [zaprojektować]” jest zresztą domeną projektowania testów, a nie „oceny zakończenia”.
   
o   „Raport podsumowujący” – a inne raporty? Nie ma o nich mowy nawet w sylabusie zaawansowanym...
   
     [PL] 1.4.5 „Testalia” – hej, drodzy tłumacze, ja to słówko wymyśliłem w 2002 roku dla żartu, a Wy je stosujecie ze śmiertelną powagą!

 Testalia na juwenaliach?

    1.5 Psychologia testowania – Garść niby-psychologicznych spostrzeżeń pra-babci. Autentycznie istotne w tym kontekście „tester nie jest odkurzaczem” Hansa Schaefera[4] oraz „testowanie jako choroba współuzależnienia” Lee Copelanda[5] nie są wymienione.
     
     1.6 Kodeks etyczny – brzmi fałszywie. Tester, jak każdy, ma prawo, a może nawet powinien, rozważać sprawy etyki, wartości i celów w życiu, ale po pierwsze, nie trzeba ich szukać w żadnym technicznym dokumencie, a po drugie, nie istnieje też żadna specjalna etyka dla testerów – etyka jest po prostu dla ludzi, niezależnie od zawodu.
    
o   Podane konkretne zasady są sprzeczne wewnętrznie i niemożliwe do realizacji, Np. jak tester ma „brać pod uwagę interes publiczny” Bo będą różne wykładnie...
   
    2.1.1 Model V – skąd w tym rozdziale wziął się skok do CMMI (czemu nie do SPICE?), i po co on jest? Czemu nie do PRINCE 2 albo PMBOK, albo BABOK? Rozumiem, model V może się kojarzyć z wieloma rozmaitymi rzeczami, ale sylabus, to nie test Rorschacha[6] :(.
             
Tester Rorschacha :)

    2.1.2 Modele iteracyjno-przyrostowe, ładnie, i nagle – bomba! „Każdy przyrost może podlegać zarówno weryfikacji, jak i walidacji”. Niezmiernie to oryginalne miejsce, żeby rozważać, skądinąd ważną, różnicę między weryfikacją i walidacją. Czytelnik sylabusa ma nieodparte wrażenie, że to pojęcia odnoszące się wyłącznie do modeli przyrostowych. 
     
    Rozdział 2.2 Poziomy testów, głosi we wstępie, że „podczas planowania testów powinno zostać uwzględnione również testowanie danych konfiguracyjnych”. No, tak… oraz testowanie interfejsów, wszelkich danych, wykonywania kopii zapasowych, dokumentacji, łatwości użytkowania… 1000 różności. To wyróżnienie właśnie tajemniczych „danych konfiguracyjnych” wygląda, jakby...
    
    Rozdział 2.2.2 Testy integracyjne twierdzi, że podstawą dla projektowania testów integracji mogą być „projekt oprogramowania i systemu, architektura, przepływy procesów, przypadki użycia”. Wiję się, usiłując wytłumaczyć słuchaczom, co autorzy sylabusa mogli mieć na myśli, odrębnie traktując „projekt oprogramowania” oraz „architekturę” (to jedno i to samo, prawda?), oraz dlaczego tak niezwykle wyróżnili jeden z czternastu (!) diagramów UML, diagramy przypadków użycia (czy może same „przypadki użycia”? – trudno to zgadnąć!), a pominęli m.in. diagramy sekwencji i diagramy aktywności, i czemu diagramy BPMN nazwali tajemniczo „przepływami procesów”?
     
    2.2.3 Testy systemowe – możemy się tutaj dowiedzieć, że „wymagania” i „przypadki użycia” to dwie różne rzeczy. Drżyj, inżynierio wymagań! Jesteś w błędzie, naiwnie sądząc, że przypadki użycia, to jeden z wielu, wielu sposobów modelowania/opisywania wymagań. Drżyjcie, twórcy UML! Bo oto z UML zniknęły diagramy aktywności oraz diagramy przejść stanów, diagramy sekwencji, diagramy klas, diagramy komponentów i wszystkie inne. Najlepiej drżyjmy wszyscy, bo dokąd idziemy, skoro 400.000 ludzi zdawało wg tego egzamin?
     
    [PL] Tłumaczenie: „techniki, oparte na specyfikacji”, przypominają mi dowcip OCENZUROWANO. Specification-based to nie „oparte na specyfikacji”, tylko „według specyfikacji” lub „na podstawie specyfikacji”. Nagminność tego błędu, nie usprawiedliwia tłumaczenia; skoro powszechność ma być poprawnością, to równie dobrze sylabus mógłby zrezygnować z ortografii.

     Przy okazji, czemu testy biznesowe nazwać „testami na podstawie specyfikacji”. A co będzie wobec tego z testami, projektowanymi na podstawie specyfikacji architektury, struktury?
     
    Oczywiście, miary pokrycia testowego istnieją zarówno dla testów czarnej skrzynki (np. pokrycie funkcji, pokrycie wymagań, pokrycie modelu działania systemu), jak i dla testów strukturalnych. Po lekturze sylabusa pozostaje jednak nieodparte wrażenie, że pokrycie testowe dotyczy tylko testów strukturalnych, a – po zaliczeniu absurdalnego rozdziału 4-ego – że to w ogóle ciekawostka dla programistów, pokrycie kodu źródłowego. Jasne, jako trener, wyjaśniam, jak jest, ale dlaczego nie robi tego porządnie sylabus? Czemu sylabus jest taki niejasny? Można przecież, nie naruszając rzetelnych podstaw, te wszystkie błędy (usterki) łatwo naprawić, więc dlaczego, dlaczego nie robi się tego?
     
    [PL] 2.4 Testowanie pielęgnacyjne – pomyśleć tylko, że kiedyś „maintenance testing” tłumaczono dobrze na „testowanie w fazie utrzymania”, ale przerobiono to na lekko komiczne i niejasne „pielęgnacyjne” :(.
    
Testowanie pielęgnacyjne?

    3.1 Techniki statyczne a proces testowania – twierdzenia, że testy statyczne i dynamiczne mają „wspólny cel” oraz „uzupełniają się” nazywam, ku radości uczestników moich kursów, „arią Brunhildy”[7], bo podobnie jak opery Wagnera, są górnolotne, ale nic nie znaczą.
   
    3.2 Proces przeglądu. Owszem, przeglądy są ogromie ważne i wykonywane o wiele częściej, niż wymawiane są niemodne słowa „przeglądy” oraz „inspekcje”. Owszem, przeglądy, tak samo jak testy (dynamiczne) należą do tej samej, wielkiej rodziny metod sprawdzania i weryfikowania, ale oczywiście – nie ja pierwszy to mówię – nigdy i nigdzie firmy nie zatrudniają testerów, żeby je nadzorowali czy organizowali. Równie dobrze można ten rozdział o przeglądach umieścić w kursach programowania w Java czy administrowania routerami Cisco.
    
    3.2 raz jeszcze. Owszem, przeglądy można wykonywać na wiele różnych sposobów. Można też zniechęcić do nich, omawiając je według oderwanego od realiów projektowych modelu IEEE 1028, z którego ten rozdział sylabusa jest przepisany.
      
    4.2 Kategorie technik projektowania testów. Jest po prostu nieprawdą rzekomy trój-podział na techniki (1) „czarnej skrzynki”, (2) „białej skrzynki” oraz (3) „na podstawie doświadczenia”. Otóż, prosta prawda jest taka, że są dwa podziały, jeden na osi „formalne – nieformalne”, a drugi na osi „biała skrzynka – czarna skrzynka”. Podejścia do projektowania testów można więc bardzo z grubsza wprawdzie, ale trafnie, podzielić na cztery grupy, czy obszary: (1) nieformalne czarnej skrzynki; (2) nieformalne białej skrzynki; (3) formalne czarnej skrzynki i (4) formalne białej skrzynki. Jasne? Jasne. Można tak napisać w sylabusie? Można, ba! – nawet należy.
    
    4.2 raz jeszcze: czytamy twierdzenie, że w technikach czarnoskrzynkowych przypadki testowe można tworzyć z modeli, stosowanych do specyfikacji. Na pierwszy rzut oka, bezpiecznie, choć jak zwykle niezwykle zawile. Ale prawdziwa groza czai się tuż za rogiem. Zacytuję:
    
Cechy wspólne technik projektowania testów opartych na specyfikacji, to m.in.:
·         w specyfikacji problemu do rozwiązania, oprogramowania lub jego komponentów używane są modele
·         z tych modeli można, w sposób usystematyzowany, wywodzić przypadki testowe
   
I zaraz poniżej:
   
Cechy wspólne technik projektowania testów opartych na strukturze, to m.in.:
·         […]
·         można mierzyć stopień pokrycia istniejących przypadków testowych, można też w sposób usystematyzowany tworzyć nowe przypadki testowe w celu zwiększenia pokrycia
   
Czy jest jasne, co głosi sylabus? Podkreślam: sylabus ISTQB CTFL, twierdzi, że projektowanie testów na podstawie modeli stosuje się tylko w podejściu czarno-skrzynkowym. Żegnajcie, testy zaprojektowane na podstawie diagramów klas lub diagramów komponentów; adiόs, testy protokołów komunikacyjnych, stworzone przy pomocy diagramów sekwencji! Według ISTQB, nie istniejecie!
   
Ponadto, tenże sylabus głosi, że projektowanie testów w celu zwiększenia pokrycia, jest specyficzne wyłącznie dla projektowania na podstawie struktury. Żegnajcie, miary pokrycia wymagań! Żegnaj, pokrycie ryzyka, to nasza ostatnia niedziela! Żegnajcie, rozmaite miary pokrycia grafów i modeli – już nie istniejecie :(.
   
·         4.3.3 Testowanie na podstawie tablicy decyzyjnej ([PL] w sylabusie, oczywiście „w oparciu o tablicę”, za co jestem tłumaczom wdzięczny, bo czas już w materiałach wkleić zabawną ilustrację: tester, oparty o tablicę). Wypadałoby wspomnieć, że ta sama technika bywa często nazywana testowaniem na podstawie grafów przyczynowo - skutkowych.
    
Testowanie w oparciu o tablicę!

·         4.3.4 Testowanie przejść między stanami – czyżby naprawdę zniknął już koszmar „pokrycia zero-, jedno- i dwuprzełącznikowego”, z powodu których kursanci dochodzili kiedyś do krawędzi samobójstwa? Cieszmy się! Być może jednak, tylko w sylabusie tych nazw nie ma, ale nie wiem na pewno, co czai się, w pytaniach: na wszelki wypadek, przygotowuję moich uczniów i do tego.
    
·         4.3.4 Testowanie według przypadków użycia – po raz nie wiem już, który, przypominam, że UML oferuje 14 różnych modeli, z których diagramy przypadków użycia jest tylko jednym (1/14 = 7%), więc niezrozumiała ta ich nieuzasadniona kariera. Sorry, przecież wcześniej są omówione diagramy przejść stanów, to daje 2/14, czyli aż 14%... nadal to za mało. Do pewnego stopnia, to ograniczenie znika w nowym sylabusie „ISTQB MBT”, więc OCENZUROWANE (jego autorzy) rozumieją te sprawy. Pomożecie kolegom od CTFL? [PL] Postscriptum: w polskiej wersji mały lapsus, w tytule sekcji, napisano „przypadki testowe”, zamiast „przypadki użycia”.
    
Nie, nie twierdzę, że trzeba w CTFL uczyć wszystkich czternastu modeli UML, plus modeli spoza UML. Można wybrać, jako przykład, przypadki użycia, ale trzeba wówczas koniecznie podkreślić, że to tylko przykład – jeden z wielu możliwych.
    
·         4.3.4 ma jeszcze solidne błędy w środku. „Przypadek użycia opisuje interakcje pomiędzy aktorami (użytkownikami lub systemami), które powodują powstanie wyniku wartościowego z punktu widzenia użytkownika lub klienta”. 200% nieprawdy! Interakcje opisuję diagram przypadku użycia, nie „przypadek użycia”, ale nawet diagram nie opisuje interakcji między aktorami, lecz interakcje między aktorami oraz przypadkami użycia (funkcjami systemu).
     
Dalej, opisując korzyści tego sposobu projektowania, już w miarę poprawnie opisane są testy według przypadków użycia, a nie diagramów przypadków użycia. Szkoda, że pominięto przy okazji korzyści projektowania testów także na podstawie tych diagramów… ale nie chciejmy za wiele.

Last but not least, cały ten lekko poetycki felieton o testach na podstawie przypadków użycia, którym częstuje nas sylabus, warto by zastąpić prostym diagramem przypadku użycia (rysunkiem) i wyjaśnieniem, że przebieg („przepływ”, jak napisano w sylabusie) można opisywać na wiele sposobów, słownie, lub przy pomocy innych modeli, np. diagramów aktywności lub BPMN.
   
·         4.4 Techniki białoskrzynkowe – rozdział stwarza nieodparte wrażenie, że wśród technik projektowania testów na podstawie kodu źródłowego, dominujące czy wręcz jedyne jest projektowanie w celu osiągnięcia pokrycia kodu: „W tym podrozdziale omówione są trzy strukturalne techniki projektowania testów związane pokryciem kodu bazujące [PL - !!!] na instrukcjach, decyzjach oraz rozgałęzieniach”. Należy choć wspomnieć, że stosuje się wiele innych, np. – to name just a few – testowanie granic wektora, testowanie obsługi wektorów i list, testowanie obsługi stosu lub kopca, testowanie kolejek, testowanie modułów z różnymi wartościami parametrów…
      
·         Rozumiem, że chcąc sprawdzić na egzaminie sprawdzić, czy testowany osobnik zrozumiał, czym są miary pokrycia instrukcji oraz decyzji, można dawać mu do rozwiązania dziwaczne łamigłówki, wymagające, aby dla kawałka pseudokodu określać minimalną liczbę przypadków testowych, potrzebnych dla osiągnięcia np. 100% któregoś pokrycia. Należy jednak wyraźnie podkreślić, że rozwiązywanie takich łamigłówek, to sztuczka, którą warto opanować wyłącznie na potrzeby egzaminu – nikt, nigdy i nigdzie nie będzie potrzebował tej umiejętności w rzeczywistości. Trzeba to podkreślić.
     
·         4.5 Projektowanie testów na podstawie doświadczenia” to rozdział, w którym – zgodnie z „4-ą ogólną zasadą testowania” (tą z rozdziału 1.3 Ogólne zasady) o kumulowaniu się błędów (powinno być „defektów”)… więc zgodnie z tą zasadą, defekty szczególnie skumulowały się w tym właśnie rozdziale 4.5. Więc, darujcie mi, wymienię tylko te zabawne, brak mi siły na inne, bo w końcu nie chcę – nie w tym artykule – napisać całego sylabusa od nowa. Poza tym, chętnie...
     
„Szeroko wykorzystywaną techniką opartą na doświadczeniu jest zgadywanie błędów. […] testerzy przewidują usterki” – aha, to jednak nie zgadujemy „błędów”, lecz usterki. Uczestnicy kursu, przerwa na śmiech.

Angielskie „fault attack” jeszcze jakoś zniosę, choć to kiepska, myląca nazwa na względnie mało istotny sposób testowania… Ściślej, istotny, ale jako element podejścia eksploracyjnego; dziwnie wygląda tak wyrwany z kontekstu. Jednak laury należą się tłumaczom, bo „atak usterkowy” :), zilustrowany w moich nowych slajdach fotografią natarcia z filmu „Mad Max”, poprawia wszystkim humor na długo.
Atak usterkowy :)

·         5.1 Organizacja testów – jest w tym obszarze wiele ważniejszych zagadnień, niż ponowne (po 1.5 Psychologia testowania) roztrząsanie zalet i wad niezależności testowania. Wybór autorów sylabusa jest, aby opowiadać o nich – to błędny wybór.
   
·         5.1.2 Zadania lidera testów oraz testera zastępuję tutaj opis śmiesznymi obrazkami, bo trudno mi z poważną twarzą opowiadać uczestnikom, co też takiego robi tester, a co kierownik testów, jakby tego nie wiedzieli.
    
Czytelniku, przyznam Ci się – wymiękam! Zaczynałem pisać ten tekst z ogniem w duszy, czułem się dzielnym bojownikiem, ale pisząc, poczułem przygnębienie. Jest takie angielskie przysłowie: „zanim prawda zdąży nałożyć buty, defekt już obiegnie świat”, czego ta sprawa jest smutnym potwierdzeniem.

Więc tylko na jeszcze jeden temat sił mi starczy.
   
5.2.6 Podejście do testowania, strategia testowania: analityczne, według modeli, metodyczne, zgodne ze standardem, dynamiczno-heurystyczne, konsultatywne, regresywne. Skąd wzięła się ta klasyfikacja?
   
Wydaje się, że znikąd: długie poszukiwanie w Internecie ujawnia jej istnienie na wielu stronach, poświęconych… zgadliście, egzaminom ISTQB; bywa w książkach – podręcznikach do certyfikacji ISTQB, i na blogach o podobnej tematyce.
    
Po prostu, wydaje się, że prawo Murphy’ego, głoszące, że dostatecznie duża organizacja nie potrzebuje świata, bo sama sobie stwarza zadania i pozorne cele, sprawdza się tutaj w zupełności. Ktoś wie coś więcej? OCENZUROWANI, pamiętacie, czy ta klasyfikacja „podejść” była już w sylabusie ISEB, pisanym w latach 1997-1998[8], czy pojawiła się dopiero później? OCENZUROWANY, u ciebie znajduje się szczególnie obszerny opis tych strategii[9] – czy ujawnisz jego źródła?
   

Zakończenie

  
Sylabus ISTQB CTFL trzeba koniecznie przerobić i poprawić. Nie radykalnie, bo to trwałoby bardzo długo, zaburzyło ciągłość i zapewne – zaowocowała nowym, tyle że odmiennym, chaosem. Należy po prostu zostawić szkielet – lepszy czy gorszy, bo powszechna wiedza testowa zakłada jego istnienie i taką, a nie inną, strukturę – ale wymienić ściany, okna i drzwi, wywód uprościć i uczynić zrozumiałym. Powinien to zrobić zespół najwyżej 3-4 osobowy, a nie wielkie międzynarodowe gremium.
    
A jeśli nie? No cóż, nie będę kłamał: świat się od tego nie zawali. Znam wiele innych błędnych tekstów… i jakoś słońce wciąż wschodzi :).