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

poniedziałek, 20 lutego 2017

Zrozumieć IT dla nie-informatyków

Propozycja kolejnych seminariów PTIW - proszę o uwagi kontakt@requirements.org.pl

Agenda szkolenia:

  • Od Ady Lovelace przez Turinga do Gates'a, Jobsa i Zukerberga
  • Jak działa procesor?
    • Lampy elektronowe, druciki, magistrale i układy scalone
    • System dwójkowy, bity, bajty, kilo, kilo, mega, giga i tera
    • Instrukcje procesora
  • Jak działa komputer?
    • Przetwarzanie i pamięć (PROM, RAM, dyski)
    • Hardware (platforma sprzętowa) a oprogramowanie
  • Jak działa oprogramowanie?
    • Program, oprogramowanie, aplikacja
    • System operacyjny, API, sterowniki
    • Graficzny interfejs użytkownika
    • Wiele programów jednocześnie?
  • Jak tworzy się oprogramowanie?
    • Języki programowania - kod źródłowy
    • Od kodu źródłowego do instrukcji mikroprocesora
      • Kompilacja
      • Łączenie
      • Ładowanie do pamięci i uruchomienie
    • Różne tryby tworzenia i działania: na przykład HTML, Java Script, Java i C++ (tak, to są bardzo różne rzeczy)
    • Typy języków oprogramowania - i o co chodzi z tą obiektowością?
  • Jak komputer nadzoruje działanie pralki, czyli tak zwane systemy wbudowane, albo kontrolne
    • Niewidzialne systemy krytyczne dla bezpieczeństwa - sprawa życia i śmierci
  • Podstawy Internetu
    • Przeglądarka
    • HTTP
    • HTML i inne języki znaczników
    • Wyszukiwarki
    • Domeny, URL oraz IP
    • CSS, PHP, WordPress, Joomla?
    • Portale, blogi, fejsbuki i to wszystko
  • Usługi w chmurze, usługi internetowe, usługi mobilne i różna Androidy
  • Oprogramowanie a projekt informatyczny - trudna przyjaźń
  • Informatyka, elektronika, matematyka, IT, programowanie, komputery, sieci
  • Mody w świecie komputerów
  • Psychologia w IT
  • Te wszystkie straszne nazwy: Ruby, Apache, Cucumber, Joomla, Hadoop... jak się w nich nie pogubić?
  • Bugi i błędy - skąd się biorą?
  • Tak zwane testowanie, czyli łapanie bugów - jak to się odbywa?
  • Wsparcie i utrzymanie oprogramowania - z perspektywy programisty i z perspektywy klienta
  • Deweloper, architekt, inżynier, betoniarz-zbrojarz, hydraulik i murarz - kim są w IT?
  • Co będzie dalej?

niedziela, 19 lutego 2017

Discussing REQB mock exam questions



Hi All,

On 17.02.2017 07:40, […] wrote:

Hi Bogdan
I was wondering if you may help us because in one of the exams I found some different answers. You remember that I had the exam from Swedish board and also answers that I found on the Internet and in some cases the answers differ with yours, could you please double check these?

Thanks

_____________________________________________________________________
(13) Which of the following activities would primarily help to improve the quality of a Requirements Specification in an initial state?

a)  Make the specification formal as early as possible to avoid disturbances that can jeopardize the quality

b)  Executing System Test as early as possible to find discrepancies between stated requirement and actual outcome.
c)  Set clear statements of what a system should do rather than how it should do it

d)  Leave the development constraints to next phase, so they do not affect requirements quality

I have answer C here

"C" may have two meanings (and we do not know which one the question author had in mind):
  1. "what" = functional requirements, "how" = non-functional requirements;
  2. "what" = requirements, "how" = design, planned implementation details.
Whichever interpretation you choose, it cannot be "C": "1" is wrong (the syllabus rightly states that non-functional requirements are equally important as functional ones), and "2" is generally right, but not in any way specific for "an initial state" (regardless of whether "initial state" means early requirement's version, or early project stage).
Therefore, the right answer is "A", because "B" and "D" are impossible and wrong. However, some doubt may appear because in several places in the syllabus they say full formality is not always required nor preferable, but on the other hand, it states in many places that "early formal acceptance" is a good thing (please run "<Ctrl-F> formal" on the syllabus to check it).

_____________________________________________________________________

(15)   Which of the following will probably cause most problems when handling requirements?

a.    Prioritization of the requirements
b.    Too formal formulations
c.    Planned changes to requirements
d.    The fact that requirements are feasible

I have answer B here 

"B" is 100% wrong for two reasons: you seldom have problems with excessively formal description (the opposite is true - requirements specifications are commonly too vague), and even if they were too formal, the problem would be mild compared to prioritization problems. The syllabus says much on both subjects (check it, using " priori" and "> formal") but it does not say much on the relative levels of difficulty, sorry.

_____________________________________________________________________

(21)  Which one of the following is a main activity within the process Requirements Elicitation in Requirements Development

a)  Detailing known high-level requirements
b)  Defining and maintaining traceability of requirements
c)  Developing models of the business solution
d)  Elaborating business requirements into system/solution

I have answer A here (Syllabus mentions the answer A, the answer B belongs to Requirement Analysis) 

You and your answer is right! My mistake, SORRY! ("right" in the sense "according to the syllabus").


_____________________________________________________________________
 
(27) Which of the following statements about solution models is NOT correct?

a)  They serve as the basis for system design
b)  They are designed in parallel with the requirements model
c)  They describe various views of the system
d)  They serve as the basis for the estimate of work effort

I have answer D here.

Requirement models "serve as basis for the solution model" (syllabus, page 75), so they cannot be designed "in parallel" (i.e. simultaneously) - ergo, "B" is wrong (i.e. the right answer).

Both types of models [in reality, there is seldom any practical difference, but yes, you should forget about the reality as I told you] are basis for work effort estimation - first, requirements models, and solution models later on.

However - sorry for this! - in the next section on the same page the syllabus says that the "[business] solution model serves as a basis for the solution design". This is correct of course: solution model serves both as a basis for the solution design and for the work effort estimate.

So - yes - from these two sections the question author may have come to the (very wrong) conclusion that solution models are not used for work effort estimate. Hence their answer "D" here . Linguistics and psychology!


_____________________________________________________________________
 
(35)      Which of the following statements about requirements traceability is MOST correct [important]?

a)  It is extremely important to label requirements precisely in order to ensure good traceability

b)  Traceability provides a check on whether all requirements have been labelled precisely.

c)  The aim of traceability is to label interrelationships within a project precisely enough in order to comply with the requirements

d) Traceability is important to keep requirements stable and to ensure that they cannot evolve


I have the answer A here 

Concerning "A": the syllabus says "in order to ensure good traceability, it is important to label the requirements uniquely"; on one hand, the word "extremely" is excessive (both in reality and according to the syllabus") and the crucial word "unique" is omitted. So "A" is not fully correct nor the MOST important aspect of traceability.

The MOST important aspect (and, hopefully, the "MOST correct" answer according to the unusual figurative stylistics of this question) is its GOAL - to identify (and label) the interrelationships (between requirements and other artefacts) - therefore, the answer should be "C".

"B" and "D" are incorrect ("D" is simply WRONG, and "B" is very week).

_____________________________________________________________________
 
(36)      Which of the following statements about metrics is MOST correct [important]?

a.    Metrics must always be set in relation to reference data
b.    It is important to ensure that all metrics are selected

c.    Metrics in Requirements Engineering allow a qualified statement about the quality status of the system

d.    The lower the requirement rating, the greater the risk for the project

I have answer A here ( Syllabus also mentions here a similar answer) 

"A" is very true but very trivial, in the same sense as, for example, a sentence "Metrics is defined by the measurement scale it uses" is. True, but so what? "C" is the main GOAL of using metrics - to be able to "make quantifiable statement about project status and quality" (the preceding statement in the syllabus). And of course "quantifiable" metrics (the syllabus" makes the statement more "qualified" (the question). Quod erat demonstrandum.

_____________________________________________________________________
 
(40)  How exactly do process maturity models prescribe Requirements Engineering?

a)    CMMI and SPICE prescribe Requirements Engineering procedures
b)    CMMI and SPICE contain Requirements Engineering techniques

c)    CMMI and SPICE prescribe what Requirements Engineering must deliver, but not in detail how it is done

I have answer C here 

"B" is wrong (these maturity standards do not specify specific techniques), and "A" and "C" are both right: these standards tell us what [results] RE must deliver and how RE comes into development processes [RE procedures]. The choice is arbitrary. My choice of "A" rather than "C" is based on the assumption that "A" is more general and "C" is too detailed.

Summary: so what now? The problem is, you can almost never be 100% sure what the right answer is, because it depends on what a question author has in mind, and the questions are (like bad requirements) not sufficiently detailed to decide this! So guesswork and learning the way authors may think is the key to success here. Of course, you need to learn to guess what exam questions' authors think, and not Bogdan Bereza thinks . In this case (the SEQB questions) their authors must be Beata Karpinski and Ingvar Nordström. How probable is it that they are as well the authors of (some) real exam questions? I do not know.

Of course, there is as well some probability that certain answers in the "official" answer sheet are simply typing mistakes - this happens as well.


Please let me present you the uncensored version of the slide how these questions are created:
  • The question author takes a random piece / section of the syllabus and finds in it some complex / dubious / hard to remember statement.
  • The author rips this statement out of its context and changes a word or two in it.
  • This doctored statement becomes the "correct" answer, and three more statements are added to it (often sensible, but not from the syllabus)
  • To defeat such questions, the counter-measure it to read the syllabus slowly a few times (it is painful, but not deadly)
Cheers, Bogdan