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