Przed wdrożeniem
Nowy produkt lub duża funkcja idzie na produkcję. Krytyczne i wysokie błędy naprawiamy przed startem.
Playbook
Playbook testów systemów i aplikacji
Procedura, według której Hindbrain testuje backend, web, aplikacje okienkowe i mobilne oraz bezpieczeństwo. Odhaczaj punkty, drukuj dokumenty i sprawdź, czego brakuje w Twoim projekcie.
Kiedy używać tego playbooka
Po przejęciu aplikacji
Dostajesz system od innego wykonawcy. Sprawdzamy, co naprawdę działa, zanim zaczniesz go rozwijać.
Raz w roku
Aplikacja już działa. Powtarzamy pełny przegląd, bo zależności, uprawnienia i konfiguracja się starzeją.
Ile to trwa
Audyt bezpieczeństwa typowej aplikacji B2B zajmuje 4 do 5 dni roboczych. Czas całej ścieżki zależy od liczby gałęzi: [NEED: widełki czasu pełnej ścieżki testów dla aplikacji web, desktop i mobile].
Co dostajesz
- Raport ze znaleziskami: opis, dowód, wpływ biznesowy, ocena CVSS 3.1 i naprawa krok po kroku
- Protokół testów akceptacyjnych podpisany przez obie strony
- Retest po poprawkach w tym samym raporcie
- Listę rzeczy sprawdzonych bez zastrzeżeń
- Rekomendację: wdrażać czy nie
Mapa ścieżki testów
Siedem etapów po kolei. Testy frontu rozgałęziają się na web, aplikację okienkową i mobilną, a potem schodzą się w testach integracji i bezpieczeństwa.
Przygotowanie
Zakres, zgoda na testy, dostępy, konta testowe i staging. Bez tego nie zaczynamy.
Testy backendu
API, dane, uprawnienia, wydajność i kopie zapasowe.
Testy frontu
Osobno web, aplikacja okienkowa i aplikacja mobilna, zależnie od tego, co budujesz.
Integracja i bezpieczeństwo
Testy według OWASP ASVS poziom 2: automaty, potem ręczna weryfikacja każdego wyniku.
Testy akceptacyjne
Ty przechodzisz scenariusze na stagingu. Wynik trafia do protokołu.
Raport i retest
Raport ze znaleziskami, poprawki, ponowny test.
Decyzja o wdrożeniu
Zasada: produkt nie wychodzi z otwartym znaleziskiem krytycznym. Decyzję podejmujesz Ty.
Graf zależności: co musi istnieć, żeby zacząć
Każdy etap ma wejście. Jeśli brakuje któregoś elementu, etap czeka. Sprawdź kolumnę „Właściciel”: tyle spraw leży po Twojej stronie.
| Wymaganie | Blokuje etapy | Właściciel |
|---|---|---|
| DostępyRepozytorium, panel hostingu, panele administracyjne, konta w sklepach z aplikacjami. | Wszystkie etapy | Klient |
| Konta testowePo jednym koncie na każdą rolę użytkownika, z danymi, które wolno widzieć. | Testy backendu, Testy frontu, Testy akceptacyjne | Klient |
| Staging z danymi testowymiŚrodowisko oddzielone od produkcji. Nigdy produkcja z danymi klientów. | Wszystkie etapy | Klient |
| Zgoda na testyPisemna zgoda z oknem czasowym, zakresem i kontaktem awaryjnym. | Integracja i bezpieczeństwo | Wspólnie |
| Dokumentacja APISpecyfikacja OpenAPI lub opis endpointów z przykładami zapytań. | Testy backendu | Klient |
| Buildy mobilnePliki do instalacji na iOS i Androidzie, najlepiej przez TestFlight i kanał testowy. | Testy frontu | Klient |
| Certyfikaty i podpisyCertyfikaty podpisu aplikacji, profile provisioning, klucze podpisu. | Testy frontu | Klient |
Gałęzie szczegółowe
Dla każdej gałęzi określamy zakres, narzędzia oraz kryteria wejścia i wyjścia. Wchodzimy w gałąź dopiero po spełnieniu kryteriów wejścia.
Backend
Zakres
- API: kontrakt, kody błędów, limity
- Dane: spójność, migracje, walidacja
- Uprawnienia: role, izolacja danych między firmami
- Wydajność: obciążenie typowym ruchem
- Kopie zapasowe: istnieją i da się je odtworzyć
Narzędzia
- Bruno lub Postman
- k6
- OWASP ZAP lub Burp
- Test odtworzenia kopii na stagingu
Kryteria wejścia
- Staging działa z danymi testowymi
- Dokumentacja API lub lista endpointów
- Konta testowe dla każdej roli
Kryteria wyjścia
- Wszystkie endpointy sprawdzone
- Brak otwartych znalezisk krytycznych
- Odtworzenie kopii przetestowane i zmierzone
Web
Zakres
- Przeglądarki: aktualne Chrome, Firefox, Safari, Edge
- Dostępność według WCAG 2.2 AA
- Responsywność od telefonu do dużego ekranu
- Stany błędów: brak sieci, pusta lista, wygasła sesja
Narzędzia
- Playwright
- axe
- Lighthouse
- Czytnik ekranu i nawigacja klawiaturą
Kryteria wejścia
- Backend po testach
- Staging z aktualnym buildem
- Lista kluczowych ścieżek użytkownika
Kryteria wyjścia
- Kluczowe ścieżki przechodzą w każdej przeglądarce z zakresu
- Brak błędów dostępności poziomu krytycznego
- Stany błędów mają czytelny komunikat
Aplikacja okienkowa (desktop)
Zakres
- Instalacja i odinstalowanie
- Aktualizacje: automatyczne i ręczne
- Uprawnienia systemowe: pliki, sieć, powiadomienia
- Praca offline i powrót do online
Narzędzia
- Maszyny wirtualne z Windows i macOS
- Narzędzia systemowe do podglądu plików i ruchu sieciowego
- [NEED: stos aplikacji desktop, np. Electron, Tauri lub natywna]
Kryteria wejścia
- Instalator podpisany certyfikatem
- Dostęp do kanału aktualizacji
- Lista obsługiwanych wersji systemów
Kryteria wyjścia
- Instalacja i aktualizacja działają na każdej obsługiwanej wersji
- Aplikacja prosi tylko o potrzebne uprawnienia
- Praca offline nie gubi danych
Aplikacja mobilna
Zakres
- iOS i Android na prawdziwych urządzeniach
- Uprawnienia: aparat, lokalizacja, powiadomienia
- Pamięć, bateria i słaba sieć
- Wymogi sklepów App Store i Google Play
- Bezpieczeństwo według OWASP MASVS
Narzędzia
- TestFlight i wewnętrzny kanał testowy Google Play
- Xcode i Android Studio
- OWASP MASTG
- MobSF
Kryteria wejścia
- Build testowy na obu platformach
- Konta w sklepach i certyfikaty
- Backend po testach
Kryteria wyjścia
- Kluczowe ścieżki działają na urządzeniach z zakresu
- Dane wrażliwe są w keychain lub keystore
- Wymogi sklepów sprawdzone przed zgłoszeniem
Role: kto za co odpowiada
Matryca RACI dla każdego etapu. Dostarcza ten, kto przygotowuje wejście. Decyduje ten, kto odpowiada za wynik. Testuje ten, kto wykonuje testy. Podpisuje ten, kto potwierdza zakończenie etapu.
| Etap | Dostarcza | Decyduje | Testuje | Podpisuje |
|---|---|---|---|---|
| Przygotowanie | Klient | Wspólnie | Hindbrain | Klient |
| Testy backendu | Klient | Hindbrain | Hindbrain | Hindbrain |
| Testy frontu | Klient | Hindbrain | Hindbrain | Hindbrain |
| Integracja i bezpieczeństwo | Klient | Hindbrain | Hindbrain | Hindbrain |
| Testy akceptacyjne | Wspólnie | Klient | Klient | Klient |
| Raport i retest | Hindbrain | Klient | Hindbrain | Wspólnie |
| Decyzja o wdrożeniu | Hindbrain | Klient | Wspólnie | Klient |
Checklista interaktywna
Odhaczaj punkty w trakcie projektu. Stan zapisuje się tylko w tej przeglądarce. Każdy punkt ma właściciela: Klient, Hindbrain albo Wspólnie. Pełną listę wydrukujesz jako osobny dokument.
Postęp0 / 42
Dokumenty do pobrania
Pięć szablonów. Wydrukuj stronę lub wybierz „Zapisz jako PDF”. Pola z podkreśleniem uzupełnij odręcznie lub w edytorze.
Zgoda na testy (rules of engagement)
Pisemna zgoda klienta na testy bezpieczeństwa. Bez niej nie zaczynamy.
Strony
- Klient: ____
- Wykonawca: Hindbrain
- Osoba decyzyjna po stronie klienta: ____
Zakres
- Domeny i adresy: ____
- API i aplikacje mobilne: ____
- Środowisko testowe (nigdy produkcja z danymi klientów): ____
- Poza zakresem: ____
Zasady
- Okno czasowe testów: od ____ do ____
- Dozwolone: skanowanie, testy ręczne na koncie testowym
- Niedozwolone: ataki DoS, socjotechnika bez osobnej zgody
- Kontakt awaryjny (imię, telefon): ____
Podpisy
- Klient, data: ____
- Hindbrain, data: ____
Plan testów
Co, kiedy i kto testuje, oraz kiedy uznajemy etap za zakończony.
Cel i zakres
- Aplikacja i wersja: ____
- Gałęzie: backend, web, desktop, mobile (zaznacz wybrane)
- Standard bezpieczeństwa: OWASP ASVS poziom 2
Harmonogram
- Start: ____
- Testy backendu: ____
- Testy frontu: ____
- Testy bezpieczeństwa: ____
- Testy akceptacyjne: ____
- Retest: ____
Kryteria wejścia i wyjścia
- Wejście: dostępy, konta testowe, staging, zgoda na testy
- Wyjście: brak otwartych znalezisk krytycznych i wysokich
Ryzyka i założenia
- Ryzyka: ____
- Założenia: ____
Protokół testów akceptacyjnych
Potwierdzenie, że klient sprawdził uzgodnione scenariusze i zaakceptował wynik.
Dane
- Aplikacja i wersja: ____
- Środowisko: ____
- Data testów: ____
- Osoby testujące: ____
Scenariusze
- Scenariusz, oczekiwany wynik, wynik (zaliczony / niezaliczony), uwagi
- Scenariusz 1: ____
- Scenariusz 2: ____
- Scenariusz 3: ____
Decyzja
- Zaakceptowano bez uwag
- Zaakceptowano z uwagami do poprawy w terminie: ____
- Odrzucono, powód: ____
Podpisy
- Klient, data: ____
- Hindbrain, data: ____
Szablon raportu ze znaleziskami
Struktura raportu z audytu: streszczenie dla zarządu i opis każdego znaleziska.
Streszczenie dla zarządu
- Trzy zdania: co sprawdzono, ogólna ocena, najważniejsze ryzyko
- Liczba znalezisk per poziom: ____
Poziomy CVSS 3.1
- Krytyczny: 9.0 do 10.0
- Wysoki: 7.0 do 8.9
- Średni: 4.0 do 6.9
- Niski: 0.1 do 3.9
- Informacyjny: 0.0
Opis znaleziska
- Identyfikator i tytuł: ____
- Poziom i wynik CVSS: ____
- Opis i dowód: ____
- Wpływ biznesowy: ____
- Naprawa krok po kroku: ____
- Właściciel i termin: ____
- Status po retestie: naprawione / otwarte
Sprawdzone bez zastrzeżeń
- Lista obszarów, w których nie znaleziono problemów: ____
Lista dostępów do przekazania
Co klient przekazuje przed startem testów. Hasła przekazuj przez menedżer haseł, nie e-mailem.
Kod i infrastruktura
- Repozytorium (odczyt): ____
- Panel hostingu lub chmury (rola tylko do odczytu): ____
- DNS: ____
Środowisko testowe
- Adres stagingu: ____
- Konta testowe dla każdej roli: ____
- Dokumentacja API: ____
Aplikacje mobilne i desktop
- Dostęp do TestFlight i kanału testowego Google Play: ____
- Certyfikaty i profile podpisu: ____
- Instalatory i kanał aktualizacji: ____
Kontakt
- Osoba techniczna po stronie klienta: ____
- Kontakt awaryjny: ____