czwartek, 13 lipca 2017

Rano do Krakowa

Na Dworcu Wschodnim: pachnie metalem, plastikiem, jarzeniówkami i WiFi / Warsaw East Station smells metal, plastic and glow tubes:

Czekamy na peronie, moja wysłużona torba mnie pilnuje, żebym się nie oddalał nigdzie / We're waiting on the platform, my long-serving bag looks after me so that I do not go away anywhere

Czemu na dworach ludzie nawykowo nerwowo truchtają? Nie można po prostu CHODZIĆ? / Why do train stations make people scamper? Why can't they just WALK?

Ach, kochany Dworzec Wschodni! Jestem w pierwszy w pustym wagonie :) a w dodatku to Strefa Ciszy - genialny wynalazek :) / Ah dear East Station. I am the first and only person in the empty carriage. And besides it is the Quiet Zone - a wonderful idea!


Już wchodzę w nieprawdziwy świat... komputer włączony / Here I enter the fictiuous world - my computer is switched on:

środa, 12 lipca 2017

Bestiariusz testera oprogramowania



Bestiariusz testera oprogramowania

1.

Podstawy to testowania, przepiękne i ważne są wielce
Gdy czytać będziesz ten rozdział, miej serce i patrzaj w serce!

1.1

Dlaczego testować niezbędnym?
Spytajcie mędrców i wieszczy:
Bez testów świat się rozleci,
Albo co najmniej zatrzeszczy!

1.1.1

Bo softwarowe systemy w kontekście siedzą, jak wiecie
i każdy z nas jest kontekstem, nawet starzec i dziecię.
Jeśli awaria się zdarzy, stracisz pieniądze lub życie!
Czyli ten kontekst jest ważny, co chyba już sami widzicie?

1.1.2

Błądzić jest rzeczą ludzką! I błądzić, i nawet mylić,
I bach! Już pełno defektów, usterek wielkich jak słonie,
Awaria goni awarię, huk słychać i w jednej chwili
Kontekst się cały posypie i świat beznadziejnie utonie.

Refren:

Warto więc włożyć wysiłek, by nie popełniać pomyłek!
Zamiast pracować pod presją, lepiej się schowaj pod krzesło,
Unikaj też zanieczyszczeń, to software będzie się błyszczeć!
Wiedz, że i w dokumentach, defekt się czasem przypęta .

Ciąg dalszy nastąpi!

niedziela, 9 lipca 2017

Szare korzenie pięknych kwiatów



W tej chwili w Polsce około 10-12 tysięcy osób ma tak zwany „certyfikat ISTQB z testowania oprogramowania”. Większość mieszkańców naszego pięknego kraju nie tylko nie zna tego certyfikatu, ale nie ma pojęcia, czym jest to tajemnicze „testowanie”. Oczywiście, słyszeli o jakichś programistach, podobno mają fantastyczne pensje, ale testerzy? To pewnie kolejny modny i nie bardzo potrzebny wymysł, jak jacyś animatorzy kultury, specjaliści delfino-terapii, czy inni architekci krajobrazu? 

No dobra, dobra, myślicie: wróćmy do ważnych tematów, takich jak rozwój osobisty, jak stać się kobietą spełnioną/mężczyzną spełnionym, może dieta, może wegetarianizm, może muzułmańska imigracja, może wypadek smoleński, może istota objawień fatimskich, a najlepiej coś ze słowem „zarządzanie” w nazwie 😊?
  
Tymczasem ja dziś właśnie wyszkoliłem kolejną 20-kę – to już pewnie, licząc od 1997 roku, środek trzeciego tysiąca moich absolwentów - do egzaminu na ten certyfikat… kandydatów na testerów oprogramowania. Większość, to ludzie z wyższym wyksztalceniem (trafiają się, z rzadka wprawdzie, także osoby z doktoratami), niektórzy bezrobotni, inni szukający nowej, lepszej pracy, gdzie będą się czuli potrzebni. Branża IT krzyczy, woła o takich ludzi, podczas gdy wyższe uczelnie tradycyjnie produkują fachowców technicznych, ale często pozbawionych umiejętności zastosowania techniki w kontekście; stąd potrzeba testerów i analityków (ich również produkuję, ale nie tak masowo, jak testerów).

Jeśli za dwadzieścia i trzydzieści lat polska gospodarka – i światowa, nie tylko w Polsce są te trendy - będzie – mimo naszej skłonności do okresowych napadów mistyczno-nacjonalistycznego szaleństwa – dawała na ziemi pokój i dostatek ludziom dobrej woli…

… jeśli systemy informatyczne, tkwiące do tego czasu w każdym bucie, w każdym oknie i w każdej szczotce do zębów, będą działały ku naszej wygodzie, a nie ku naszemu utrapieniu…

… to będzie w tym znaczna zasługa także tych ludzi, których wyszkoliłem, których szkolę i których będę jeszcze szkolił.

Dla mnie ta przygoda zaczęła się dawno, dawno temu, kiedy czułem się i byłem naprawdę ostrym hakerem, kochającym mikroprocesory, kolegów (i koleżanki) elektroników, asemblery oraz język „C”. Przez trzy godziny przekonywał mnie jesienią 1993 roku, nieżyjący już Thomas Vesterlund, żebym te zabawki porzucił na rzecz sztuki, o której wtedy myślałem, że jest dla cieniasów – dla testowania.

Zaryzykowałem.

W 1998 roku niezawodni Anglicy wymyśli, że warto stworzyć certyfikat dla osób, co chcą specjalizować się w tym rzemiośle i nazwali go certyfikatem ISEB CTFL – to był zapomniany już prekursor tych certyfikatów ISTQB, których dziś jest na świecie ponad pół miliona w ponad pięćdziesięciu krajach świata. Z mojej inicjatywy powstał wtedy, na początku 2000 roku, pierwszy poza Wielką Brytanią kurs, przygotowujący do egzaminu na ten certyfikat: w Szwecji.

W 2001 roku przyniosłem ten pomysł do Polski. Początkowo spotkałem się z oporami, ale za to cieszyłem się monopolem; to ja szkoliłem wtedy wszystkie dzisiejsze tuzy, wielkich przedsiębiorców tej branży. Brawo, dziewczyny i chłopaki! Miło, że mogę dziś pracować czasem dla Waszych firm 😊.

Monopolu nie da się utrzymać długo, dzięki czemu nie ustaje motywacja, aby iść dalej, uczyć się nowych rzeczy. Wspaniale – nie cieszyłaby mnie rola podstarzałego guru, wyłącznie wspominającego dawne, dobre czasy i zadowolony jestem, że poszedłem w inne, równie ciekawe dziedziny. Ale nie ukrywam – dzisiejszy gwałtowny renesans testowania i ten jego bezprecedensowy, kwantowy skok wydajności – cieszą mnie! Rola podstarzałego guru, mogącego się przechwalać: „A widzicie? Co mówiłem ćwierć wieku temu, ha?!” - bardzo mi się podoba, pod warunkiem, że (a) nie jest to jedyna rola, którą mogę odgrywać, i (b) że nie kończy się na wspominaniu 😉.


sobota, 18 marca 2017

ROZWIĄZANIE ZAGADKI


Zagadka była taka:

Jesteś analitykiem testów w projekcie, wytwarzającym oprogramowanie dla pomp, instalowanych na dnie morza pod norweskimi platformami wiertniczymi. Niektóre funkcje tego oprogramowania są zaklasyfikowane jako krytyczne dla bezpieczeństwa, a niektóre - nie. Kierownik całego projektu ma na imię Björn, włosy blond i jego dotychczasowe doświadczenie jest głównie z dziedziny gier komputerowych, aplikacji na Android oraz programowania w PHP.

Klient - główny producent pomp - stawia wymaganie, aby oprogramowanie było zgodne z normą ISO 26262, która zawiera między innymi wskazówki, dotyczące wymaganego poziomu pokrycia kodu w kontekście konkretnego przepływu sterowania przez punkty decyzyjne, które ma być kalkulowane przez podzielenie liczby wyników decyzji pokrytych przez (zaprojektowane lub wykonane) przypadki testowe przez liczbę wszystkich wyników decyzji znajdujących się w testowanym kodzie.

Uczestniczysz w nisko-formalnym przeglądzie koleżeńskim tekst krótkiego memoriału, skierowanego do kierownictwa projektu i mającego uzasadnić, dlaczego potrzebne jest więcej czasu, aby przetestować dostarczany kod zgodnie z tymi wytycznymi. Poniżej znajduje się pięć zdań, wybranych z tego memoriału:

i. Istnieją techniki jeszcze mocniejsze niż pokrycie decyzji, na przykład pokrycie warunków lub wielokrotne pokrycie warunków, wymagające zwykle wykonania większej liczby testów, niż pokrycie instrukcji; [T]

ii. W testowaniu integracyjnym odsetek modułów, komponentów lub klas, które zostały przetestowane przez zestaw testów można wyrazić jako pokrycie instrukcji,
decyzji lub ścieżek. [F]

iii. Gałęzie zaczynają się w punktach decyzyjnych i pokazują przekazanie sterowania do różnych modułów lub systemów. Testowanie gałęzi różni się od testowania decyzji przez to, że skupia się na samych decyzjach. [F]

iv. W technice testowania strukturalnego projektuje się przypadki testowe, tak by wykonać określone instrukcje, zwykle po to żeby zwiększyć pokrycie modułowe. [F]

v. Pokrycie instrukcji oblicza się przez podzielenie liczby wykonywalnych instrukcji pokrytych przez (zaprojektowane lub wykonane) przypadki testowe, przez liczbę wszystkich wykonywalnych instrukcji w testowanym kodzie. [T]

A. (iii), (iv) i (v) są fałszywe, (i) i (ii) są prawdziwe
B. (v) jest prawdziwe, (i), (ii), (iii) i (iv) są prawdziwe
C. (i) i (v) są prawdziwe, (ii), (iii) i (iv) są fałszywe.
D. (i), (v) i (ii) są prawdziwe, (iii) i (iv) są fałszywe.
Rozwiązanie:

i. Zdanie "Istnieją techniki jeszcze mocniejsze niż pokrycie decyzji, na przykład pokrycie warunków lub wielokrotne pokrycie warunków, wymagające zwykle wykonania większej liczby testów, niż pokrycie instrukcji;" jest po prostu, zwyczajnie prawdziwe, pod warunkiem, że rozumiemy tajemnicze słówko "mocniejsza" w odniesieniu do techniki [pierwszy akapit 4.4.3 w sylabusie].

ii. Zdanie "W testowaniu integracyjnym odsetek modułów, komponentów lub klas, które zostały przetestowane przez zestaw testów można wyrazić jako pokrycie instrukcji decyzji lub ścieżek." jest przeróbką poprawnego zdania (akapit drugi 4.4.3) z podmienieniem słów "można wyrazić jako pokrycie modułów, komponentów lub klas" (poprawne) na słowa "pokrycie instrukcji decyzji lub ścieżek" (dobre dla pokrycia kodu, niedobre dla pokrycia modułów czy klas).

iii. Zdanie "Gałęzie zaczynają się w punktach decyzyjnych i pokazują przekazanie sterowania do różnych modułów lub systemów. Testowanie gałęzi różni się od testowania decyzji przez to, że skupia się na samych decyzjach." jest wszechstronną przeróbką z kilkoma błędami autentycznego zdania z sylabusa: "Gałęzie zaczynają się w punktach decyzyjnych i pokazują przekazanie sterowania do różnych miejsc w kodzie. Testowanie gałęzi różni się od testowania decyzji przez to, że skupia się na samych gałęziach.". W oryginale jest "Branches originate from decision points in the code and show the transfer of control to different locations in the code" - dodatek "Testowanie gałęzi różni się od testowania decyzji przez to, że skupia się na samych gałęziach." to już inwencja tłumaczy :) fajna skądinąd, takie "skupienie się na gałęziach" brzmi godnie i tajemniczo ;) Jeśli kogoś różnica, prócz "skupienia na gałęziach", interesuje, to jest fajny opis tutaj: https://quorum.akademiq.pl/discussion/225/testowanie-decyzji-vs-testowanie-rozgalezien/p1.

iv. Prosty numerek, w zdaniu "W technice testowania strukturalnego projektuje się przypadki testowe, tak by wykonać określone instrukcje, zwykle po to żeby zwiększyć pokrycie modułowe."  słowo "instrukcji" zamineiłem na słowo "modułowe". Ha, ha!

v. To po prostu cytat z sylabusa: "Pokrycie instrukcji oblicza się przez podzielenie liczby wykonywalnych instrukcji pokrytych przez (zaprojektowane lub wykonane) przypadki testowe, przez liczbę wszystkich wykonywalnych instrukcji w testowanym kodzie." 

Miłęj zabawy!


Nowe pytania ISTQB - strach ma wielkie oczy?


Od lutego krążą wielkookie opowieści, o nowych zestawach polskojęzycznych pytań na egzamin ISTQB, poziom podstawowy. Jedni twierdzą, że to trwoga i zgroza, a inni - że nie jest tak źle.

Oto zbiór opinii, zebranych przeze mnie od lutego.

MAIL 1

Był trudny przykład, ten poniżej. Dodatkowym utrudnieniem było to, że jedna z instrukcji wewnątrz IF-a miała wpływ na dane sprawdzane w kolejnych IF-ach.

INPUT a
INPUT b

a=b+1
IF b

  a=b+5
ENDIF

IF a<=40 THEN
  IF a<=28 THEN
    PRINT „coś tam”
  ELSE
    PRINT „coś tam”
  ENDIF
ENDIF


Trzeba było wybrać odpowiedź, która pokryje 100% instrukcji i 100% decyzji.


MAIL 2

Chciałam się podzielić wrażeniami z egzaminu, który zdałam wczoraj. Nie zgadzam się z opiniami, że pytania są długie i bardzo rozbudowane. Nie znałam sylabusa na pamięć (przeczytałam go 4 razy), a rozwiązanie testu nie sprawiło mi żadnego problemu. Zajęło mi to 30 minut. Przez kolejne 20 przerzucałam jeszcze pytania zupełnie bez sensu. Moim zdaniem test, który otrzymaliśmy od Pana podczas ostatniego dnia szkolenia, był o wiele trudniejszy. A co do samego szkolenia... Przed jego rozpoczęciem przeczytałam sylabus dwa razy. Ale dopiero po Pana wykładach zaczęłam go rozumieć. Powtórka do egzaminu była przyjemnością i wszystko wydawało się proste i zrozumiałe. Za to bardzo Panu dziękuję :)


MAIL 3

Witam, wczoraj pisaliśmy egzamin ISTQB FL. Udało mi się zdać na 80%. Egzamin całościowo nie był taki trudny. Chociaż wynik 80% świadczy o tym, że są pytania z którymi sobie nie poradziłem. Na szczęście dominowały pytania jednokrotnego wyboru, a nie te w stylu - "I i II są prawdą, a III i IV się nieprawdą". Były też ze dwa pytania w których byłem pewny odpowiedzi, a okazały się źle. (niestety nie pamiętam już szczegółów).
    

MAIL 4

Co do samych pytań, zdecydowanie wypadło na nową bazę. Z tego co przerobiłem i co było dostępne na internecie pokrywała się stosunkowo niewielka część. Było parę zadań gdzie wręcz do bólu wszystkie odpowiedzi były poprawne. W ogólnej ocenie część pytań wymagała praktyki niżeli wiedzy teoretycznej, sam sylabus przydałoby się rozbudować o zagadnienia właśnie bardziej praktyczne. Aaa i tak sylabus od dechy do dechy.


MAIL 5

Dzisiaj otrzymałam wynik egzaminu ISTQB niestety negatywny - 57,5%. [...] Niestety niektóre zadania były zbyt obszerne jak na taką ilość czasu i trzeba było test czytać "po łebkach".


MAIL 6

Z radością informuję, że udało mi się zaliczyć sobotni egzamin z wynikiem 72 %. Większość osób ze szkolenia zaliczyła (z tego co wiem dwóm osobom się nie udało). Egzamin oceniam na trudny, dodatkowo egzaminujący powiedział, że w tym roku powstały nowe zestawy pytań i nam one przypadły. Część pytań była bardzo rozbudowana, tzn. było bardzo dużo tekstu w stosunku do czasu jaki przewidziany jest na egzamin. O dziwo nie było wcale obliczeń dotyczących klas równoważności i wartości brzegowych (myślałam, że to pewniaki). Pytania teoretyczne były bardzo skrupulatne i wymagały bardzo dobrej znajomości sylabusa (dosłownie od deski do deski i łącznie z tym co w nawiasach). W głowie mogły też namieszać "odpowiedzi jednokrotnego wyboru" pisze to złośliwie , bo niemal każde pytanie zawierało wszystkie możliwe kombinacje różnych kombinacji :). Zestawy pytań próbnych [...] oceniam jako łatwe i średnio trudne. Aby lepiej przygotowywały to egzaminu należałoby je uzupełnić o "bardziej złośliwe odpowiedzi", bo o ile pytania egzaminacyjne w wersji otwartej nie byłyby takie straszne, o tyle wskazanie właściwej odpowiedzi wśród tych zawiłych kombinacji bywa dość problematyczne. Widać, że przygotowujących pytania fantazja poniosła :) Dziękuję za przekazaną wiedzę i słowa otuchy przed egzaminem.


MAIL 7

Dla potomnych pytania, które zapamiętałam:

  1. Czym się różni testowanie od debugowania?
  2. Cecha techniki biało-skrzynkowej (odp. chodziło o strukturę)
  3. Pytanie o cechy testów systemowych (czy jakoś tak)
  4. Było jakieś pytanie o proces formalny (inspekcję), kto w tym uczestniczy?
  5. Co wykryje analiza statyczna
  6. Jakie techniki oparte o strukturę określają  pokrycie (pokrycie instrukcji, decyzji)
  7. IF-y i ELSE-y czyli schemat blokowy (p. sterowania) a w odpowiedziach jakieś liczby
  8. Jakieś pytanie o incydent chyba było
  9. Jakaś tabela do interpretacji z pytaniem o liczbę przypadków testowych
  10. Jakie narzędzie do projektowania testów --> narzędzia wspierające testy (dla specyfikacji testów)
  11. Pytanie czym się różnią techniki statyczne od dynamicznych (uruchamiany / nieuruchamiany kod)
  12. Cechy testów regresywnych i retestów (potwierdzających)
  13. Co bierzemy pod uwagę przy wyborze narzędzia
  14. Jaki test najlepiej nadaje się do automatyzacji --> regresywny
  15. Coś o metrykach, ale nei pamiętam dokładnie
  16. Ryzyko projektowe i produktowe (przykłady)
  17. Testowanie pielęgnacyjne
  18. Testowanie w oparciu o doświadczenie - testowanie eksploracyjne, atak usterkowy , najlepsze przy braku dokumentacji
  19. Co zawiera raport incydentu
  20. Pytanie o narzędzia do wykonywania testow w oparciu o dane
  21. Chyba cos o projekt pilotażowy
  22. I oczywiście nasz kochany proces testowy, etapy i co wchodzi w ich zakres :) z tego to chyba były nawet 2 pytania;  jedno to: co wchodzi w zakres planowania?
  23. Chyba coś o strategie testowania czego dotyczą np. analityczne - ryzyka itp
  24. Zarządzanie konfiguracją i zarządzanie incydentami
  25. Ryzyko używani narzędzi testowych
  26. Komparator testowy co robi i do jakich narzędzi należy
  27. Cel narzędzi wspomagających proces testowy lub coś w ten deseń (budowanie powiązań między testami, wymaganiami i błędami)
  28. Które narzędzia komunikują się między sobą  --> narzędzia do zarządzania testami
  29. pytanie o testy akceptacyjne
  30. I chyba coś o testy integracyjne
 
 MAIL 8

W ostatni weekend byłem w grupie, która miała z Panem szkolenie ISQB FL. Mam pytanie odnośnie podstawowego procesu testowego. Podczas zajęć zanotowałem, że: 


1. W etapie "Analizy i projektowania" tworzone są warunki testowe, przypadki testowe oraz dokument "specyfikacja projektu testowego". Na stronie http://blogomocja.blogspot.com/2017/02/ostateczna-powtorka-przedegzaminacyjna.html "specyfikacja przypadków testowych". Chcąc to ujednolicić, ile i jakie dokumenty są tworzone w tym etapie?

Odpowiedź: Sylabus obecnej wersji 4.1 "Pojęcia" wymienia oba te dokumenty. "Specyfikacja procedur testowych" tworzona jest podczas "implementacji".

2. Z tworzonych dokumentów w etapie "Implementacji i wykonywania" oprócz tego co wymienione jest na stronie, mam zanotowane również tworzenie "raportów". Czy tworzenie raportów znajduje się w tym etapie?

Odpowiedź: Sylabus w opisie "wykonywania" radośnie pomija tworzenie jakichkolwiek raportów, wymieniając jako "raport" tylko "raport końcowy" tworzony na końcu fazy "kontroli spełnienia warunków zakończenia". Jest to na tyle ostrą bzdurą, że mimo braku mowy o "raportach podczas wykonywania", dodałem to w moim opisie.
    

W załączniku przesyłam schemat procesu, który zacząłem tworzyć w ramach nauki i porządkowania notatek.
 

Odpowiedź: Super! Proszę go wrzucić do https://www.facebook.com/groups/194288250951242/?fref=ts