Dokument przedstawiający wymagania w zakresie testów oprogramowania, zgodnych z opublikowaną przez KNF "Rekomendacją D" dotyczącą zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w bankach.
Analiza nowej Rekomendacji D pod kątem metodologii testowania
1. Analiza nowej Rekomendacji D
pod kątem metodologii testowania
Komisja Nadzoru Finansowego. Rekomendacja D., Rekomendacja 7., punkt 7.
Wersja 1.0
2. 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
3. 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
4. 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
5. 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)
6. 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)
8. 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
9. 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
10. Cykl życia oprogramowania
- Szczegółowe wymagania (7.2)
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
11. Cykl życia oprogramowania
- Szczegółowe wymagania (7.2)
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.
12. 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.
13. 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”
14. 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.
15. 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.
16. 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.
17. 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
18. Cykl życia oprogramowania
- Testowanie (7.7)
Rekomendacja D zakłada zdefiniowanie przez organizację
metodologii testowania.
Opis metodologii od strony 22
19. 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.
20. 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
21. 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.
23. 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
24. Metodologia testowania
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ń
27. Metodologia testowania (2/4)
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
28. Metodologia testowania (3/4)
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
29. Metodologia testowania (4/4)
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
31. 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
32. 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
33. 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
34. 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
35. 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
36. Metodologia testowania
- Uruchomienie testów
plan testów,
środowisko
testowe,
oprogramowanie,
scenariusze
testowe i dane
testowe
Uruchomienie testów Wyniki testów
37. Metodologia testowania
- Uruchomienie 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
38. Metodologia testowania
- Uruchomienie 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
40. Metodologia testowania
- 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
41. Metodologia testowania
- 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)
42. 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
43. Podsumowanie
Dokument prezentuje aspekt testowania zaprezentowany w
Rekomendacji D opublikowanej przez Komisję Nadzoru Bankowego
Dokument proponuje wymaganą przez KNF metodologię testowania
44. 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.
45. 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