Please enable JavaScript.

Coggle requires JavaScript to display documents.

ISTQB - Coggle Diagram

- - - - Rozpoczęcie przeglądu
        
        rozesłanie produktu pracy i materiałów
        
        wyjaśnienie uczestnikom zakresu, celów, ról, produktów pracy
      - Przegląd indywidualny
        
        dokonanie przeglądu
        
        odnotowanie defektów, zaleceń, pytań
      - Przekazanie informacji o problemach i analiza problemu
        
        przekazanie informacji o defektach
        
        analiza defektów
        
        dokonanie oceny charakterystyk jakościowych
        
        dokonanie oceny wniosków z przeglądu pod kątem kryteriów wyjścia (odrzucenie/akceptacja produktu pracy)
      - Usunięcie defektów i raportowanie
        
        raport o defektach wymagających zmiany
        
        usunięcie defektów
        
        aktualizacja statusów defektów
        
        zaakceptowanie produktu pracy po spełnieniu kryteriów wyjścia
      - Planowanie
        
        zakres prac
        
        nakład pracy i ram czasowych
        
        typ przeglądu, role, czynności i listy kontrolne
        
        wybór osób i przypisanie im ról
        
        określenie kryteriów wejścia i wyjścia
        
        sprawdzenie czy zostały określone kryteria wejścia
    - - Autor
        
        tworzy produkt pracy
        
        usuwa defekty
      - Kierownictwo
        
        planuje przegląd
        
        decyduje o wykonaniu przeglądu
        
        wyznacza pracowników, określa budżet i ramy czasowe
        
        monitoruje opłacalność przeglądu
      - Facylitator
        
        prowadzi spotkania
        
        mediator
      - Lider przeglądu
        
        decyduje kto ma wziąć udział, określa miejsce i termin przeglądu
      - Przeglądający
        
        identyfikują potencjalne defekty
        
        reprezentują różne punkty widzenia
      - Protokolant
        
        gromadzi informacje o potencjalnych defektach
        
        rejestruje nowe potencjalne defekty, otwarte punkty, decyzje
    - - Przegląd nieformalny
        
        Cel: wykrycie potencjalnych defektów
        
        Sprawdzenie koleżeńskie
      - Przejrzenie
        
        Cel: wykrycie defektów, podniesienie jakości oprogramowania, rozważenie alternatywnej implementacji, dokonanie oceny zgodności z normami/standardami i specyfikacjami
        
        wymagany udział protokolanta
        
        może mieć formę scenariuszy, przebiegów próbnych lub symulacji
        
        charakter może być różny - od nieformalnego po bardzo formalny
      - Przegląd techniczny
        
        Cel: uzyskanie konsensusu, wykrycie defektów
        
        przeglądający o takich samych kompetencjach jak autor
        
        indywidualne przygotowanie przed spotkaniem związanym z przeglądem
        
        spotkanie nieobowiązkowe
        
        wymagany udział protokolanta
        
        na ogół są tworzone: defekt, raport z przeglądu
      - Inspekcja
        
        Cel: wykrycie defektów, dokonanie oceny jakości produktu pracy i zwiększenie zaufania do niego, zapobieganie wystąpieniu w przyszłości podobnych defektów poprzez przekazanie wniosków autorowi i przeprowadzeniu analizy przyczyny podstawowej
        
        przegląd odbywa się zgodnie ze zdefiniowanym procesem opartym na regułach i listach kontrolnych a rezultaty są dokumentowane
        
        występują jednoznacznie zdefiniowane role
        
        indywidualne przygotowanie przed spotkaniem jest obowiązkowe
        
        przeglądającymi są osoby zajmujące stanowiska równorzędne do autora lub eksperci w innych dyscyplinach istotnych z punktu widzenia produktu pracy
        
        obowiązują określone kryteria wejścia i wyjścia
        
        obecność protokolanta obowiązkowa
        
        przegląd prowadzi przeszkolony facylitator
        
        autor nie może być liderem przeglądu, osobą czytającą ani protokolantem
        
        zbierane są miary wykorzystywane następnie do udoskonalania całego procesu wytwarzania oprogramowania
    - - Przegląd oparty na rolach
        
        Ocena produktu pracy z perspektywy poszczególnych ról przypisanych interesariuszom (użytkownicy końcowi - doświadczony, niedoświadczony etc.; funkcje w organizacji - użytkownik, amdin, tester wydajności
      - Czytanie oparte na perspektywie
        
        Przeglądający przyjmują podczas pzeglądu punkt widzenia różnych interesariuszy (użytkownik, pracownik działu marketingu, projektant, tester)
      - Scenariusze i przebiegi próbne
        
        Ustrukturyzowane wytyczne dotyczące sposobu zapoznawania się z produktem pracy. Umożliwia przeglądającym wykonanie przebiegów próbnych takich produktów zgodnie z ich przewidywanym zastosowaniem (np. dokumentacja w postaci przypadków użycia)
      - Przegląd oparty na liście kontrolnej
        
        Usystematyzowana technika, zgodnie z którą przeglądający wykrywają problemy na podstawie list kontrolnych. Lista kontrolna zawiera zestaw pytań odopowiadających potencjalnym defektom na podstawie dotychczasowych doświadczeń.
      - Przegląd ad hoc
        
        Niewiele wskazówek przed przeglądem. Polega na czytaniu produktu sekwencyjnie, na bieżąco identyfikując stwierdzone problemy. Powodzenie zależy od umiejętności przeglądających.
- - - - ocena produktów pracy (wymagania, historyjki, projekt, kod)
      - sprawdzenie czy zostały spełnione wszystkie wyspecyfikowane wymagania
      - sprawdzenie czy przedmiot testów jest kompletny i działa zgodnie z oczekiwaniami użytkowników i innych interesariuszy
      - budowanie zaufania do poziomu jakości przedmiotu testów
      - zapobieganie defektom
      - wykrywanie defektów i awarii
      - dostarczanie interesariuszom informacji niezbędnych do podejmowania decyzji
      - oniżanie poziomu ryzyka związanego z jakością oprogramowania (np. wystąpienia niewykrytych awarii)
      - spełnienie umów, norm, przepisów, standardów
  - - - Identyfikowanie defektów w produktach pracy zmniejsza ryzyko wutworzenia niepoprawnej lub nietestowalnej funkcjonalności
      - współpraca tester - projektant systemu = lepsze zrozumienie projektu i sposobu testowania
      - współpraca tester - programista = lepsze zrozumeinie kodu i sposobu testowania. Zmniejszenie ryzyka wystąpienia defektów w kodzie.
      - weryfikacja i walidacja - wykrycie defektów przed przekazaniem do eksploatacji. Ułatwia usuwanie defektów (debugowanie). W rezultacie zwiększa prawdopodobieństwo, że oprogramowanie zaspokoi potrzeby interesariuszy i spełni stawiane mu wymagania.
    - - Zapewnienie jakości
        
        Skupia się na prawdiłowym przestrzeganiu właściwych procesów. Jeśli procesy są przestrzegane w ich wyniku produkty pracy mają zwykle wyższą jakość, co przyczynia się do zapobiegania defektom.
        
        Analiza przyczyny podstawowej - wykrywanie i usuwanie przyczyn defektów
      - Kontrola jakości
        
        m.in. czynności testowe
  - - - Analizowanie wpływu zmian
      - Przeprowadzenie audytu testów
      - Przekazywanie informacji interesariuszom w zrozumiałej formie
      - Spełnienie kryteriów związanych ze standardami
      - Bardziej zrozumiałe raporty o statusie testów
      - Udzielanie informacji potrzebnych do oceny jakości produktów
    - - Planowanie testów
        
        Czynności i zadania testowe
        
        Zdefiniowanie celów testowania
        
        Określenie podejścia do osiągania celów testowania w granicach wyznaczonych przez kontekst: określenie odpowiednich technik testowania, zadań testowych, harmonogramu
        
        Produkty pracy
        
        Plan testów:
        
        informacje na temat podstawy testów z którą zostaną powiązane testalia
        
        kryteria wyjścia - definicja ukończenia
      - Monitorowanie i nadzór testów
        
        Czynności i zadania testowe
        
        Monitorowanie - ciągłe porównywanie rzeczywistego z zaplanowanym postępem testowania
        
        Nadzór - podejmowanie działań, które są niezbędne do osiągnięcia celów wyznaczonych w planie testów (z uwzględnieniem aktualizacji)
        
        Ocena kryteriów wyjścia
        
        Sprawdzenie resultatu testów i dziennika testów pod kątem określonych kryteriów pokrycia
        
        Oszacowanie poziomu jakości modułu lub systemu na podstawie rezultatów testów i dziennika testów
        
        Ustalenie, czy są konieczne dalsze testy
        
        Produkty pracy
        
        Raporty z testów:
        
        raporty o postępie
        
        sumaryczne raporty końcowe
      - Analiza testów
        
        Czynności i zadania testowe
        
        Przeanalizowanie podstawy testów
        
        Zidentyfikowanie testowalnych cech
        
        Zdefiniowanie warunków testowych
        
        "Co należy przetesować?"
        
        Ocena testowalności podstawy testów i elementów testowych: niejednoznaczności, pominięcia etc.
        
        Określenie priorytetów warunków testowych
        
        Stworzenie trecability podstawa testów - warunki testowe
        
        Produkty pracy
        
        Zdefiniowane i uszeregowane według priorytetów warunki testowe
      - Projektowanie testów
        
        Czynności i zadania testowe
        
        Przekształcanie warunków testowych w przypadki testowe wysokiego poziomu, zbiory przypadków oraz określenie ich priorytetów.
        
        "Jak należy testować?"
        
        Identyfikowanie danych testowych
        
        Projektowanie środowiska testowego oraz zidentyfikowanie narzędzi i elementów infrastruktury
        
        Stworzenie traceability podstawa testów - warunki testowe - przypadki testowe - procedury testowe
        
        Produkty pracy
        
        Przypadki testowe i zestawy testowe
      - Ukończenie testów
        
        Czynności i zadania testowe
        
        Sprawdzenie czy wszystkie raporty o defektach są zamknięte
        
        Utworzenie raportu z testów
        
        Dla wersji końcowej: archiwizacja środowiska, danych testowych, infrastruktury i innych testaliów
        
        Przekazanie testaliów zespołom odpowiedzialnym za pielęgnację, innym zespołom, interesariuszom
        
        Przeanalizowanie zdobytych doświadczeń
        
        Wykorzystanie zebranych informacji do zwiększenia dojrzałości procesu testowego
        
        Produkty pracy
        
        Sumaryczne raporty z ukończenia testów, retrospektywa, żądanie zmian, listy zaległości produktowych, ostateczna wersja testaliów
      - Implementacja testów
        
        Czynności testowe i zadania testowe
        
        Opracowanie procedur testowych i określenie ich priorytetów
        
        Utworzenie skryptów testów automatycznych
        
        Utworzenie zestawów testowych oraz skryptów testów automatycznych
        
        Uporządkowanie zestawów testów w harmonogram wykonywania testów
        
        Zbudowanie środowiska testowego
        
        Przygotowanie danych testowych
        
        Zweryfikowanie i zaktualizowanie traceability podstawa testów - warunki testowe - przypadki testowe - procedury testowe - zestawy testowe
        
        Produkty pracy
        
        Procedury testowe oraz kolejność ich wykonywania
        
        Zestawy testowe
        
        Harmonogram wykonywania testów
      - Wykonywanie testów
        
        Czynności testowe i zadania testowe
        
        Uruchomienie zestawów testowych zgodnie z harmonogramem
        
        Zarejestrowanie wersji elementów testowych, przedmiotu testów, narzędzi, testaliów
        
        Wykonywanie testów ręcznie lub przy użyciu narzędzi
        
        Porównanie rzeczywistych wyników z oczekiwanymi
        
        Analizowanie anomalii i ustalanie przyczyn
        
        Raportowanie defektów
        
        Zarejestrowanie wyniku testów
        
        Powtórzenie czynności testowych, testowanie potwierdzające, poprawione testy, testowanie regresji
        
        Zweryfikowanie i zaktualizowanie traceability podstawa testów - warunki testowe - przypadki testowe - procedury testowe - wyniki testów
        
        Produkty pracy
        
        Dokumentacja dotycząca statusu poszczególnych przypadków testowych lub procedur testowych
        
        Raporty o defektach
        
        Dokumentacja wskazująca, które elementy, przedmioty, narzędzia testowe i testalia zostały wykorzystane w ramach testowania
    - - Ograniczenia operacyjne: budżet, zasoby, harmonogramy, złożoność procesu lub projektu, wymagania wynikające z umów i przepisów
      - Polityka testów i praktyki obowiązujące w organizacji
      - Dziedzina biznesowa
      - Wymagane normy/standardy wew. i zew.
      - Czynniki ryzyka produktowego i projektowego
      - Poziomy testów i typy testów
      - Model cyklu życia oprogramowania i metodyki projektowe
- - - - każdy poziom testów ma przypisane cele odpowiednie do tego poziomu
      - analizę i projektowanie testów należy rozpocząć podczas wykonywania odpowiedniego poziomu testów (wczesne tesowanie)
      - dla każdej czynności związanej z wytwarzaniem orpogramowania istnieje odpowiadająca jej czynność testowa
      - testerzy powinni uczestniczyć w dyskusjach dotyczących definiowania i doprcyzowywania wymagań, założeń projektu, przeglądów jak najwcześniej
    - - Model kaskadowy (waterfall)
      - model V
      - Liniowy przepływ czynności następujący kolejno po sobie
    - - SCRUM
        
        krótkie iteracje, małe części funkcjonalności na raz
      - Kanban
        
        jedno udoskonalenie/funkcjonalność lub grupa na raz
      - Model spiralny (prototypowanie)
        
        eksperymentalne elementy przyrostowe, mogą być do gruntownego przebudowania albo porzucenia
      - Przyrostowe wytwarzanie - funkcjonalność oprogramowania rośnie przyrostowo. W zależności od modelu są to większe lub mniejsze fragmenty.
      - Iteracyjne wytwarzanie - wspólne wytwarzanie grup funkcjonalności w serii cyklii, często o określonym czasie trwania. Każda iteracja dostarcza działające oprogramowanie, które stanowi rosnący podzbiór całkowitego zbioru funkcjonalności.
      - RUP
        
        długie iteracje
    - - Cel projektu
      - Typ wytwarzanego produktu
      - Priorytety biznesowe
      - Czynniki ryzka produktowego i projektowego
  - - - Podstawa testów
        
        projekt szczegółowy
        
        kod
        
        model danych
        
        specyfikacje modułów
      - Przedmiot testów
        
        moduły, jednostki lub komponenty
        
        kod i struktury danych
        
        klasy
        
        moduły baz danych
      - Cele szczegółowe
        
        zmniejszanie ryzyka
        
        sprawdzanie zgodności zachowań funkcjonalnych i niefunkcjonalnych modułu z projektem i specyfikacjami
        
        budowanie zaufania do jakości modułu
        
        wykrywanie defektów w module
        
        zapobieganiu przedostawaniu się defektów na wyższe poziomy testowania
        
        Automatyczne modułowe testy regresji - kluczowy element w zwinnym wytwarzaniu oprogramowania gdzie zmiany kodu mają charakter ciągły
        
        Testowanie modułowe może obejmować funkcjonalność, parametry niefunkcjonalne (wycieki pamięci) oraz właściwości strukturalne (testowanie decyzji)
      - Typowe defekty i awarie
        
        niepoprawna funkcjonalność
        
        problemy z przepływem danych
        
        niepoprawny kod i logika
      - Konkretne podejścia i odpowiedzialności
        
        Zwykle wykonywane przez programistę. Pisane przed implementacją modułu (TDD) lub po napisaniu kodu danego modułu
    - - Podstawa testów
        
        projekt oprogramowania i systemu
        
        diagramy sekwencji
        
        specyfikacje interfejsów
        
        przypadki użycia
        
        architektura na poziomie modułów i systemu
        
        przepływy pracy
        
        definicje interfejsów zewnętrznych
      - Typowe defekty i awarie
        
        Integracja modułów:
        
        niepoprawne lub brakujące dane
        
        niepoprawne uszeregowanie lub niepoprawna synchronizacja wywołań interfejsów
        
        niezgodność interfejsów
        
        błędy komunikacji między modułami
        
        brak obsługi lub niepoprawna obsługa komunikacji między modułami
        
        niepoprawne założenia dotyczące znaczenia, jednostek lub granic danych przesyłanych między modułami
        
        Integracja systemów:
        
        to samo co dla modułów
        
        niespójne struktury komunikatów przesyłanych między systemami
        
        nieprzestrzeganie rygorystycznych, obowiązujących przepisów dotyczących zabezpieczeń
      - Cele szczegółowe
        
        Skupia się na interakcjach między modułami lub systemami
        
        zmniejszanie ryzyka
        
        sprawdzanie zgodności zachowań funkcjonalnych i niefunkcjonalnych interfejsu z projektem i specyfikacjami
        
        budowanie zaufania do jakości interfejsu
        
        wykrywanie defektów w (w intrfejsach lub modułach)
        
        zapobieganiu przedostawaniu się defektów na wyższe poziomy testowania
        
        Poziomy testowania integracyjnego:
        
        integracja modułów wykonywane po testach modułowych
        
        integracji systemów wykonywane na etapie testów systemowych lub później
      - Konkretne podejścia i odpowiedzialności
        
        Testy nie powinny skupiać się na funkcjonalnościach modułów tylko na komunikacji między nimi.
        Na tym etapie można przeprowadzić testy funkcjonalne, niefunkcjonalne i strukturalne.
        Zaleca się integrację metodą przyrostową - łatwiejsze znajdowanie błędów.
      - Przedmioty testów
        
        podsystemy
        
        bazy danych
        
        infrastruktura
        
        interfejsy
        
        API
        
        mikrousługi
    - - Podstawa testów
        
        specyfikacje wymagań
        
        raporty z analizy ryzyka
        
        przypadki użycia
        
        opowieści i historyjki użytkownika
        
        modele zachowania systemu
        
        diagramy stanów
        
        instrukcje obsługi systemu i podręczniki użytkownika
      - Przedmiot testów
        
        aplikacja
        
        systemy łączące sprzęt i oprogramowanie
        
        systemy operacyjne
        
        systemy podlegające testowaniu
        
        konfiguracja i dane konfiguracyjne systemu
      - Cele testowania
        
        Skupia się na zachowaniach i możliwościach całego systemu lub produktu.
        
        zmniejszanie ryzyka
        
        sprawdzanie zgodności zachowań funkcjonalnych i niefunkcjonalnych systemu z projektem i specyfikacjami
        
        sprawdzanie kompletności systemu i prawidłowości jego działania
        
        budowanie zaufania do całości systemu jako całości
        
        wykrywanie defektów
        
        zapobieganie przedostawania się defektów na poziom testowania akceptacyjnego lub na produkcję
        
        Często rezultatem testowania systemowego są informacje na podstawie których interesariusze podejmują decyzję o przekazaniu systemu do użycia produkcyjnego
        
        Testowanie systemowe może być niezbędne do spełnienia wymagań wynikających z przepisów prawa lub norm, standardów
      - Typowe defekty i awarie
        
        niepoprawne obliczenia
        
        niepoprawne lub nieoczekiwane zachowania funkcjonalne i niefunkcjonalne
        
        niepoprawne przepływy sterowania lub przepływy danych
        
        problemy z prawidłowym i kompletnym wykonaniem całościowych zadań funkcjonalnych
        
        problemy z prawidłowym działaniem systemu w środowisku produkcyjnym
        
        niezgodność systemu z opisami w instrukcjach i podręcznikach użytkownika
      - Konkretne podejścia i odpowiedzialności
        
        Kompleksowe zbadanie zachowania systemu jako całości na poziomie zarówno funkcjonalnym jak i niefunkcjonalnym.
    - - Typowe defekty i awarie
        
        systemowe przepływy pracy niezgodne z wymaganiami biznesowymi lum wymaganiami użytkowników
        
        niepoprawnie zaimplementowane reguły biznesowe
        
        niespełnienie przez system wymagań umownych lub prawnych
        
        awarie niefunkcjonalne, takie jak podatność zabezpieczeń, niedostateczna wydajność
      - Przedmiot testów
        
        system podlegający testowaniu
        
        konfiguracja i dane konfiguracyjne systemu
        
        procesy biznesowe wykonywane na całkowicie zintegrowanym systemie
        
        systemy rezerwowe i ośrodki zastępcze służące do testowania mechanizmów zapewnienia ciąłości biznesowej i usuwania skutków awarii
        
        procesy związane z użyciem produkcyjnym i utrzymaniem
        
        formularze
        
        raporty
        
        istniejące i skonwertowane dane produkcyjne
      - Konkretne podejścia i odpowiedzialności
        
        Testowanie akceptacyjne często spoczywa na klientach, użytkownikach biznesowych, właścicielach produktu lub operatorach systemu.
      - Podstawa testów
        
        procesy biznesowe
        
        wymagania użytkowników lub wymagania biznesowe
        
        przepisy, umowy, normy i standardy
        
        przypadki użycia
        
        wymagania systemowe
        
        dokumentacja systemu lub podręczniki użytkowników
        
        procedura instalacji
        
        raporty z analizy ryzyka
        
        Na potrzeby produkcyjnych testów akceptacyjnych:
        
        procedury tworzenia kopii zapasowej
        
        procedury usuwania skutków awarii
        
        wymagania niefunkcjonalne
        
        dokumentacja operacyjna
        
        instrukcje wdrażania i instalacji
        
        założenia wydajnościowe
        
        pakiety bazodanowe
        
        normy, standardy, przepisy w dziedzinie zabezpieczeń
      - Cele testowania
        
        budowanie zaufania do systemu
        
        sprawdzenie kompletności systemu i jego prawidłowego działania
        
        sprawdzanie zgodności zachowania funkcjonalnego i niefunkcjonalnego systemu ze specyfikacją
        
        W wyniku testowania akceptacyjnego mogą powstawać informacje pozwalające ocenić gotowość systemu do wdrożenia i użytkownaia przez klienta/używtkonika.
        
        Formy testowania akceptacyjnego
        
        Testowanie przez użytkownika
        
        Symulowane środowisko produkcyjne i skupia się na sprawdzeniu czy system nadaje się do użytkowania przez przyszłych odbiorców.
        
        Produkcyjne testy akceptacyjne
        
        Testowanie wykonywane przez operatorów lub administartorów.
        
        testowaniu mechanizmów kopii zapasowej i odtwarzania danych
        
        instalowanie, aktualizowanie orpogramowania
        
        usuwanie skutków awarii
        
        czynności pielęgnacyjne
        
        ładowanie i migracja danych
        
        podatności zabezpieczeń
        
        testy wydajnościowe
        
        Testowanie zgodności z umową i zgodności z przepisami prawa
        
        Testowanie alfa i beta
        
        Testowanie alfa jest wykonywane w siedzibie organizacji wytwarzającej oprogramowanie, ale zamiast zespołu wytwórczego testy wykonują potencjalni lub obecni klienci, i/lub operatorzy bądź niezależni testerzy.
        
        Testowanie beta wykonują obecni lub potencjalni klienci we własnych lokalizacjach.
  - - - Wykonanie testów, które umożliwia dokonanie oceny funkcji, jakie powinien system realizować.
        Testy funkcjonalne należy wykonywać na każdym poziomie testów.
    - - Celem jest dokonanie ocen charakterystyk systemów i oprogramowania, takich jak: użyteczność, wydajność, bezpieczeństwo, niezawodność itd.
        Testy funkcjonalne należy wykonywać na każdym poziomie testów
    - - Warunki testowe wyprowadza się na podstawie struktury wewnętrznej lub implementacji danego systemu
    - - Po wprowadzeniu w systemie zmian mających na celu usunięcie defektu bądź dodanie lub zmodyfikowanie funkcjonalności należy przeprowadzić testy, które potwierdzą, że wprowadzone zmiany faktycznie skutkowały naprawieniem defektu lub poprawną implementacją odpowiedniej funkcjonalności, a przy tym nie wywołały żądnych nieprzewidzianych, niekorzystnych zachowań oprogramowania.
      - Testowanie potwierdzające - Sprawdzenie czy pierwotny defekt został usunięty. Po naprawie defektu można wykonać przypadki testowe, które wcześniej nie zostały zaliczone z powodu wystąpienia tego defektu. Można testować też nowymi testami jeśli defektem była brakująca funkcjonalność.
      - Testowanie regresji - istnieje ryzyko, że zmiana wprowadzona w jednej części kodu wpłynie na zachowanie innych części kodu. Niezamierzone skutki uboczne są nazywane regresjami, a testowanie regresji polega na ponownym wykonaniu testów w celu ich wykrycia.
  - - - Modyfikacja
      - Migracja
      - Wycofanie
    - - Pozwala ocenić zmiany wprowadzone w wersji pielęgnacyjnej pod kątem zarówno skutków zamierzonych, jak i spodzeiwnych lub potencjalnych skutków ubocznych
      - Zidentyfikowanie obszarów systemu, na które zmiany będą miały wpływ
- - - - Analiza wartości brzegowych
        
        Może być stosowana tylko w przypadku uporządkowanych klas zawierających dane liczbowe lub sekwencyjne
        
        Wartościami brzegowymi klasy równoważności są jej wartość minimalna i maksymalna (lub pierwsza i ostatnia wartość)
      - Tablica decyzyjna
        
        Warunki - dane wejściowe
        
        Wynikające z warunków Akcje - dane wyjściowe
        
        Reguła decyzyjna - unikatowa kombinacja warunków
        
        Wartości warunków i akcji zwykle przedstawia się jako wartości logincze true/false lub dyskretne np. czerwony, zielony etc.
        
        Modelowanie złożonych reguł biznesowych
        
        Tablicę można zredukować: kombinacja warunków niemożliwych do spełnienia; możliwe ale niewykonalne kombinacje warunków; kolumny kombinacji warunków, które nie mają wpływu na wynik
      - Testowanie przejść pomiędzy stanami
        
        Diagram przejść między stanami służy do zobrazowania możliwych stanów oprogramowania oraz przejść między nimi.
        
        Stany
        
        Zdarzenia - inicjuje przejście w inny stan
        
        Warunki dozoru
        
        Np. menu, nawigacja
      - Testowanie oparte na przypadkach użycia
        
        Weryfikuje wymagania dla funkcjonalności.
        
        Przypadki użycia opisują interakcje z elementami oprogramowania
        
        Testy projektuje się tak żeby umożliwiały sprawdzenie wszystkich zdefiniowanych zachowań (zachowanie podstawowe, wyjątkowego oraz obsługę błędów)
      - Podział na klasy równoważności
        
        Dzielenie danych na grupy w taki sposób, aby każda grupa zawierała elementy, które z założenia mają być przetwarzane w ten sam sposób
        
        Klasy równoważności można wyznaczyć dla wartości poprawnych i wartości niepoprawnych
        
        Używa się w odniesieniu do danych wejściowych, wyjściowych, wartości wewnętrznych bądź wartości zależnych od czasu, parametrów interfejsu
        
        Każda liczba musi należeć do tylko jednej klasy równoważności
        
        Warunkiem uzyskania pokrycia 100% jest pokrycie przez przypadki testowe wszystkich zdefiniowanych klas równoważności, co wymaga wybrania co najmniej 1 wartości z każdej klasy
  - - - Zgadywanie błędów
        
        Metodyczne podejście do zgadywania błędów polega na stworzeniu listy potencjalnych pomyłek, defektów i awarii, a następinie zaprojektowaniu testów pozwalających je uwidocznić.
      - Testowanie eksploracyjne
        
        Nieformalna technika projektowania testów, w której tester projektuje testy w czasie, gdy są one wykonywane i wykorzystuje się informacje zdobyte podczas testowania do projektowania nowych i lepszych testów.
      - Testowanie w oparciu o listę kontrolną
        
        Technika projektowania testów oparta na doświadczeniu, w której doświadczony tester używa listy ogólnych zagadnień, które powinny być odnotowywane, sprawdzone, zapamiętane lub zbioru reguł bądź kryteriów, względem których produkt ma być sprawdzany.
  - - - Testowanie i pokrycie instrukcji kodu
      - Testowanie i pokrycie decyzji
        
        Służy do sprawdzenia decyzji zawartych w kodzie oraz kodu wykonywanego na postawie wyników decyzji (IF, CASE etc.)