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)


– zewnętrzny (7.6)

Testowanie (7.7)

Wdrożenie (7.8)

Wycofanie (7.15)

Cykl życia oprogramowania

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)

Cykl życia oprogramowania - wizualizacja

Strategia banku(7.1)

Szczegółowe wymagania

(7.2)

Projektowanie(7.3)

Analiza ryzyk(7.4)


- wewnętrzny(7.5)


- 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)

Cykl życia oprogramowania - 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

Cykl życia oprogramowania - 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.

Cykl życia oprogramowania - 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.

Cykl życia oprogramowania - 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”

Cykl życia oprogramowania - 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.

Cykl życia oprogramowania- Rozwój oprogramowania - wewnętrzny (7.5)

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.

Cykl życia oprogramowania - Rozwój oprogramowania - wewnętrzny (7.5)

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.

Cykl życia oprogramowania - 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

Cykl życia oprogramowania - Testowanie (7.7)

Rekomendacja D zakłada zdefiniowanie przez organizację

metodologii testowania.

Opis metodologii od strony 22

Cykl życia oprogramowania - 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.

Cykl życia oprogramowania - 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

Cykl życia oprogramowania- 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

Metodologia testowania - Planowanie

strategia banku, wymagania, wymagania biznesowe, plan projektu

Planowanie Plan testów

Metodologia testowania - 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

Metodologia testowania - 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

Metodologia testowania - 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

Metodologia testowania - Zarządzanie środowiskiem

plan testów, scenariusze testowe i dane testowe, konfiguracja, zasoby sprzętowe, zdefiniowany poziom integracji oprogramowania

Zarządzanie środowiskiem

Środowisko testowe

Metodologia testowania - 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

Metodologia testowania - 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

Metodologia testowania - Raportowanie

plan testów, wymagania funkcjonalne, wymagania biznesowe, wyniki testów

Raportowanie Raport z testów


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


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 [email protected]

Wojciech Dworakowski, SecuRing audyt i testowanie bezpieczeństwa systemów

teleinformatycznych [email protected]

Tomasz Watras, PGS Software S.A. outsourcing wytwarzania i testowania [email protected]

mailto:[email protected]



Business

Analiza nowej Rekomendacji D pod kątem metodologii testowania