Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Analiza nowej Rekomendacji D pod kątem metodologii testowania

9,795 views

Published on

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.

Published in: Business
  • Be the first to comment

Analiza nowej Rekomendacji D pod kątem metodologii testowania

  1. 1. Analiza nowej Rekomendacji Dpod kątem metodologii testowaniaKomisja Nadzoru Finansowego. Rekomendacja D., Rekomendacja 7., punkt 7.Wersja 1.0
  2. 2. Wprowadzenie Nowa Rekomendacja D: dotyczy zarządzania obszarami technologii informacyjneji 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 życiaoprogramowania, a w punkcie 7. testowanie
  3. 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 Requirementsand Evaluation (SQuaRE) [opcja] ISO/IEC 12207:2008 Systems and software engineering – Softwarelife cycle processes [opcja] ISO/IEC 29119 Software Testing – w przygotowaniu
  4. 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. 5. Cykl życia oprogramowania Rekomendacja D opisuje cykl życia oprogramowania wyróżniającpodstawowe 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. 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)
  7. 7. Cykl życia oprogramowania- wizualizacjaStrategia banku(7.1)Szczegółowewymagania(7.2)Projektowanie(7.3)Analiza ryzyk(7.4)Rozwójoprogramowania -wewnętrzny(7.5)Rozwójoprogramowania -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)
  8. 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 informacyjneji bezpieczeństwa środowiska teleinformatycznego
  9. 9. Cykl życia oprogramowania- Szczegółowe wymagania (7.2) Dokument wskazuje na ważny element zapewnienia jakościoprogramowania, zaczynający się od zapewnienia jakości wymagań Szczególnie dla projektów wytwarzanych zewnętrznie, wykrywanieproblemów wymagań (np. niejasności) na etapie (dopiero)testowania może być kosztowne dla całej organizacji Reguła 1:10:100
  10. 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. 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. 12. Cykl życia oprogramowania- Projektowanie (7.3) Projektowanie systemu z uwzględnieniem modyfikacji wprzyszłości (elastyczność), wynikających ze: Zmiany prawa, Strategii banku, Standardów w banku, Zmiany w otoczeniu i działania konkurencji banku.
  13. 13. Cykl życia oprogramowania- Analiza ryzyka (7.4) Przeprowadzenie analizy ryzyka przed wdrożeniem nowegosystemu 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. 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ędnieniemwielkości danej zmiany (zmiana jako: cały projekt, zmiana wprodukcie, poprawka), Zarządzanie incydentami (pochodzącymi z produkcji, pochodzącymize środowisk testowych), Zarządzanie środowiskami testowymi, Zarządzanie dokumentacją testową, Miary.
  15. 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 zapewnieniejakoś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. 16. Cykl życia oprogramowania- Rozwój oprogramowania - wewnętrzny (7.5) Rekomendacja wskazuje na konieczność wykonywania bieżącychtestów i przeglądów kodu, zapewniających odpowiednistopień niezależności w przypadku rozwoju oprogramowaniarealizowanego siłami własnymi.
  17. 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 imetodyk 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. 18. Cykl życia oprogramowania- Testowanie (7.7) Rekomendacja D zakłada zdefiniowanie przez organizacjęmetodologii testowania. Opis metodologii od strony 22
  19. 19. Cykl życia oprogramowania- Wdrożenie (7.8) Zgodnie z rekomendacją D bank powinien zapewnić, aby proceduryprzenoszenia nowego systemu informatycznego lub zmiany jużfunkcjonującego systemu na środowisko produkcyjneminimalizowały ryzyko wystąpienia przestojów w działalnościbanku. Wskazana jest konieczność: zweryfikowania poprawności działania systemu i zgodności zwymaganiami, monitorowania systemu (przez odpowiedni czas ) w celu identyfikacjiewentualnych problemów.
  20. 20. Cykl życia oprogramowania- Wdrożenie (7.8) Bank powinien podjąć decyzję dotyczącą zapewnieniamechanizmów umożliwiających powrót do stanu sprzed wdrożeniaw przypadku wystąpienia sytuacji krytycznej Np. tworzenie kopii awaryjnych odpowiedniego obszaru środowiskateleinformatycznego
  21. 21. Cykl życia oprogramowania- Wycofanie (7.15) Rekomenduje się posiadanie sformalizowanych regulacji w zakresiewycofywania z eksploatacji rozwiązań informatycznychuwzglę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.
  22. 22. Metodologia testowania
  23. 23. Metodologia testowania Prezentowana metodologia testowania jest zgodnaz rekomendacją D Poprzez „metodologię testowania” rozumie się „metodologiętestowania środowiska teleinformatycznego” czyli testowaniasystemu i infrastruktury Metodologia uwzględnia wspomniane w rekomendacji „dobrepraktyki” testowania, takie jak planowanie i testowanie atrybutówjakościowych oprogramowania
  24. 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 modyfikowaniasystemów informatycznych od ich testowania (poza testamirealizowanymi przez programistów w ramach wytwarzaniaoprogramowania), administracji i użytkowania. sposób organizacji testów powinien zapewniać możliwie wysokistopień niezależności weryfikacji spełnienia przyjętych założeń
  25. 25. Uruchomienie testówMetodologia testowania…PlanowanieZarządzanie środowiskiemDane testoweScenariusze testoweOutsourcing testowyFunkcjonalnośćBezpieczeństwoWydajnośćDostępnośćRaportowanieZgodność zmiarami jakościoprogramowania
  26. 26. Metodologia testowania (1/4) [opcja] Planowanie Strategia testowania (dobór lub definicja) Zdefiniowanie miar jakości oprogramowania Kryterium odbioru oprogramowania
  27. 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. 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 Testowanieregresywne [opcja] Testowaniepotwierdzające Typy testów: funkcje i charakterystykioprogramowania Funkcjonalne Bezpieczeństwo Wydajność Dostępność [opcja] Użyteczność [opcja] Inne
  29. 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 danychrzeczywistych). Raportowanie [opcja] Raport z testów - > miary jakości oprogramowania Zgłaszanie błędów
  30. 30. Metodologia testowania- Planowaniestrategia banku,wymagania,wymaganiabiznesowe, planprojektuPlanowanie Plan testów
  31. 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. 32. Metodologia testowania- Wytworzenie scenariuszy i danych w oparciu o wymaganiaplan testów,wymaganiaWytworzenie scenariuszy idanych w oparciu owymaganiaScenariuszetestowe i danetestowe
  33. 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. 34. Metodologia testowania- Zarządzanie środowiskiemplan testów,scenariusze testowe idane testowe,konfiguracja, zasobysprzętowe,zdefiniowany poziomintegracjioprogramowaniaZarządzanie środowiskiemŚrodowiskotestowe
  35. 35. Metodologia testowania- Zarządzanie środowiskiem Wejście: plan testów, scenariusze testowe i dane testowe,konfiguracja, zasoby sprzętowe, zdefiniowany poziom integracjioprogramowania Wyjście: środowisko testowe Działania: Przygotowanie środowiska testowego odseparowanego od środowiskaprogramistycznego i produkcyjnego
  36. 36. Metodologia testowania- Uruchomienie testówplan testów,środowiskotestowe,oprogramowanie,scenariuszetestowe i danetestoweUruchomienie testów Wyniki testów
  37. 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. 38. Metodologia testowania- Uruchomienie testów Rekomendacja: Udział docelowych odbiorców aplikacji w testachfunkcjonalnych i niefunkcjonalnych (tam gdzie możliwe) [opcja] Przy braku wymagań może nie być możliwości wytworzeniascenariuszy. W takim wypadku kompensuje się brak specyfikacjitestowej poprzez testy eksploracyjne, bazujących na intuicji,wiedzy eksperckiej oraz doświadczeniu testerów
  39. 39. Metodologia testowania- Raportowanieplan testów,wymaganiafunkcjonalne,wymaganiabiznesowe, wynikitestówRaportowanie Raport z testów
  40. 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. 41. Metodologia testowania- Raportowanie Ograniczenia: jakość raportowania ograniczona możliwościami wdrożonych narzędziraportowania błędów system zgłaszania błędów gwarantujący zapisanie wszystkichincydentów precyzyjne (jednoznaczne) raportowanie błędów poufność informacji o błędach (szczególnie błędów bezpieczeństwa)
  42. 42. Testowanie w Rekomendacji D Testowanie dodatkowo opisane jest w następujących ustępachRekomendacji 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. 43. Podsumowanie Dokument prezentuje aspekt testowania zaprezentowany wRekomendacji D opublikowanej przez Komisję Nadzoru Bankowego Dokument proponuje wymaganą przez KNF metodologię testowania
  44. 44. DODATEK– fragment listy kontrolnej dla nowej Rekomendacji 7Pytanie TAK NIE *Czy organizacja dba o ważny element cyklu życia oprogramowaniaczyli 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ętrzniejak i dostarczane przez zewnętrznych dostawców w sposób gwarantującyniezależność weryfikacji jakości?Czy testy obejmują weryfikację wszystkich wymagań, w szczególnościdotyczących: funkcjonalności, wydajności, bezpieczeństwaCzy zakres definiowanych wymagań obejmuje wszystkiezakresy wymienione w punkcie 7.2 nowej Rekomendacji D?…*) każda odpowiedź NIE może sugerować konieczność wprowadzenia zmianw organizacji pod kątem dopasowania się do Rekomendacji D.
  45. 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

×