Please enable JavaScript.

Coggle requires JavaScript to display documents.

TEST MIENAGIER (2. ZARZĄDZANIE TESTAMI (2.4 Dokumentacja testowa i inne…

- - - - Programiści, liderzy i kierownicy zespołów tworzących oprogramowanie
      - Architekci baz danych, architekci systemowi i projektanci
      - Analitycy marketingowi i biznesowi
      - Kierownictwo wyższego szczebla, kierownicy produktu i sponsorzy projektu
      - Kierownicy projektów
      - Wsparcie techniczne, wsparcie klienta i pracownicy wsparcia technicznego
      - Użytkownicy bezpośredni i pośredni
  - - - 2.3.1.1 Identyfikacja ryzyka
      - 2.3.1.2 Ocena ryzyka
      - 2.3.1.3 Łagodzenie ryzyka
      - 2.3.1.4 Zarządzanie ryzykiem w cyklu życia
- - - - cykl doskonalenia Deminga (PDCA) - ciągle aktualny, gdy tester potrzebuje udoskonalić proces, który jest aktualnie stosowany
    - - Modele doskonalące procesy - dwie kategorie:
        
        1) model referencyjny procesu: pomiar dojrzałości,ocena organizacji w ramach struktury, dostarcza mapę drogową dla doskonalenia procesu
        
        2) model referencyjny zawartości (CTP, STEP): ocena, z perspektywy biznesowej, okazji organizacji do doskonalenia, w niektórych przypadkach pozwala na porównanie ze średnimi branżowymi; ocena może być wykorzystania do zbudowania harmonogramu udoskonalania procesu
      - Doskonalenie procesu testowego może być również zrealizowane bez wykorzystania modelu (np. użycie podejścia analitycznego i spotkań retrospektywnych)
  - - - 1) modele wielostopniowe (TMMi i CMMI) - zapewniają normy pozwalające na porównanie pomiędzy różnymi firmami i organizacjami
      - 2) modele ciągłe (CTP, STEP, TPI Next) - umożliwają organizacji zwrócenie uwagi na zagadnienia o najwyższym priorytecie z większą dowolnością w definiowaniu kolejności wdrożenia
    - - 1. Rozpoczęcie procesu doskonalenia (Initiating)
        
        a) interesariusze ustalają cele, zakres i pokrycie usprawnianych
        procesów
        b) wybór modelu doskonalenia procesu (z publicznie dostępnych lub wytworzony wewnętrzne)
        c) zdefiniowanie kryteriów powodzenia oraz metod pomiaru
      - 2. Diagnozowanie obecnej sytuacji (Diagnosing)
        
        a) dokonanie oceny
        b) stworzenie raportu oceny (zawartość raportu: ocena aktualnych praktyk testowania i lista potrzebnych udoskonaleń procesu)
      - 3. Przyjęcie planu doskonalenia procesu testowego (Establishing)
        
        a) przypisanie priorytetów dla elementów listy potrzebnych usprawień (które usprawienia są najważniejsze itp.) - na podstawie np. zwrotu z inwestycji, zgodności ze strategią organizacji lub innych korzyści
        b) opracowanie planu dostarczania usprawień (np. treningi, mentoringi itp.)
      - 4. Działanie w celu wdrożenia udoskonaleń (Acting)
        
        a) wdrożenie planu doskonalenia procesu (pilotażowe i ostateczne)
      - 5. Uczenie się (Learning) (po pełnym wdrożeniu usprawienia)
        
        a) zweryfikowanie, które korzyści zostały osiągnięte
        b) sprawdzenie, które z kryteriów powodzenia zostały osiągnięte
      - gdy jest po wszystkim: rozpoczynamy monitorowanie następnego poziomu dojrzałości oraz podejmujemy decyzję o rozpoczęciu procesu kolejny raz lub decyzję o przerwaniu czynności na tym etapie
  - - - :one: POZIOM 1. Początkowy (Initial)
        
        nie ma formalnie udokumentowanego (zdefiniowanego) procesu testowania
        
        testy tworzone ad hoc po kodowaniu
        
        testowanie postrzegane jako równoważne z debagowaniem
        
        cel testów jest rozumiany jako udowodnienie, że oprogramowanie działa
      - :two: POZIOM 2. Zarządzany (Managed)
        
        procesy testowania są jasno oddzielone od debagowania
        
        ustanowienie polityki oraz celów testowania, wprowadzenie kroków z podstawowego procesu testowego (np. planowanie testów)
        
        implementacja podstawowych technik i metod testowania
      - :three: POZIOM 3. Zdefiniowany (Defined)
        
        proces testowania zintegrowany z cyklem życia rozwoju oprogramowania
        
        proces testowania udokumentowany w postaci formalnych standardów, procedur i metodyk
        
        odbywają się przeglądy
        
        wydzielona rola testowania oprogramowania, która może być kontrolowana i monitorowana
      - :four: POZIOM 4. Mierzony (Measured)
        
        testowanie może zostać skutecznie zmierzone i zarządzane na poziomie organizacji
      - :five: POZIOM 5. Zoptymalizowany (Optimized)
        
        dane z testowania mogą być użyte, aby zapobiegać defektom
        
        organizacja skupia się na optymalizacji wdrożonego procesu
  - - - Początkowy
      - Kontrolowany
      - Efektywny
      - Optymalizowany
  - - - a) strategia testowania oparta na wymaganiach
      - b) testowanie rozpoczyna się już na początku cyklu życia oprogramowania
      - c) testy wykorzystuje się jako modele wymagań i użycia
      - d) projektowanie testaliów wyprzedza projektowanie oprogramowania
      - e) defekty są wykrywane wcześnie lub udaje się im całkowicie zapobiec
      - f) defekty są systematycznie analizowane
      - g) testerzy i programiści pracują wspólnie
- - - - używanie oprogramowania
      - wiedza dziedzinowa lub biznesowa (np. co jest najważniejsze dla biznesu, jak spełnić wymagania biznesu itp.)
      - wykonywanie czynności w różnych fazach rozwoju oprogramowania np. analizie wymagań, kodowaniu, wsparciu technicznym (przydaje się np. w analizie statycznej kodu, testach jednostkowych)
      - wykonywanie czynności związanych z testowaniem oprogramowania
- - - - Przeglądy wymagań, rozpoczęte w momencie, gdy wymagania są dostępne do przeglądu, który idealnie sprawdza zarówno wymagania funkcjonalne, jak i niefunkcjonalne.
      - Przeglądy projektu na wysokim poziomie, rozpoczęte, gdy całościowy projekt architektoniczny jest dostępny do przeglądu.
      - Szczegółowe przeglądy projektu, rozpoczęte, gdy szczegółowy projekt jest dostępny do przeglądu.
      - Przeglądy kodu, przeprowadzane dla poszczególnych modułów tworzonego oprogramowania, które mogą obejmować testy jednostkowe i ich wyniki, a także przeglądy samego kodu.
      - Przeglądy produktów prac testowych, które mogą obejmować plan testu, warunki testowe, wynik analizy jakości na podstawie ryzyka, testy, dane testowe, środowiska testowe i wyniki testów
      - Przegląd kryteriów wejściowych testów (gotowość testów) oraz kryteria wyjściowych z testów dla każdego poziomu testów, który odpowiednio sprawdza kryteria wejścia przed rozpoczęciem wykonywania testów i kryteria wyjścia przed zakończeniem testów.
      - Przeglądy akceptacyjne, wykorzystywane w celu akceptacji systemu przez klienta lub interesariuszy.
    - - przegląd może wyeliminować problem na poziomie wymagań, zanim problem ten zostanie wprowadzony do kodu
      - analiza statyczna może pomóc w egzekwowaniu standardów kodowania i "sprawdzić czy problemy, które mogą być zbyt pracochłonne dla zespołu, zostały znalezione poprzez rewizję produktów pracy"
      - inspekcje mogą prowadzić do do wykrycia i usunięcia defektów, ale także mogą uczyć autorów, w jaki sposób uniknąć tworzenia defektów
    - - Przegląd nieformalny
      - Przejrzenie
      - Przegląd techniczny
      - Inspekcja
      - :star: Przegląd kierowniczy
      - :star: Audyt
  - - - wykorzystywane do monitorowania postępu, oceny statusu i podejmowania decyzji dotyczących przyszłych działań (np. jakie zasoby przydzielić, jakie wdrożyć działania naprawcze lub zmiany)
        
        przeglądy kierownicze procesów (np. retrospektywy projektu, tj. wyciągnięcie wniosków) są integralną częścią czynności doskonalenia procesów
        
        KT powinni uczestniczyć w przeglądach procesu testowego i mogą je inicjować. :reminder_ribbon:
      - :star: Kluczowe cechy przeglądów kierowniczych:
        
        prowadzony przez lub dla **menedżerów mających bezpośrednią odpowiedzialność za projekt lub system, ew. interesariuszy lub osób podejmujących decyzję** np. kierownik wyższego szczebla lub dyrektor
        
        sprawdzenie zgodności lub odchyleń od planów
        
        sprawdzenie adekwatności procedur zarządzania
        
        ocena ryzyka projektu
        
        ocena wpływu działań i sposobu pomiaru skutków tych działań
        
        sporządzenie listy działań, problemów, które należy rozwiązać i decyzji, które należy podjąć
    - - wykonywane zwykle w celu wykazania zgodności z określonym zestawem kryteriów (standardami, przepisami prawa, umowami)
        
        mają dostarczyć niezależną ocenę zgodności z procesami, normami itp.
      - :star: Kluczowe cechy audytów:
        
        prowadzone i moderowane przez audytora wiodącego
        
        dowody zgodności zebrane poprzez wywiady, świadectwa i sprawdzone dokumenty
        
        udokumentowane wyniki zawierające uwagi, rekomendacje, działania korygujące i oceny zaliczenia / niezaliczenia
  - - - na początku fazy planowania projektu, Lider Przeglądu powinien określić elementy, które powinny być poddane analizie i wybrać rodzaj przeglądu oraz poziom formalności
      - może być zalecane dodatkowe szkolenie z procesu przeglądu
      - ustalenie budżetu (czas i zasoby) dla procesu przeglądu, w tym ocena ryzyka i zwrotu z inwestycji
        
        :warning: zwrot z inwestycji dla przeglądów: różnica między kosztem przeprowadzenia przeglądu a kosztem naprawy defektów na późniejszym etapie (lub braku naprawy), jeśli przegląd nie był zrealizowany
        
        określenie optymalnego czasu przeprowadzenia przeglądów - co wziąć pod uwagę:
        
        dostępność elementów będących przedmiotem przeglądu w formacie ostatecznym
        
        dostępność odpowiednich pracowników
        
        termin, w którym powinna być dostępna ostateczna wersja produktu
        
        czas potrzebny na realizację procesu przeglądu dla tego konkretnego elementu
      - trzeba określić miary do oceny przeglądu. "Jeżeli stosowane są inspekcje, to na wniosek autora, po ukończeniu fragmentu dokumentu (np. indywidualnych wymagań lub ich części), powinny być przeprowadzone krótkie inspekcje."
      - należy określić cele procesu przeglądu (skuteczne i efektywne przeglądów i podejmowanie decyzji zgodnie z informacją zwrotną z przeglądu)
      - aby przeglądy były skuteczne, uczestnicy przeglądów muszą posiadać odpowiedni poziom wiedzy, zarówno technicznej, jak i proceduralnej (a więc mogą być potrzebne szkolenia z zakresu wiedzy proceduralnej, aby upewnić się, że recenzenci rozumieją swoje role i odpowiedzialności w procesie przeglądu a także szkolenia techniczne)
      - planowanie przeglądu powinno uwzględniać ryzyko związane z czynnikami technicznymi, czynnikami organizacyjnymi i zagadnieniami ludzkimi przy wykonywaniu przeglądu
      - w planowanie przeglądów powinny być zaangażowane wszystkie zespoły w ramach projektu
      - należy wskazać recenzentów zapasowych (w razie gdyby ci pierwotni byli niedostępni)
    - - zebrać metryki z przeglądu i zapewnić, że zidentyfikowane kwestie są odpowiednio wyjaśnione w kontekście specyficznych celów testowych
      - użyć metryk przeglądu w celu określenia zwrotu z inwestycji (ROI)
      - zapewnić informację zwrotną dla właściwych interesariuszy
      - zapewnić informację zwrotną dla uczestników przeglądu
    - - porównanie wyników testów (tj. po przeglądzie) z wynikami raportów z przeglądu - jeśli produkt został zatwierdzony podczas przeglądu, a później okazał się wadliwy, należy rozważyć, dlaczego proces przeglądu pozwolił na ominięcie defektów
      - możliwe przyczyny ominięcia defektów: problemy z procesem przeglądu (np. słabe kryteria wejściowe / wyjściowe), niewłaściwy skład zespołu recenzującego, nieodpowiednie narzędzia weryfikacji (listy kontrolne itp.), niewystarczające przeszkolenie recenzentów, za mało czasu na przygotowanie oraz realizację przeglądu
      - "standardowe wycieki defektów (zwłaszcza głównych defektów), powtarzane w kilku projektach, wskazują, że istnieją znaczne problemy z przeprowadzanymi przeglądami." - trzeba wówczas zweryfikować proces przeglądu i podjąć odpowiednie działania
      - możliwe również, że z różnych powodów przeglądy mogły stracić swoją skuteczność w czasie - zmniejszenie skuteczności wykrywania defektów z przeglądów może zostać ujawnione podczas retrospektyw projektu
      - metryki z przeglądu nie powinny być wykorzystywane do karania lub nagradzania poszczególnych recenzentów i autorów, ale powinny koncentrować się na samym procesie przeglądu :warning:
  - - - Rozmiar produktu (strony, linie kodu, itp.)
      - Czas przygotowania (przed przeglądem)
      - Czas do przeprowadzenia przeglądu
      - Czas naprawy defektów
      - Czas trwania procesu przeglądu
      - Ilość znalezionych defektów i ich ważność
      - Identyfikacja obszarów defektów w produkcie (tj. obszary, które mają wyższą gęstość defektów)
      - Rodzaj przeglądu (przegląd nieformalny, przejrzenie, przegląd techniczny lub inspekcja)
      - Średnia gęstość defektów (np. ilość defektów na stronę lub na tysiąc linii kodu)
      - Szacowane pozostałych defektów (lub śladowej gęstości defektów)
    - - Skuteczność wykrywania defektów (biorąc pod uwagę defekty znalezione później w cyklu życia)
      - Udoskonalenie procesu przeglądu pod względem czaso- i pracochłonności
      - Procent pokrycia planowanych produktów pracy
      - Rodzaje wykrytych defektów i ich ważność
      - Ankiety uczestnika o skuteczności i efektywności procesu przeglądu
      - Koszt metryk defektów z przeglądu w porównaniu do defektów z testów dynamicznych i defektów na produkcji
      - Korelacja skuteczności przeglądu (typ przeglądu a skuteczność wykrywania defektów)
      - Liczba przeglądających
      - Defekty znalezione na godzinę pracy
      - Szacowany zaoszczędzony czas trwania projektu
      - Średni czas naprawy defektu (np., całkowity czas wykrycia i czas naprawy podzielony przez ilość defektów)
  - - - Zdefiniowane kryteria wejścia i wyjścia
      - Listy kontrolne do wykorzystania przez przeglądających
      - Są dostarczone produkty pracy (deliverables), takie jak raporty, arkusze ocen lub innych arkusze podsumowujące przegląd
      - Metryki w celu raportowania skuteczności, wydajności i rozwoju procesu przeglądu
- - - - W przypadku większości stanów raportu defektu, raport przypisany jest zwykle do jednej odpowiedzialnej osoby (uczestnika procesu) - po zmianie stanu następuje przypisanie do kolejnej osoby (czyli zmienia się właściciel defektu)
      - 2) stany, które wymagają działania zespołu testowego
        
        początkowy (otwarty, nowy): jeden lub więcej testerów zbiera informacje niezbędne dla osoby
        odpowiedzialnej za rozwiązywanie defektu, by odtworzyć anomalię
        
        zwrócony (odrzucony, do wyjaśnienia): odbiorca raportu odrzucił raport lub prosi testera o dostarczenie dodatkowych informacji (tester powinien dostarczyć te informacje lub potwierdzić, że raport faktycznie należy odrzucić); kierownicy testów powinni monitorować nadmierne wskaźniki zwrotu
        
        stan testu potwierdzającego (rozwiązany, weryfikacja): tester będzie uruchamiać testy potwierdzające, aby stwierdzić, czy aby stwierdzić, czy poprawka rzeczywiście rozwiązała problem; jeśli defekt naprawiony - tester powinien zamknąć raport, a jeśli defekt nienaprawiony - tester powinien ponownie otworzyć raport powodując przypisanie go do poprzedniego właściciela, który następnie może ukończyć prace niezbędne do naprawy defektu
      - 1) stany, w których raport nie ma właściciela, ponieważ nie są konieczne żadne dalsze działania (stany końcowe)
        
        zamykany: defekt został naprawiony i zweryfikowany przez testy potwierdzające
        
        anulowany: raport defektu jest nieprawidłowy
        
        nieodtwarzalny: anomalii nie da się już zaobserwować
        
        odroczony: anomalia dotyczy prawdziwego defektu, ale defekt ten nie będzie naprawiony w trakcie realizacji projektu
    - - rezultat fałszywie niezaliczony: gdy raport defektu nie jest związany z defektem w produkcie, ale wynika np. z problemów ze środowiskiem testowym czy danymi testowymi lub z błędnego rozumowania testera; takie raporty są zazwyczaj anulowane lub zamykane jako nieprawidłowe rpaorty defektów
      - defekt może przejawiać się poprzez różne symptomy, które mogą wydawać się testerowi niepowiązane ze sobą; jeśli stworzono dwa lub więcej raportów defektów, które następnie okazują się być związane z tą samą przyczyną podstawową, jeden z tych raportów jest zwykle zachowywany, a pozostałe są zamykane jako raporty zduplikowane
      - :warning: nieprawidłowe lub zduplikowane raporty defektów odzwierciedlają pewien poziom nieefektywności, ale pewna ilość takich raportów jest nieunikniona - kierownik testów nie powinien tego za bardzo krytykować i piętnować (próbować wyeliminować wszystkie nieprawidłowe i zduplikowane raporty), ponieważ to mogłoby zniechęcić testerów do zgłaszania raportów defektów i w efekcie powodując:
        
        wzrost liczby fałszywie zaliczonych rezultatów
        
        zmniejszenie skuteczności wykrywania defektów
    - - Komitet zarządzania usterkami (konsylium nad defektami)
        
        Uczestnicy (członkowie):
        
        kierownik testów
        
        przedstawiciele zespołu wytwarzającego oprogramowanie,
        
        przedstawiciele zespołu zarządzania projektem i zarządzania
        produktem
        
        inni interesariusze zainteresowani rozwijanym oprogramowaniem
        
        Zadania (kompetencje):
        
        odbywanie spotkań w celu określenia, czy każdy raport defektu
        reprezentuje poprawny defekt, i czy powinien być naprawiony, czy odroczony
        
        analiza korzyści, ryzyka i kosztów związanych z naprawą lub brakiem naprawy danego defektu
        
        w przypadku decyzji o naprawie defektu - ustalenie priorytetu naprawy defektu względem innych prac projektowych (kierownik testów i zespół testerski mogą być proszeni o konsultacje dotyczące ważności defektu i należy wówczas dostarczyć dostępne i obiektywne informacje)
      - "Chociaż właścicielami całego procesu zarządzania defektami oraz narzędzia do zarządzania defektami jest zwykle organizacja testerska oraz Kierownik Testów, to za zarządzanie defektami zgłoszonymi w danym projekcie ogólnie odpowiada międzyfunkcjonalny zespół."
      - "Elementy konieczne do efektywnego i skutecznego zarządzania defektami": komunikacja, odpowiednie wsparcie narzędziowe, dobrze zdefiniowany cykl życia defektu oraz zaangażowany komitet zarządzający defektami.
        Narzędzie do śledzenia defektów nie powinno być używane jako substytut dobrej komunikacji, podobnie jak spotkania komitetu zarządzania usterkami nie powinny być substytutem efektywnego wykorzystania dobrego narzędzia do śledzenia defektów.
    - - defekty mogą być wprowadzane w dowolnym punkcie cyklu rozwoju oprogramowania i w każdym produkcie powstałym w procesie wytwórczym
      - :bug: defekt: gdy osoba popełni błąd podczas tworzenia jakiegoś produktu pracy (np. wymagań, kodu, przypadku testowego itp.)
      - każda faza cyklu rozwoju oprogramowania powinna obejmować działania mające na celu wykrycie i usunięcie ew. defektów
      - a) statyczne techniki testowania (przeglądy, analiza statyczna) - weryfikacja specyfikacji projektu, wymagań i kodu; testy statyczne znajdują raczej defekty niż awarie, zatem koszt usuwania usterki jest niższy, bo nie trzeba wykonywanać debagowania w celu odizolowania defektu
      - :explode: im wcześniej defekt jest wykryty i usunięty, tym niższy koszt jakości dla systemu
      - :explode: koszt jakości dla danego poziomu defektów jest minimalizowany wtedy, gdy defekt jest usuwany podczas tej samej fazy, w której został on wykryty ((tj., gdy proces wytwarzania oprogramowania osiąga doskonałe powstrzymanie fazowe)
      - b) testy dynamiczne - defekt widać, gdy powoduje on awarię (gdy wynik rzeczywisty inny niż oczekiwany - tj. anomalia); gdy tester widzi anomalię, wymaga to dalszego zbadania - badanie rozpoczyna się od wypełnienia raportu defektu
      - Cytat z sylabusa: "W niektórych przypadkach pojawia się rezultat fałszywie niezaliczony, gdy tester nie dostrzega anomali" - ale czy tu nie powinno być raczej "fałszywie zaliczony", a nie "niezaliczony"?
      - Test Driven Development (TDD) - wytwarzany kod jest natychmiast badany za pomocą zautomatyzowanych testów modułowych; niezaliczenie takiego testu nie stanowi defektu i zwykle nie jest śledzone (bo wytwarzanie modułu dalej trwa)
  - - - imię i nazwisko osoby, która odkryła defekt
      - rola osoby (np. użytkownik, analityk biznesowy, programista, osoba wsparcia technicznego)
      - typ wykonywanych testów (np. testowanie użyteczności, testowanie wydajności, testowanie regresyjne)
      - podsumowanie problemu
      - szczegółowy opis problemu
      - kroki do odtworzenia awarii (dla defektu) wraz z rzeczywistymi i oczekiwanymi wynikami (podkreślającymi anomalię), w tym zrzuty ekranu, zrzuty baz danych i dzienniki, jeżeli ma to zastosowanie
      - faza cyklu życia wprowadzenia, wykrycia i usunięcia defektu, w tym poziom testów, gdy ma to zastosowanie
      - produkt pracy, w którym defekt został wprowadzony
      - krytyczność wpływu na system i/lub interesariuszy produktu (zazwyczaj określany przez zachowanie techniczne systemu)
      - priorytet rozwiązania problemu (zwykle określony przez wpływ biznesowy awarii)
      - podsystem lub moduł, w którym znajduje się defekt (dla analizy gromadzenia się defektów)
      - czynność projektowa występująca w momencie wykrycia defektu
      - metoda identyfikacji, która ujawniła problem (np. przegląd, analiza statyczna, testy dynamiczne, użycie produkcyjne)
      - typ defektu (zwykle odpowiada taksonomii defektów, jeśli jest używana)
      - charakterystyka jakościowa dotknięta defektem
      - środowisko testowe, w którym zauważono defekt (dla testów dynamicznych)
      - projekt i produkt, w których występuje problem
      - obecny właściciel, czyli osoba aktualnie przydzielona do pracy nad problemem, zakładając, że raport nie jest w stanie końcowym
      - obecny status raportu (zazwyczaj zarządzany przez narzędzie do śledzenia defektów w ramach cyklu życia)
      - konkretne produkty pracy (np. elementy testowe i ich numery wydań), w których zaobserwowano problem, wraz z poszczególnymi produktami pracy, w których problem został ostatecznie rozwiązany
      - wpływ na projekt i interesy interesariuszy produktu
      - wnioski, rekomendacje i akceptacje dla działań podjętych lub niepodjętych w celu rozwiązania problemu
      - ryzyko, koszty, możliwości i korzyści związane z naprawą lub brakiem naprawy defektu
      - daty, w których wystąpiły różne przejścia w cyklu życia defektu, właściciele raportu opartego na każdym przejściu oraz działania podejmowane przez członków zespołu projektowego w celu odizolowania, naprawy i sprawdzenia poprawki defektu
      - opis sposobu, w jaki defekt został ostatecznie rozwiązany oraz zalecenia dotyczące testowania poprawki (jeśli defekt został rozwiązany przez zmianę w oprogramowaniu)
      - inne odniesienia, np. który test ujawnił defekt oraz ryzyko, wymagania lub inne elementy podstawy testów związane z wadą (dla testów dynamicznych)
  - - - Korzystanie z informacji o fazie wprowadzenia, wykrycia i usunięcia w trybie faza-po-fazie celem oceny powstrzymania fazowego oraz proponowania sposobów zwiększenia skuteczności wykrywania defektów w każdej fazie
      - Korzystanie z informacji w fazie wprowadzenia błędów do analizy Pareto dla faz, w których została wprowadzona największa liczba defektów, aby umożliwić ukierunkowane doskonalenie w celu zmniejszenia całkowitej liczby defektów
      - Korzystanie z informacji o pierwotnej przyczynie defektu w celu określenia zasadniczego powodu powstania defektu, aby umożliwić poprawę procesów, które zmniejszą liczbę defektów
      - Korzystanie z informacji o fazie wprowadzenia, wykrycia i usunięcia do wykonania analizy kosztów jakości, w celu zminimalizowania kosztów związanych z defektami
      - Korzystanie z informacji o komponentach związanych z defektami w cellu wykonania analizy skupisk defektów, aby lepiej zrozumieć ryzyko techniczne (dla testowania opartego na ryzyku) i umożliwić przeprojektowanie kłopotliwych komponentów
- - - - PROS :heavy_plus_sign:
        
        nie mają wysokich kosztów zakupu (albo w ogóle są bezpłatne)
        
        zwykle można je zmodyfikować lub rozbudować, jeśli organizacja posiada odpowiednie kompetencje (np. aby współpracowało z innymi narzędziami - przy czym im więcej narzędzi i modyfikacji, tym większa złozoność i koszty ogólne)
      - CONS :heavy_minus_sign:
        
        zazwyczaj tworzone dla rozwiązania konkretnego problemu, więc mogą nie posiadać pewnych funkcji, które z kolei mają rozwiązania komercyjne ("za darmo nie można mieć wszystkiego")
        
        mogą nie posiadać formalnego wsparcia (jednak może istnieć community, która będzie wspierać nieformalnie)
        
        trzeba się upewnić, że zespół nie zaczyna używać narzędzi otwartych tylko dla nich samych - tak jak w przypadku innych narzędzi celem głównym jest dodatni zwot z inwestycji
        
        trzeba rozumieć schemat licencjowania narzędzia, np. jeden z wariantów GNU General Public License wymaga, aby dystrubucja oprogramowania odbywała się na tych samych zasadach, na jakich zostało ono pozyskane (w przypadku dostosowania narzędzia, może być konieczność udostępnienia wykonanych zmian pozostałym użytkownikom na tych samych zasadach licencyjnych) - trzeba zatem sprawdzić skutki prawne w przypadku redystrybucji oprogramowania
        
        dokładność działania tych narzędzi najczęściej nie jest potwierdzona certyfikatem ("nie są walidowane"), więc raczej nie mogą być użyte do testowania oprogramowania krytycznego pod względem bezpieczenstwa czy takiego, które musi być zgodne z przepisami prawnymi; jeśli chcielibyśmy takie narzędzia certyfikować to trzeba by wyłożyć kasę na proces certyfikacji (dodatkowy koszt)
    - - PROS :heavy_plus_sign:
        
        jest dokładnie dopasowane do potrzeb zespołu i może efektywnie pracować w wymaganym przez zespół kontekście
        
        może być napisane tak, żeby współpracowało z innymi używanymi narzędziami i żeby generowało dane dokładnie w takiej formie, jaka jest potrzebna
        
        może mieć zastosowanie w organizacji poza projektem, w którym zostało stworzone (czyli w innym projekcie) - przy czym przed przekazaniem narzędzia do innego projektu trzeba przemyśleć cel, korzyści i wady
      - CONS :heavy_minus_sign:
        
        zespół musi mieć odpowiednie kompetencje, aby rozwijać własne narzędzia
        
        są często zależne od ich twórców - gdy taki twórca odejdzie z organizacji ("osieroci" narzędzie), można się znaleźć w czarnej du%# - dlatego ważne jest posiadanie odpowiedniej dokumentacji do takiego narzędzia
        
        może prowadzić do fałszywie pozytywnych raportów defektów lub tworzenia niedokładnych danych - gdy jakość narzędzia jest niska ("zastosowanie narzędzia może z czasem zostać rozszerzone poza początkowy cel, co może spowodować problemy z jakością narzędzia)
    - - trzeba zapewnić, że narzędzie zwiększa wartość pracy zespołu i daje organizacji pozytywny zwrot z inwestycji,
        
        przed pozyskaniem narzędzia trzeba przeprowadzić analizę kosztow i korzyści - przeanalizować koszty (pieniężne, czas itp.) oraz uwzględnić możliwe ryzyka
        
        nie wszystkie narzędzia dostarczają korzyści, które przeważają nad ryzykami
        
        całkowite ROI zależy od wszystkich używanych narzędzi (rzadko używa się tylko jednego); narzędzia powinny wymieniać informacje i współpracować
        
        dobrym pomysłem jest posiadanie strategii dotyczącej narzędzi testowych
      - Rodzaje kosztów (niepowtarzające się i powtarzające):
        
        Koszty niepowtarzające się: :repeat_one:
        
        definiowanie wymagań narzędzia, tak, aby spełniało ono zadane cele
        
        ocena i wybór odpowiedniego narzędzia i jego dostawcy
        
        nabycie, adaptacja lub stworzenie narzędzia
        
        przeprowadzenie wstępnego szkolenia z narzędzia
        
        integracja narzędzia z innymi narzędziami
        
        zakup oprogramowania i sprzętu potrzebnego do wsparcia narzędzia
        
        Koszty powtarzające się: :repeat:
        
        posiadanie narzędzia: opłaty za licencję i wsparcie, koszt utrzymania samego narzędzia, utrzymanie artefaktów wytworzonych przez narzędzie, koszty ciągłego szkolenia i mentoring
        
        przenoszenie narzędzia na inne środowiska
        
        dostosowanie narzędzia do przyszłych potrzeb
        
        doskonalenie jakości narzędzia oraz procesu w celu zapewnienia optymalnego wykorzystania wybranych narzędzi
        
        koszty utraconych korzyści - czas spędzony na wdrożenie narzędzia (pozyskanie, zarządzanie, szkolenia itp.) mógł być przeznaczony na wykonywanie zadań testowych; dlatego na początku, do momentu uruchomienia narzędzia, może być potrzebnych więcej zasobów
      - Ryzyka związane z wykorzystaniem narzędzi:
        
        vide sylabus CTFL
        
        niedostateczna dojrzałość organizacji (nie jest gotowa do wykorzystania narzędzia)
        
        artefakty tworzone przez narzędzie mogą być trudne w utrzymaniu wymagając wielu poprawek, gdy zmienia się testowane oprogramowanie
        
        zmniejszenie udziału Analityków Testów w zadaniach testowych może spowodować obniżenie wartości testowania (np. skuteczność wykrywania defektów zmniejsza się, gdy wykonywane są jedynie skrypty automatyczne)
      - Korzyści z wdrożenia i używania narzędzi:
        
        redukcja powtarzającej się pracy
        
        skrócenie cyklu testowego (np. przez wykorzystanie automatycznych testów regresywnych)
        
        zmniejszenie kosztów wykonania testów
        
        zwiększenie ilości pewnych typów testów (np. testów regresywnych)
        
        zmniejszenie liczby błędów popełnianych przez ludzi w różnych fazach testów (np. dane testowe wygenerowane przez narzędzie mogą być bardziej poprawne; porównywanie wyników testów może być dokładniejsze, wprowadzanie danych testowych może być bardziej poprawne)
        
        zmniejszenie wysiłku potrzebnego do skorzystania z informacji o testach (np. raporty i metryki wygenerowane przez narzędzie, powtórne wykorzystanie zasobów testowych takich, jak przypadki testowe, skrypty testowe i dane testowe)
        
        zwiększenie ilości testów, których nie można wykonać bez narzędzi (np. testów wydajnościowych i obciążeniowych)
        
        podniesienie statusu testerów, którzy automatyzują, oraz organizacji testowej jako całości przez pokazanie zrozumienia i wykorzystania wyszukanych narzędzi
    - - Różne punkty widzenia podczas wyboru narzędzia:
        
        :warning: Aby zapewnić, że uwzględnione zostały wszystkie punkty widzenia (biznes, projekt, użytkownik), należy stworzyć mapę drogową wdrażania narzędzia testowego.
        
        1) biznesowy - wymagany jest dodatni zwrot z inwestycji; organizacja powinna się upewnić, że narzędzia (testowe i niezwiązane z testowaniem), które mają być powiązane, faktycznie współdziałają; czasami, aby zapewnić współdziałanie narzędzi, trzeba usprawnić procesy i łączność, co może zająć czas
        
        2) projektowy - narzędzie ma być skuteczne (np. zmniejszać liczbę pomyłek przy manulanym wykonywniu testów, np. literówek - takich, jak te powyżej:)); musi minąć trochę czasu zanim inwestycja się zwróci (np. zwróci się dopiero w drugim wydaniu czy w fazie utrzymania, a nie podczas pierwszego projektu) - czyli trzeba brać pod uwagę cały cykl życia aplikacji
        
        3) użytkownika - narzędzie ma faktycznie wspierać członków zespołu, tak aby lepiej wykonywali swoje zadania; trzeba brać pod uwagę krzywą uczenia - tak żeby użytkownicy byli w stanie opanować narzędzie szybko i przy minimalnym stresie; przy pierwszym wdrożeniu narzędzia testowe wymagają szkoleń i
        wsparcia w formie mentoringu dla użytkowników
      - Proces wyboru narzędzi testowych
        
        1) oceń dojrzałość organizacji
        
        2) zidentyfikuj wymagania na narzędzia
        
        3) oceń narzędzia
        
        4) oceń dostawcę lub dostępne wsparcie (dla narzędzi testowych lub pisanych na zamówienie)
        
        5) zidentyfikuj wewnętrzne wymagania na coaching i mentoring w użyciu narzędzia
        
        6) oceń potrzeby szkoleniowe uwzględniając obecne umiejętności zespołu testowego w zakresie automatyzacji testów
        
        7) oszacuj koszty i korzyści
      - Określenie możliwości narzędzia
        
        ANALIZA:
        
        Czy narzędzie „zrozumie” podane dane wejściowe?
        
        Czy narzędzie nadaje się do tego, do czego chcemy go użyć?
        
        PROJEKTOWANIE:
        
        Czy narzędzie pomoże projektować testalia na podstawie istniejących informacji (np. narzędzie do projektowania przypadków testowych utworzy przypadki testowe z wymagań)?
        
        Czy projektowanie będzie automatyczne?
        
        Czy kod testaliów zostanie wygenerowany w całości lub częściowo w formacie używalnym i utrzymywalnym?
        
        Czy potrzebne dane mogą zostać wygenerowane automatycznie (dane generowane z analizy kodu)?
        
        DANE I WYBÓR TESTÓW:
        
        Jak narzędzie wybiera potrzebne mu dane (np. który przypadek testowy wykonać z którym zestawem danych)?
        
        Czy narzędzie przyjmuje kryteria wyboru podane automatycznie albo ręcznie?
        
        Czy narzędzie jest w stanie określić jak, „wyszorować” dane produkcyjne bazując na wybranych danych wejściowych? ["wyszorować" kulwa, tłumaczenie level master]
        
        Czy narzędzie jest w stanie określić, które testy są potrzebne bazując na kryteriach pokrycia (np. mając podany zbiór wymagań prześledzić powiązania, żeby określić, które testy należy wykonać)?
        
        WYKONANIE:
        
        Czy narzędzie wykonuje testy automatycznie, czy wymagana jest interwencja człowieka?
        
        Jak narzędzie zatrzymuje się i restartuje?
        
        Czy narzędzie powinno być w stanie „odbierać” istotne zdarzenia (np. czy narzędzie do zarządzania testami powinno automatycznie zmieniać status przypadku testowego, gdy zostanie zamknięty raport błędu zgłoszony z powodu tego przypadku)?
        
        OCENA:
        
        Jak narzędzie oceni, czy dostało poprawny wynik (np. narzędzie wykorzysta wyrocznię testową do ustalenia, czy odpowiedź systemu jest prawidłowa)?
        
        Jakie możliwości reakcji na błąd narzędzie posiada?
        
        Czy narzędzie ma odpowiednie możliwości logowania i raportowania?
  - - - po dokonaniu wyboru narzędzia, trzeba wyznaczyć kogoś (zwykle AT lub TAT) na administratora narzędzia - będzie on decydował, kiedy i jak narzędzie ma być użyte, gdzie będą składowane artefakty, jaka będą konwencje nazewnicze itp. > podjęcie tych decyzji na początku (a nie ad hoc w trakcie) może zwiększyć ROI; pewnie trzeba też będzie zrobić szkolenia dla użytkowników narzędzia
    - - w zakresie odpowiedzialności administratora lub jakiejś dedykowanej grupy; należy tutaj rozważyć m.in. sposoby wymiany danych i współpracy między narzędziami (jeśli już jakieś mamy) oraz sposoby wykonywania i odtwarzania kopii zapasowych narzędzia
    - - z czasem mogą być konieczne zmiany w narzędziu i sposobie jego wykorzystania, bo np. zmieni się środowisko (im bardziej złożone środowisko, w ktorym narzędzie działa, tym bardziej nawet mała zmiana może coś zepsuć) czy potrzeby biznesowe lub wystąpią problemy z dostawcą (np. dostawca wymusi aktualizację, po której coś się "wysypie", np. narzędzie przestanie współpracować z innymi) - w takich sytuacjach trzeba będzie coś zrobić, aby zapewnić ciągłość pracy narzędzia
    - - w momencie narzędzie trzeba "wdzięcznie zezłomować" - należy wówczas zastąpić funkcjonalność narzędzia, zabezpieczyć i zarchwizować dane
  - - - narzędzia do zarządzania testami: badanie pokrycia (śledzenie powiązań od wymagań do przypadków testowych, automatyczne skrypty), sprawdzenie jakie są aktualnie testy (dostępne, planowane), jaki jest bieżący stan wykonania testów (zaliczone, niezaliczone, pominięte, zablokowane, w kolejce)
      - narzędzia do zarządzania zgłoszeniami błędów: informacje o defektach (status, waga, priorytet, rozkład w systemie itp.), fazy, w jakich błąd został popełniony i znaleziony, współczynnik ucieczki - pomagają w doskonalenie procesów
      - narzędzia do analizy statycznej: mogą pomóc w wykryciu i zaraportowaniu problemów z utrzymaniem
      - narzędzia do testów wydajnościowych: dane na temat skalowalności systemu
      - narzędzia do mierzenia pokrycia: pomagają zrozumieć, jak dokładnie system został przetestowany