Zasada naczyń połączonych, czyli jak testować aby nie zwariować, cz. 1/2

Okazuje się, że niektóre tematy stanowią dość żywy organizm, który co jakiś czas przypomina o swoim istnieniu. Jednym z nich jest np. kwestia testowania oprogramowania, kto i dlaczego powinien się tym zajmować oraz w jakich warunkach powinno się testować oprogramowanie.

Generalnie problem z tym zagadnieniem ma swoje źródło w czymś, co można nazwać procesowym kołem zamachowym, które swój początek bierze w znajomości własnego środowiska (ocena kluczowości i krytyczności elementów składowych), a koniec
w ocenie ryzyka. Po drodze nie bez znaczenia pojawia się trzeci składnik układanki, jakim jest proces zarządzania zmianami i/lub rozwój oprogramowania.

„Wprowadzenie nowego systemu informatycznego, jak również znacznej zmiany do już istniejącego systemu, powinno być poprzedzone przeprowadzeniem analizy ryzyka wynikającego z zastosowanych technologii informatycznych oraz dokonaniem oceny wpływu wprowadzanych zmian na środowisko teleinformatyczne i procesy biznesowe banku, ze szczególnym uwzględnieniem aspektów bezpieczeństwa. (…) 

Zarówno nowe oprogramowanie, jak i zmiany wprowadzane do już funkcjonujących rozwiązań informatycznych, powinny być testowane adekwatnie do swojej złożoności oraz wpływu na pozostałe elementy środowiska teleinformatycznego banku. Bank powinien posiadać metodologię testowania oprogramowania (…)” tyle Rekomendacja D…

A co Wy o tym sądzicie? Jakie są Wasze doświadczenia?

Za tydzień kolejna część opowieści o „naczyniach połączonych”.

Jacek Rembikowski, E-QSM