Redakcja
Po wdrożeniu w środowisku produkcyjnym oprogramowanie lub system wymaga dalszego utrzymania. Różnego rodzaju zmiany - związane na przykład z usuwaniem defektów wykrytych podczas używania produkcyjnego, dodaniem nowej funkcjonalności bądź usuwaniem lub modyfikowaniem funkcjonalności już istniejącej - są praktycznie nieuniknione. Ponadto utrzymanie jest niezbędne do utrzymania lub poprawy wymaganych niefunkcjonalnych charakterystyk jakościowych oprogramowania lub systemu przez cały cykl jego życia - zwłaszcza w zakresie wydajności, kompatybilności, niezawodności, bezpieczeństwa i przenaszalności.
Po dokonaniu każdej zmiany w fazie utrzymania, należy wykonać testowanie utrzymaniowe, którego celem jest zarówno sprawdzenie, czy zmiana została wprowadzona pomyślnie, jak i wykrycie ewentualnych skutków ubocznych (np. regresji) w niezmienionych częściach systemu (czyli zwykle w większości jego obszarów). W związku z tym testowanie utrzymaniowe obejmuje zarówno te części systemu, które zostały zmienione, jak i części niezmienione, na które zmiany mogły mieć wpływ. Utrzymanie może być wykonywana zarówno planowo (w związku z nowymi wersjami), jak i w sposób niezaplanowany (w związku z poprawkami doraźnymi ang. hotfix). Wydanie w czasie utrzymania może wymagać wykonania testów na wielu poziomach testów i z wykorzystaniem różnych typów testów - zależnie od zakresu wprowadzonych zmian. Na zakres testowania w utrzymaniu wpływają między innymi:
- poziom ryzyka związanego ze zmianą (np. stopień, w jakim zmieniony obszar oprogramowania komunikuje się z innymi modułami lub systemami);
- wielkość dotychczasowego systemu;
- wielkość wprowadzonej zmiany.
Istnieje kilka powodów, dla których utrzymuje się oprogramowania, a tym samym testuje. Dotyczy to zarówno zmian planowanych, jak i nieplanowanych. Zdarzenia wywołujące czynności utrzymaniowe można podzielić na następujące kategorie:
- Modyfikacja. Ta kategoria obejmuje między innymi zaplanowane udoskonalenia (np. w postaci nowych wersji oprogramowania), zmiany korekcyjne i awaryjne, zmiany środowiska operacyjnego (np. planowe uaktualnienia systemu operacyjnego lub bazy danych), uaktualnienia oprogramowania do powszechnej sprzedaży (COTS) oraz poprawki usuwające defekty i podatności zabezpieczeń;
- Migracja. Ta kategoria obejmuje między innymi przejście z jednej platformy na inną, co może wiązać się z koniecznością przeprowadzenia testów produkcyjnych nowego środowiska i zmienionego oprogramowania bądź testów konwersji danych (w przypadku migracji danych z innej aplikacji do utrzymywanego systemu);
- Wycofanie. Ta kategoria dotyczy sytuacji, w której aplikacja jest wycofywana z użytku.
Kiedy aplikacja lub system jest wycofywany, może to wymagać testowania migracji lub archiwizacji danych, jeśli zachodzi potrzeba ich przechowywania przez dłuższy czas. Testowanie procedur odzyskiwania/pozyskiwania po archiwizacji przez dłuższy czas może także być konieczne. Dodatkowo konieczne może być uwzględnienie testów regresji, aby zapewnić dalszą prawidłową pracę funkcjonalności pozostających w użyciu.
W przypadku systemów związanych z Internetem rzeczy testowanie w utrzymaniu może być konieczne po wprowadzeniu w systemie zupełnie nowych lub zmodyfikowanych elementów, takich jak urządzenia sprzętowe czy usługi programowe. Podczas testowania utrzymaniowego takich systemów szczególny nacisk kładzie się na testowanie integracyjne na różnych poziomach (np. na poziomie sieci i aplikacji) oraz na aspekty związane z zabezpieczeniami, szczególnie w zakresie danych osobowych.
Analiza wpływu pozwala ocenić zmiany wprowadzone w utrzymywanej wersji pod kątem zarówno skutków zamierzonych, jak i spodziewanych lub potencjalnych skutków ubocznych, a także umożliwia zidentyfikowanie obszarów systemu, na które będą miały wpływ wprowadzone zmiany. Ponadto może pomóc w zidentyfikowaniu wpływu zmiany na dotychczasowe testy. Skutki uboczne zmiany oraz obszary systemu, na które może ona wpływać należy przetestować pod kątem regresji, przy czym czynność ta może być poprzedzona aktualizacją istniejących testów, na które oddziałuje dana zmiana.
Analizę wpływu można przeprowadzić przed dokonaniem zmiany, aby ustalić, czy zmianę tę należy faktycznie wprowadzić (z uwagi na potencjalne konsekwencje dla innych obszarów systemu).
Przeprowadzenie analizy wpływu może być utrudnione, jeśli:
- specyfikacje (np. wymagania biznesowe, historyjki użytkownika, architektura) są nieaktualne lub niedostępne;
- przypadki testowe nie zostały udokumentowane lub są nieaktualne;
- nie stworzono możliwości dwukierunkowego śledzenia powiązań między testami a podstawą testów;
- wsparcie narzędziowe nie istnieje lub jest niewystarczające;
- zaangażowane osoby nie dysponują wiedzą z danej dziedziny i/lub na temat danego systemu;
- zaangażowane osoby nie dysponują wiedzą z danej dziedziny i/lub na temat danego systemu;
- podczas wytwarzania oprogramowania poświęcono zbyt mało uwagi jego charakterystyce jakościowej w zakresie utrzymywalności.
Tekst (prawie) w całości pochodzi z sylabusa ISTQB. Zostały z niego usunięte nagłówki, a słowo "pielęgnacja" zastąpione popularniejszym "utrzymanie". Choć jako źródło wiedzy sylabus może być postrzegany jako zbyt "ciężki" i "toporny", w małych dawkach jest to bardzo wartościowe kompendium wiedzy.
Całość można pobrać ze strony.
