Analiza nowej Rekomendacji D pod kątem metodologii testowania

Analiza nowej Rekomendacji D
pod kątem metodologii testowania
Komisja Nadzoru Finansowego. Rekomendacja D., Rekomendacja 7., punkt 7.
Wersja 1.0

Wprowadzenie
 Nowa Rekomendacja D:
 dotyczy zarządzania obszarami technologii informacyjnej
i bezpieczeństwa środowiska teleinformatycznego w bankach
 ma zostać wprowadzona przez banki w Polsce do końca 2014 roku
 Rekomendacja D opisuje w rekomendacji 7 cykl życia
oprogramowania, a w punkcie 7. testowanie

Wprowadzenie
 Normy wskazane w Rekomendacji D:
 ISO/IEC 27000:2009 - Information technology - Security techniques -
Information security management systems
 Inne normy ISO (International Organization for Standardization)
 [opcja] ISO/IEC 25010:2011 Systems and software Quality Requirements
and Evaluation (SQuaRE)
 [opcja] ISO/IEC 12207:2008 Systems and software engineering – Software
life cycle processes
 [opcja] ISO/IEC 29119 Software Testing – w przygotowaniu

 Standardy wskazane w Rekomendacji D:
 Zarządzanie projektami proponowane przez PMI
(Project Management Institute)
 PMBoK (Project Management Body of Knowledge)
 PRINCE2 (PRojects IN Controlled Environments).
 Audyty:
 ISACA (Information Systems Audit and Control Association)
 COBIT (Control Objectives for Information and related Technology)
 GTAG (Global Technology Audit Guide)
 GAIT (Guide to the Assessment for IT Risk)
Wprowadzenie

Cykl życia oprogramowania
 Rekomendacja D opisuje cykl życia oprogramowania wyróżniając
podstawowe kroki:
 Strategia banku (7.1)
 Szczegółowe wymagania (7.2)
 Projektowanie (7.3)
 Analiza ryzyk (7.4)
 Rozwój oprogramowania
– wewnętrzny (7.5)
 Rozwój oprogramowania
– zewnętrzny (7.6)
 Testowanie (7.7)
 Wdrożenie (7.8)
 Wycofanie (7.15)

 Rekomendacja D uwzględnia również dodatkowe działania:
 Zarządzanie środowiskami (7.9)
 Dokumentacja (7.10)
 Zarządzanie zmianą (7.11, 7.12, 7.13, 7.14)

- wizualizacja
Strategia banku
(7.1)
Szczegółowe
wymagania
(7.2)
Projektowanie
(7.3)
Analiza ryzyk
(7.4)
Rozwój
oprogramowania -
wewnętrzny
(7.5)
Rozwój
oprogramowania -
zewnętrzny
(7.6)
Wdrożenie
(7.8)
Wycofanie
(7.15)
Zarządzanie środowiskami (7.9)
Dokumentacja (7.10)
Zarządzanie zmianą (7.11, 7.12, 7.13, 7.14)
Testowanie
(7.7)

- Strategia banku (7.1)
 Zakłada się w rekomendacji rozwój systemu zgodny ze strategią
banku w zakresie obszarów technologii informacyjnej
i bezpieczeństwa środowiska teleinformatycznego

- Szczegółowe wymagania (7.2)
 Dokument wskazuje na ważny element zapewnienia jakości
oprogramowania, zaczynający się od zapewnienia jakości wymagań
 Szczególnie dla projektów wytwarzanych zewnętrznie, wykrywanie
problemów wymagań (np. niejasności) na etapie (dopiero)
testowania może być kosztowne dla całej organizacji
 Reguła 1:10:100

 Rekomendacja nakazuje uwzględnić w wymaganiach:
 funkcjonalność
 pojemność
 połączenia z innymi systemami
 wydajność i dostępność
 środowisko działania
 bezpieczeństwo
 zgodność z przepisami i standardami

 Niskiej jakości wymagania to w konsekwencji:
 Niskiej jakości kod,
 Niskiej jakości scenariusze testowe,
 Niskiej jakości automaty testowe,
 Niskiej jakości oprogramowanie,
 Obniżony poziom bezpieczeństwa systemu,
 Wydłużony czas realizacji projektu,
 Wyższe koszty prowadzenia projektu.

- Projektowanie (7.3)
 Projektowanie systemu z uwzględnieniem modyfikacji w
przyszłości (elastyczność), wynikających ze:
 Zmiany prawa,
 Strategii banku,
 Standardów w banku,
 Zmiany w otoczeniu i działania konkurencji banku.

- Analiza ryzyka (7.4)
 Przeprowadzenie analizy ryzyka przed wdrożeniem nowego
systemu jak i przy każdej znaczącej zmianie
 Ocena wpływu zmiany na:
 Środowisko teleinformatyczne
 Procesy biznesowe
 „… ze szczególnym uwzględnieniem aspektów bezpieczeństwa”

- Rozwój oprogramowania - wewnętrzny (7.5)
 Rekomendowane jest posiadanie (dobra praktyka) (1/2):
 Metodyki rozwoju oprogramowania (opisującej proces)
 Zarządzanie zmianą w systemie informatycznym z uwzględnieniem
wielkości danej zmiany (zmiana jako: cały projekt, zmiana w
produkcie, poprawka),
 Zarządzanie incydentami (pochodzącymi z produkcji, pochodzącymi
ze środowisk testowych),
 Zarządzanie środowiskami testowymi,
 Zarządzanie dokumentacją testową,
 Miary.

 Rekomendowane jest posiadanie (dobra praktyka) (2/2):
 Standardów w rozwoju oprogramowania
 Architektura,
 Narzędzia programistyczne,
 Repozytoria,
 Standardy kodowania (preferowane języki) w tym zapewnienie
jakości poprzez dbałość o notację i komentowanie kodu,
 Zasady wykonywania testów i przeglądów kodu,
 Kryteria jakości kodu,
 Standard tworzenia dokumentacji,
 Zasady wersjonowania oprogramowania.

 Rekomendacja wskazuje na konieczność wykonywania bieżących
testów i przeglądów kodu, zapewniających odpowiedni
stopień niezależności w przypadku rozwoju oprogramowania
realizowanego siłami własnymi.

- Rozwój oprogramowania - zewnętrzny (7.6)
 Korzystanie z usług wiarygodnych partnerów
 Uwzględnienie w umowie stosowania przez dostawcę standardów i
metodyk rozwoju oprogramowania przyjętych w banku
 Wykonywanie testów przed wdrożeniem
 Przez dostawcę
 Przeprowadzenie testów w banku (bez względu na testy dostawcy)
 Dokładny opis "Współpraca z zewnętrznymi dostawcami usług" znajduje się w rekomendacji 10

- Testowanie (7.7)
 Rekomendacja D zakłada zdefiniowanie przez organizację
metodologii testowania.
 Opis metodologii od strony 22

- Wdrożenie (7.8)
 Zgodnie z rekomendacją D bank powinien zapewnić, aby procedury
przenoszenia nowego systemu informatycznego lub zmiany już
funkcjonującego systemu na środowisko produkcyjne
minimalizowały ryzyko wystąpienia przestojów w działalności
banku.
 Wskazana jest konieczność:
 zweryfikowania poprawności działania systemu i zgodności z
wymaganiami,
 monitorowania systemu (przez odpowiedni czas ) w celu identyfikacji
ewentualnych problemów.

- Wdrożenie (7.8)
 Bank powinien podjąć decyzję dotyczącą zapewnienia
mechanizmów umożliwiających powrót do stanu sprzed wdrożenia
w przypadku wystąpienia sytuacji krytycznej
 Np. tworzenie kopii awaryjnych odpowiedniego obszaru środowiska
teleinformatycznego

- Wycofanie (7.15)
 Rekomenduje się posiadanie sformalizowanych regulacji w zakresie
wycofywania z eksploatacji rozwiązań informatycznych
uwzględniających:
 podejmowanie decyzji,
 informowanie zainteresowanych stron,
 przeprowadzanie migracji danych,
 dokonywanie archiwizacji rozwiązań,
 aktualizację konfiguracji infrastruktury,
 bezpieczną eliminację wycofywanych z użytku komponentów
 aktualizację dokumentacji środowiska teleinformatycznego banku.

Metodologia testowania
 Prezentowana metodologia testowania jest zgodna
z rekomendacją D
 Poprzez „metodologię testowania” rozumie się „metodologię
testowania środowiska teleinformatycznego” czyli testowania
systemu i infrastruktury
 Metodologia uwzględnia wspomniane w rekomendacji „dobre
praktyki” testowania, takie jak planowanie i testowanie atrybutów
jakościowych oprogramowania

 Rekomendacja D w punkcie 5.2 zwraca uwagę na odpowiednią
separację obowiązków:
 w szczególności oddzielenie funkcji tworzenia lub modyfikowania
systemów informatycznych od ich testowania (poza testami
realizowanymi przez programistów w ramach wytwarzania
oprogramowania), administracji i użytkowania.
 sposób organizacji testów powinien zapewniać możliwie wysoki
stopień niezależności weryfikacji spełnienia przyjętych założeń

Uruchomienie testów
…
Planowanie
Zarządzanie środowiskiem
Dane testowe
Scenariusze testowe
Outsourcing testowy
Funkcjonalność
Bezpieczeństwo
Wydajność
Dostępność
Raportowanie
Zgodność z
miarami jakości
oprogramowania

Metodologia testowania (1/4)
 [opcja] Planowanie
 Strategia testowania (dobór lub definicja)
 Zdefiniowanie miar jakości oprogramowania
 Kryterium odbioru oprogramowania

 Wytworzenie scenariuszy i danych w oparciu o wymagania
 Wymagania dostępne – tworzenie scenariuszy z uwzględnieniem:
 [opcja] Testowalność
 [opcja] Śledzenie wymagań (ang. Traceability)
 [opcja] Automatyzacja
 Brak wymagań lub wymagania niskiej jakości – tworzenie scenariuszy:
 przy wsparciu przedstawicieli obszaru bezpieczeństwa środowiska IT
 i/lub przy wykorzystaniu wiedzy eksperckiej

 Uruchomienie testów
 Poziomy testów
 [opcja] Testowanie jednostkowe
 [opcja] Testowanie integracji modułów
 Testowanie systemu
 Testowanie integracyjne z innymi systemami
 Rodzaje testów
 Testowanie
regresywne
 [opcja] Testowanie
potwierdzające
 Typy testów: funkcje i charakterystyki
oprogramowania
 Funkcjonalne
 Bezpieczeństwo
 Wydajność
 Dostępność
 [opcja] Użyteczność
 [opcja] Inne

 Zarządzanie środowiskami
 w kontekście konfiguracji,
 w kontekście wersjonowania,
 w kontekście zasad wdrażania zmian (np. nowych wersji),
 w kontekście zarządzania danymi (np. ilość danych, problem danych
rzeczywistych).
 Raportowanie
 [opcja] Raport z testów - > miary jakości oprogramowania
 Zgłaszanie błędów

- Planowanie
strategia banku,
wymagania,
wymagania
biznesowe, plan
projektu
Planowanie Plan testów

- Planowanie
 Wejście: strategia banku, wymagania, wymagania biznesowe,
plan projektu
 Wyjście: plan testów
 Działania:
 wytworzenie planu testów
 dopasowanie planowania do strategii banku (7.1)
 adaptacja do istniejącej, lub zdefiniowanie nowej strategii testów
 estymacja czasu i budżetu
 z uwzględnieniem czasu potrzebnego na usunięcie wykrytych defektów
 określenie lub uwzględnienie miar jakości oprogramowania

- Wytworzenie scenariuszy i danych w oparciu o wymagania
plan testów,
wymagania
Wytworzenie scenariuszy i
danych w oparciu o
wymagania
Scenariusze
testowe i dane
testowe

- Wytworzenie scenariuszy i danych w oparciu o wymagania
 Wejście: plan testów, wymagania funkcjonalne
 Wyjście: scenariusze testowe i dane testowe
 Działania:
 wytworzenie scenariuszy testowych
 wytworzenie danych testowych

- Zarządzanie środowiskiem
plan testów,
scenariusze testowe i
dane testowe,
konfiguracja, zasoby
sprzętowe,
zdefiniowany poziom
integracji
oprogramowania
Zarządzanie środowiskiem
Środowisko
testowe

- Zarządzanie środowiskiem
 Wejście: plan testów, scenariusze testowe i dane testowe,
konfiguracja, zasoby sprzętowe, zdefiniowany poziom integracji
oprogramowania
 Wyjście: środowisko testowe
 Działania:
 Przygotowanie środowiska testowego odseparowanego od środowiska
programistycznego i produkcyjnego

- Uruchomienie testów
plan testów,
środowisko
testowe,
oprogramowanie,
scenariusze
testowe i dane
testowe
Uruchomienie testów Wyniki testów

 Wejście: plan testów, środowisko testowe, oprogramowanie,
scenariusze testowe i dane testowe
 Wyjście: wyniki testów
 Działania:
 Wykonanie testów funkcjonalności
 Wykonanie testów bezpieczeństwa
 Wykonanie testów wydajności
 Wykonanie testów dostępności
 [opcja] Wykonanie testów użyteczności
 Wykonanie innych testów

 Rekomendacja: Udział docelowych odbiorców aplikacji w testach
funkcjonalnych i niefunkcjonalnych (tam gdzie możliwe)
 [opcja] Przy braku wymagań może nie być możliwości wytworzenia
scenariuszy. W takim wypadku kompensuje się brak specyfikacji
testowej poprzez testy eksploracyjne, bazujących na intuicji,
wiedzy eksperckiej oraz doświadczeniu testerów

- Raportowanie
plan testów,
wymagania
funkcjonalne,
wymagania
biznesowe, wyniki
testów
Raportowanie Raport z testów

- Raportowanie
 Wejście: plan testów, wymagania, wyniki testów
 Wyjście: raport jakości, raporty błędów
 Działania:
 Analiza wyników testów i wymagań
 Raportowanie jakości oprogramowania w wielu wymiarach
 Przygotowanie raportu z testów w oparciu o zdefiniowane miary

- Raportowanie
 Ograniczenia:
 jakość raportowania ograniczona możliwościami wdrożonych narzędzi
raportowania błędów
 system zgłaszania błędów gwarantujący zapisanie wszystkich
incydentów
 precyzyjne (jednoznaczne) raportowanie błędów
 poufność informacji o błędach (szczególnie błędów bezpieczeństwa)

Testowanie w Rekomendacji D
 Testowanie dodatkowo opisane jest w następujących ustępach
Rekomendacji D:
 5.2 - izolacja procesu programowania od procesu testowania
 7.9 - separacja środowisk
 9.21 - testy penetracyjne infrastruktury teleinformatycznej
 9.24 - aktualizacje środowisk produkcyjnych

Podsumowanie
 Dokument prezentuje aspekt testowania zaprezentowany w
Rekomendacji D opublikowanej przez Komisję Nadzoru Bankowego
 Dokument proponuje wymaganą przez KNF metodologię testowania

DODATEK
– fragment listy kontrolnej dla nowej Rekomendacji 7
Pytanie TAK NIE *
Czy organizacja dba o ważny element cyklu życia oprogramowania
czyli o wysokiej jakości wymagania?
Czy organizacja posiada metodykę rozwoju oprogramowania?
Czy organizacja ma zdefiniowaną metodologię testowania?
Czy organizacja testuje oprogramowanie zarówno wytwarzane wewnętrznie
jak i dostarczane przez zewnętrznych dostawców w sposób gwarantujący
niezależność weryfikacji jakości?
Czy testy obejmują weryfikację wszystkich wymagań, w szczególności
dotyczących: funkcjonalności, wydajności, bezpieczeństwa
Czy zakres definiowanych wymagań obejmuje wszystkie
zakresy wymienione w punkcie 7.2 nowej Rekomendacji D?
…
*) każda odpowiedź NIE może sugerować konieczność wprowadzenia zmian
w organizacji pod kątem dopasowania się do Rekomendacji D.

Autorzy
 Radosław Smilgin, 21CN (testerzy.pl)
 definiowanie metodologii (procesów) testowania
 Radoslaw.Smilgin@testerzy.pl
 Wojciech Dworakowski, SecuRing
 audyt i testowanie bezpieczeństwa systemów teleinformatycznych
 Wojciech.Dworakowski@securing.pl
 Tomasz Watras, PGS Software S.A.
 outsourcing wytwarzania i testowania
 TWatras@pgs-soft.com

Analiza nowej Rekomendacji D pod kątem metodologii testowania

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Similaire à Analiza nowej Rekomendacji D pod kątem metodologii testowania

Similaire à Analiza nowej Rekomendacji D pod kątem metodologii testowania (20)

Analiza nowej Rekomendacji D pod kątem metodologii testowania