1. PROCES
1.1. https://devenv.pl/jak-wyglada-dobry-proces-testowy/
1.2. https://testerzy.pl/baza-wiedzy/artykuly/jakie-cechy-oprogramowania-warto-sprawdzic
1.3. Najwyższy poziom niezależności mają testy wykonane przez inną organizacją a najmniejszy przez autora kodu
1.4. Kryteria zakończenia testów mogą składać się z miary pokrycia kodu, funkcjonalności, istniejącego ryzyka, harmonogramów
2. BŁĄD
2.1. Definicje ISTQB
2.1.1. Błąd - na skutek działania człowieka, powstaje nieprawidłowy rezultat
2.1.2. Usterka, defekt - wynik błędu człowieka
2.1.3. Awaria - uruchomienie oprogramowania zawierającego błędy, lub konsekwencja szkodliwych czynników np. pole elektromagnetyczne
2.2. Cykl życia
2.2.1. Proces od etapu zgłoszenia do jego zamknięcia
2.2.2. Stany cyklu
2.2.2.1. New
2.2.2.1.1. Zgłoszony po raz pierwszy
2.2.2.2. Assigned
2.2.2.3. In analysis
2.2.2.4. Deferred
2.2.2.4.1. W tej iteracji nie będzie poprawiany
2.2.2.5. Rejected
2.2.2.5.1. Bezzasadny, zamknięcie bez naprawy
2.2.2.6. Duplicated
2.2.2.6.1. Dwa zgłoszenia z tą samą przyczyną, prace nie będą kontynuowane
2.2.2.7. In developement / open
2.2.2.8. Test ready / fixed
2.2.2.8.1. Wprowadzone poprawki, czeka na retesty
2.2.2.9. In test / retest
2.2.2.10. Closed
2.2.2.10.1. Błąd rozwiązany i usunięty, zmiany przetestowane z pozytywnym skutkiem
2.2.2.11. Reopen
2.2.2.11.1. Po czasie problem wystąpił ponownie
2.2.3. Zgłaszanie
2.2.3.1. Szablon notki
2.2.3.1.1. Data obserwacji, numer wersji, commit
2.2.3.1.2. Typ i wersja przeglądarki/systemu operacyjnego
2.2.3.1.3. Co zostało zaobserwowane
2.2.3.1.4. Wypunktowane kroki do odtworzenia błędu
2.2.3.1.5. Jaki powinien być rezultat po wykonanych krokach
2.2.3.1.6. Screeny, logi, nagrania
2.2.3.1.7. 1 błąd 1 notatka
2.2.3.1.8. Upewnienie się, że błąd jest reprodukowany
3. DEFEKT
3.1. Klasyfikacja
3.1.1. Trywialny
3.1.1.1. Funkcje działają poprawnie. Produkt może zostać wydany
3.1.1.2. Niepoprawnie opisane, umieszczone lub graficznie zaprezentowane
3.1.2. Średni
3.1.2.1. Pomniejsze, akceptowalne problemy
3.1.3. Poważny
3.1.3.1. Produkt niezgodny z wymaganiami, lub zaimplementowany jedynie częściowo
3.1.4. Krytyczny
3.1.4.1. Awaria systemu i/lub brak możliwości uruchomienia pewnych części aplikacji.
4. ETAPY TWORZENIA OPROGRAMOWANIA
4.1. Modele tworzenia
4.1.1. Sekwencyjny (V)
4.1.1.1. Testy jednostkowe, integracyjne, systemowe, akceptacyjne
4.1.2. Iteracyjno-przyrostowe
4.1.2.1. Krótsze cykle rozwojowe, np. prototypowanie, RAD, metodyki agile. Ważne są testy regresyjne.
4.2. Cykl
4.2.1. Plan
4.2.2. Build
4.2.3. Test
4.2.4. Release
4.2.4.1. Przygotowanie wersji w modelu ciągłym i udostępnianie (CI/CD)
4.2.5. Deploy
4.2.6. Operate
4.2.7. Monitor
4.2.7.1. Diagnozowanie wyjątków i wąskich gardeł
4.2.8. Code
4.2.8.1. BDD, analiza statyczna
5. TECHNIKI PROJEKTOWANIA
5.1. Oparte na specyfikacji lub czarnoskyrznkowe
5.1.1. Podział na klasy równoważności
5.1.1.1. Wysokie prawdopodobieństwo przetwarzania w ten sam sposób
5.1.1.2. Można je znaleźć dla wartości poprawnych i niepoprawnych
5.1.2. Analiza wartości brzegowych
5.1.2.1. Istnieje duże prawodopodobieństwo błędów przy skrajnych wartościach
5.1.2.2. Przykładowo przedziały czasowe (time out, szybkość przetwarzania transakcji), zakresy tablic
5.1.3. Tablica decyzyjna
5.1.3.1. Warunki wejściowe i wyjściowe jako prawda/fałsz
5.1.3.2. Każda kolumna odpowiada jednej regule biznesowej
5.1.4. Przejścia między stanami
5.1.5. Przypadki użycia
5.2. Białoskrzynkowe
5.2.1. Pokrycie instrukcji
5.2.1.1. Zmierzenie odsetka instrukcji wykonywalnych jaki został przetestowany przez zestaw testów
5.2.2. Pokrycie decyzji
5.2.2.1. Zmierzenie odestka wyników decyzji jaki został przetestowany przez zestaw testów
6. CRUD (SQL/HTTP)
6.1. Create
6.1.1. INSERT/PUT lub POST
6.2. Read
6.2.1. SELECT/GET
6.3. Update
6.3.1. UPDATE/POST lub PUT lub PATCH
6.4. Delete
6.4.1. DELETE
6.5. Pozwala testować prawdopodobne scenariusze
7. ŹRÓDŁA
7.1. https://testerzy.pl/
7.2. http://getistqb.com/
7.3. http://cherry-it.pl/niezbednik-juniora-testera-manualnego-cz-i/
8. SMOKE, SANITY REGRESJA
8.1. Test dymny sprawdza powierzchowne funkcjonalności i wykrywa krytyczne błędy
8.2. Sanity testy upewniają się, czy poprzednie błędy zostały naprawione i czy z wprowadzonymi nowymi zmianami nie pojawiły się kolejne.
8.3. Testy regresji są najbardziej rozbudowane i pozwalają sprawdzić, czy nie pojawiły się błędy w trakcje implementacji funkcjonalności
9. POZIOMY I TYPY
9.1. Poziomy testów
9.1.1. Jednostkowe
9.1.1.1. Pojedyncze metody, obiekty, moduły
9.1.1.2. Pełna automatyzacja
9.1.1.3. Podstawą jest rojekt szczegółowy i wymagania na moduły
9.1.2. Integracyjne
9.1.2.1. Współpraca między modułami
9.1.2.2. Podstawą jest projekt oprogramowania, architektura, przypadki użycia
9.1.2.3. Prawidłowość interakcji aplikacji z bazą danych
9.1.2.4. Wykrywanie błędów interfejsu
9.1.3. Systemowe
9.1.3.1. Analiza zachowania całego systemu
9.1.3.2. Środowisko testowe powinno być zgodne ze środowiskiem docelowym
9.1.3.3. Podstawą jest specyfikacja funkcjonalna, raporty z analizy ryzyka
9.1.4. Akceptacyjne
9.1.4.1. Upewnienie się wykonania wymagań klienta, sprawdzenie przydatności systemu
9.1.4.2. Błędy ortograficzne, kosmetyczne
9.1.4.3. Problemy zagrażające całemu produktowi
9.1.4.4. Produkcyjne, alfa, beta, zgodności z prawem, z umową
9.2. Typy testów
9.2.1. Funkcjonalne
9.2.1.1. Zewnętrzne zachowanie oprogramowania
9.2.1.1.1. Kompletność, poprawność, dokładność
9.2.1.2. Czarnoskrzynkowe
9.2.1.3. Funkcje testowane są opisywane w specyfikacji wymagań
9.2.1.4. Wykrywanie błędów bez informacji o przyczynie
9.2.1.5. M.in. testy eksploracyjne, zabezpieczeń
9.2.2. Niefunkcjonalne
9.2.2.1. Wydajnościowe
9.2.2.1.1. Uruchamianie jak najwięcej działań i sprawdzanie czasu odpowiedzi
9.2.2.2. Obciążeniowe
9.2.2.2.1. Zwiększenie liczby użytkowników i działań
9.2.2.2.2. Zużycie zasobów, testowanie stresowe, w pikach
9.2.2.3. Użyteczności
9.2.2.3.1. Intuicyjność i łatwość obsługi
9.2.2.3.2. Zapobieganie błędom użytkownika, estetyka
9.2.2.4. Niezawodności
9.2.2.4.1. Sprawność funkcjonalności w określonych warunkach
9.2.2.4.2. Dostępność, tolerancja na błędy, odtwarzalność
9.2.3. Strukturalne
9.2.3.1. Są białoskrzynkowe
9.2.3.2. Stopień, w jakim struktura jest przetestowana przez zestaw testów
9.2.4. Potwierdzające (regresywne)
9.2.4.1. Po zakończeniu procesów testowych i naprawie usterek
9.2.4.2. Potwierdzenie sprawnego działania programu
9.2.4.3. Sprawdzenie pod kątem ukrytych błędów, odsłoniętych na skutek wykonanych zmian
10. TECHNIKI STATYCZNE
10.1. Sprawdzanie ręczne - przeglądy, analiza kodu i innych dokumentów projektowych bez uruchamiania oprogramowania
10.1.1. Przegląd nieformalny
10.1.1.1. Np. programowanie w parach, może być udokumentowany
10.1.2. Przejrzenie
10.1.2.1. Spotkanie prowadzone przez autora, opcjonalne przygotowanie raportu, np. forma scenariuszy
10.1.3. Przegląd techniczny
10.1.3.1. Przygotowanie raportu (lista uwag, ocena zgodności z wymaganiami, rekomendacje)
10.1.3.2. Służy przedyskutowaniu, wyszukaniu usterek, rozwiązaniu problemów technicznych
10.1.4. Inspekcja
10.1.4.1. Prowadzona przez moderatora, posaida metryki, formalny proces oparty na liście kontrolnej, zdefiniowane kryteria wejścia i zakończenia.
10.1.5. Przegląd formalny
10.1.5.1. Planowanie
10.1.5.1.1. Definiowanie kryteriów przeglądu, wybór uczestników i przydział ról
10.1.5.1.2. Kryteria wejścia i zakończenia
10.1.5.2. Rozpoczęcie
10.1.5.3. Przygotowanie indywidualne
10.1.5.4. Kontrola/ocena/zapisanie wyników (spokanie przeglądowe)
10.1.5.4.1. Zapisywanie defektów i rekomendacji, podejmowanie decyzji
10.1.5.5. Poprawki
10.1.5.6. Zakończenie