czwartek, 9 lutego 2017

OSTATECZNA POWTÓRKA przedegzaminacyjna ISTQB


Aby zwiększyć szanse na 100% zdawalności, załączam poniżej wskazówki do OSTATECZNEJ POWTÓRKI przedegzaminacyjnej.

Odnośniki:


   

Dla wszystkich rozdziałów

Dla każdego rozdziału sylabusa – proszę uważnie i powoli przeczytać „Cele nauczania dla […]”.

Dzień przed egzaminem, wieczorem przed snem powolutku jeszcze raz przeczytać cały sylabus. Nie próbować niczego już rozumieć (to niedobre na sen), tylko powoli czytać, jak poezję. To nie jest żart, obraz tekstu utrwala się przez noc w głowie.
   

1. Podstawy testowania

Przećwiczyć pytania z zakresu rozróżniania pomyłki (błędu), usterki (defektu) i awarii.

Pamiętać, że testowanie jest jednym ze sposobów zapewnienia jakości, jakość jest ważna, aby unikać awarii i ich skutków… i to, że a Słowacki wielkim poetą był :)

Nie zapomnieć, że jednym z celów testowania jest „budowanie zaufania” – ten temat chętnie na egzaminie wyskakuje.

Jak wiele testować? – na dowolne warianty tego pytania, właściwa odpowiedź ma w sobie coś w stylu „to zależy od ryzyka”.

Nie załamać się, że jednym z celów testowania jest też „zapobieganie usterkom” – to brzmi absurdalnie, ale jest prawdą w tym sensie, że:

  •  Projektowanie testów może wykryć defekty w „podstawach testowych”, co zapobiega potem tworzeniu błędnego kodu na podstawie błędnej dokumentacji;
  • Testy statyczne dokumentacji – tak samo.

Pamiętać, że debugowanie, czyli szukanie i naprawianie defektów (usterek, bugów), to zadanie nie dla testera, lecz dla programisty / dewelopera.
 
Tajemnicze „7 zasad” – proszę pamiętać, że ich nazwy są anty-intuicyjne:
  1. Ujawnia usterki = wykonane pozytywnie testy nie są gwarancją braku bugów
  2. Niewykonalne jest „gruntowne” = nie da się przetestować wszystkiego
  3. Wczesne = (to pierwsze z 10 miejsc, gdzie sylabus to wyjaśnia) lepiej jest testować wcześniej, niż później
  4. Kumulowanie się błędów (tak, powinno być oczywiście „defektów”, lub „usterek”, a nie „błędów”! W oryginale jest „defect”, to już autorzy tłumaczenia pojechali) = występują stadami
  5. Obłąkana nazwa „paradoks pestycydów” znaczy, że stare testy trzeba odnawiać – nawet jeśli kiedyś były dobre
  6. Zależy od kontekstu = jak większy strach, to trzeba lepiej sprawdzać
  7. Mylne przekonanie, że OK (tutaj już i polski, i angielski sylabus zupełnie błędnie piszą „błędów”, zamiast „defektów”) – to ISTQB-owska wersja powiedzenia „nie to dobre, co dobre, tylko to, co się komu podoba”.
Podstawowy proces: NA PAMIĘĆ! Nie tylko fazy procesu, ale wszystkie jego artefakty (w tym – te okropne nazwy dokumentów). Kto nie sfotografował jeszcze nigdy mojego obrazka, proszę raz jeszcze:


Psychologia – tylko sobie raz jeszcze przeczytać, ale nie szukać w tym zbyt wiele logiki.
 

Etyka – pytań nie będzie.
      

2. W cyklu życia

Przejrzeć raz jeszcze slajdy wykładu, o co chodzi z tymi „modelami”. Może się pojawić pytanie nie na temat testowania, który model jest lepszy w jakiej sytuacji (iteracyjno-przyrostowe są lepsze, gdy wymagania są słabo znane lub zmienne).

2.1.3 Testowanie w cyklu życia oprogramowania - W każdym modelu rozwoju oprogramowania dobre testowanie posiada kilka niezmiennych cech:” – NA PAMIĘĆ!

Poziomy testów: bardzo powoli przeczytać to w sylabusie i na slajdach. Uwaga: slajdy są trochę nadmiarowe w stosunku do sylabusa. Zwrócić proszę uwagę na to, co wzrok człowieka omija z lekkim obrzydzeniem, czyli dla każdego poziomu „typowe obiekty testów” oraz jaka jest dla każdego poziomu właściwa dla niego „podstawa testów”.

Raczej nie przejmować się wątpliwymi rewelacjami sylabusa o tym, czy na danym poziomie robi się „raczej” testy funkcjonalne, czy niefunkcjonalne.

Typy testów:

2.3.1 testy funkcjonalne – czytamy i rozumiemy;

2.3.2 testy niefunkcjonalne – czytamy i rozumiemy;

2.3.3 NIE PRZEJMUJEMY SIĘ. Te tajemnicze „testy struktury/architektury”, to tylko wprowadzające w błąd opisanie tego, co dokładniej omawiane jest na początku rozdziału 4-ego, czyli testów „białej skrzynki” / strukturalnych (czyli, mówiąc po ludzku, TECHNICZNYCH).

2.3.4 regresja lub testy potwierdzające/retesty. Nic tam nie ma groźnego, ale uwaga: regresję robi się po każdej zmianie, nie tylko po naprawieniu defektów).

Pielęgnacyjne – ZZZ (zakuć, zdać, zapomnieć) J
    

3. Statyczne

Przeczytać, mimo powalającego uczucia nudy :(. Zapamiętać, czemu testowanie statyczne jest dobre (bo 1. można wcześniej niż dynamiczne i 2. bo znajduje czasem bugi, które może być trudno znaleźć dynamicznymi testami).

Proces przeglądu – NA PAMIĘĆ (i nie przejmować się logiką). Kto bierze udział, kroki procesu formalnego itp.

Rodzaje przeglądów – NA PAMIĘĆ i nie przejmować się logiką.

Czynniki powodzenia przeglądów – ZZZ (w tym - lektura przed snem w piątek wieczorem).

Analiza statyczna – przeczytać. Nie załamać się zdaniem „miejscem, w którym kod jest wykonywany, są testy dynamiczne” – oznacza ono to, co już wiemy, czyli że kod URUCHAMIAMY przy testach dynamicznych, a przy statycznych – NIE URUCHAMIAMY (nie „wykonujemy”) kodu testowanego programu.

„Analiza statyczna zwykle wykrywa następujące typy usterek:” – kto nie do końca ma podstawy, aby ten akapit zrozumieć (bo nie jest doświadczonym programistą), czyta przed snem, żeby te określenia potem rozpoznać pamięciowo.
    

4. Techniki projektowania

4.1 Proces rozwoju – powtórka pojęć z „podstawowego procesu testowego” z rozdziału 1. Nowe zdanie to: „Przypadek testowy składa się ze zbioru
1.       warunków wstępnych,
2.       wartości wejściowych,
3.       oczekiwanych wyników oraz
4.       warunków zakończenia”.

UWAGA: Te cztery elementy przypadku testowego, zawiera także procedura testowa / skrypt testowy.

Uwaga – tutaj nagle autorom sylabusa przypomniało się, że to, co (z korzyścią dla świata) pominęli w opisie podstawowego procesu testowego, czyli dwie nazwy z prastarego IEEE 829 (https://en.wikipedia.org/wiki/Software_test_documentation): specyfikacja przypadków testowych (nazwa logiczna) i specyfikacja projektu testów (nazwa obłąkana, logiczna byłaby „specyfikacja warunków testowych”).

4.2 – kategorie technik projektowania testów

Żeby to zrozumieć, trzeba najpierw zrozumieć, jak jest naprawdę, a potem zrozumieć, jak tę prawdę przekręcił szacowny sylabus.


__________________________________________________________________________
__________________________________________________________________________
 __________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
 __________________________________________________________________________

4.2 – kategorie technik projektowania testów – ŻEBY ZDAĆ EGZAMIN:

Uczymy się – ćwicząc na przykładach – zadań z podziału na klasy równoważności i analizy wartości brzegowych. Bardzo ważne – odróżniać poprawne i niepoprawne klasy równoważności raz poprawne i niepoprawne wartości graniczne.

Tablice decyzyjne i diagramy przejść stanów – rozwiązywanie pytań wymaga tylko skupienia i zdrowego rozsądku.

Miary pokrycia kodu – ćwiczymy, ćwiczmy. Wciąż niejasne? Proszę o pytania!\
   

5. Zarządzanie testowaniem

5.1 Organizacja testów – częściowo powtórka z „psychologii testowania”, reszta to klasyczne ZZZ. Przeczytać, rozwiązać dużo pytań, lektura przez snem. Nie ma czego rozumieć, to tylko takie hasła.

5.2 Planowanie i szacowanie – przeczytać, także jutro przed snem, żeby się uleżało. Okropna pamięciówa. Częściowo pokrywa się z tematem „planowanie” z podstawowego procesu testowego, rozdział 1.

Czynności (5.2.2), kryteria wejścia (5.2.3), kryteria zakończenia (5.2.4) i szacowanie testów (5.2.5) – czytać, aż się utrwalą:(. Uwaga – kryteria zakończenia, zapisane w planie testów, to te same, które wykorzystuje się w fazie „ocena spełnienia kryteriów zakończenia” podstawowego procesu testowego (rozdział 1).

5.2.6 Podejścia (strategie) – absolutnie nie podejmować prób rozumienia (to w całości taka kasza słowna i górnolotne nazwy). 

Typowe podejścia do testów to:” – przeczytać 3 razy, nie próbować zrozumieć, przeczytać przed snem, albo… zlekceważyć (ale 1 pytanie z tego może się trafić).

5.3 Monitorowanie i nadzór – w miarę logiczne, warto zapamiętać „Często wykorzystywanymi metrykami są:”. 

UWAGA: w tytule rozdziału jest „nadzór”, a w tekście (5.3.3) jest „Kierowanie” (w angielskim sylabusie, w obu miejscach „control”) L. Błąd tłumaczenia - nie przejmujemy się – w obu wypadkach autorzy sylabusa mają na myśli podejmowanie decyzji lub działań, kiedy monitorowanie wskazuje, że coś źle się dzieje!

5.4 Zarządzanie konfiguracją. Dwukrotna lektura i kilka pytań próbnych wystarczą na 100%

5.5 Ryzyko a testowanie. Dwukrotne przeczytanie plus parę pytań próbnych powinno starczyć na sukces. Uwaga na pułapkę w pytaniach! „Zła jakość dokumentacji”, to może być:
  • ryzyko produktowe, jeśli autor pytania ma na myśli dokumentację, którą projekt wytwarza dla klienta (która jest więc częścią produktu)
  • ryzyko projektowe, jeśli autor pytania ma na myśli dokumentację, na podstawie której projekt będzie realizowany, na przykład specyfikację wymagań.
5.6 Zarządzanie incydentami – wolniutko, uważnie przeczytać + kilka pytań próbnych = wiktoria.
     

6. Narzędzia

Nie zemdleć przy słowie „reużywalne” :(

Struktura testowa (albo: test framework) = cokolwiek L czyli albo środowisko i narzędzia do testowania, albo… stosowany proces testowy.

Jeśli struktura = środowisko + narzędzia, to trzeba ją odróżnić od „jarzma testowego” (test harness), czyli narzędzia, kierującego automatycznymi testami. Jarzmo testowe jest więc częścią struktury testowej.

6.1 Typy narzędzi testowych – czytamy powolutku, zwracając też uwagę na to, dla kogo dane narzędzie ma być wg sylabusa. 1-2 pytania będą na egzaminie.

6.2 Użycie, korzyści i ryzyko oraz 6.3 Wdrażanie w organizacji – czytamy przed snem i będzie dobrze!

Powodzenia. Mail do mnie: bogdan.bereza@victo.eu

Brak komentarzy:

Prześlij komentarz