Słowo wyjaśnienia pojęć dla zielonych i nowych w branży.
Kiedy ludzie wpadają na genialny pomysł wykonania nowej aplikacji, zazwyczaj mają w głowie jakiś jej kształt – zakres funkcjonowania, który można uznać na minimalną, pierwszą, podstawową wersję. Taką minimalną wersję można już wypuścić na świat i zacząć używać w celach, w jakich powstała.
Kiedy system do zakupu produktów, utrzymywania relacji z klientami, śledzenia stanów magazynowych, księgowości czy jakikolwiek inny, zostaje już wdrożony i działa (korzystają z niego użytkownicy realizując swoje zadania), często okazuje się, że za jakiś czas pojawiają się potrzeby, żeby jeszcze coś drobnego zmienić, dodać, przesunąć, pokazać. Zmieniają się przepisy, sposoby działania, priorytety. Użytkownicy coraz lepiej znają narzędzie. Widzą, które mechanizmy są dla nich upierdliwe czy wręcz uniemożliwiają działanie. Mają też pomysły na usprawnienia. Nie mówiąc już o błędach, które pojawiają się, kiedy użytkownicy zaczynają pracować w systemie realizując przeróżne scenariusze, które nie zostały opisane jako wymagania ani przetestowane, a teraz wywalają system.
Gdyby wszyscy programiści spakowali manatki i zaraz po wdrożeniu systemu opuścili użytkowników, byłby problem. Niektóre systemy wpierają główną działalność firmy przez kilka, kilkanaście czy nawet 20 lat. Nie można ich z dnia na dzień zamknąć, uruchomić czegoś innego czy napisać innego systemu nie poświęcając lat pracy ogromnych zespołów. Błędy czy niedociągnięcia odbijają się działaniu firmy, np. paraliżując składanie zamówień i pracę tysięcy ludzi, ich klientów i partnerów biznesowych.
Dlatego też często do ważnych dla firmy systemów wyznacza się zespoły osób pracujących nad utrzymaniem aplikacji. Mogą być to te same osoby, które pracowały nad jej stworzeniem lub inne, które się do tego przeszkoli.
Jakie zadania wykonuje się w utrzymaniu aplikacji?
Do osób pracujących nad utrzymaniem aplikacji spływają dwa rodzaje zadań. Pierwsze to błędy (defekty wynikające ze zgłoszonych incydentów działania aplikacji), a drugie to zmiany (CRy, change requests, żądania zmian).
Czym są incydenty?
„Czym jest zatem incydent? Skoro nie jest tym samym czym jest defekt. incydent – to każde zdarzenie wymagające zbadania.”
Źródło: http://testgeeks.co/incydent-defekt/ za SJSI – Słownik Terminów Testowych
Czym są defekty?
„Defektem natomiast nazywana jest – wada modułu lub systemu. Wada ta może spowodować, że moduł lub system nie wykona zakładanej czynności np. niepoprawne wyrażenie lub definicja danych. Defekt, który wystąpi podczas uruchomienia programu, może spowodować awarię modułu lub systemu.”
Źródło: http://testgeeks.co/incydent-defekt/ za SJSI – Słownik Terminów Testowych
Czym są zmiany?
Zmiany (żądania zmian, Change Requests, CRy) to nowe wymagania do zaimplementowania w systemie. Jest to nowa cecha czy zachowanie aplikacji, której ona w tej chwili nie posiada. Nie ma jej w specyfikacji, wymaganiach, działającym kodzie.
Zmiany można zgłaszać w tak zwanych żądaniach zmian, potocznie „chcę dodać/zmienić to czy tamto”. Takie żądanie może przyjść mailem, wyniknąć z rozmowy, jednak najczęściej, dla porządku, zgłoszeniami zarządza się w jednym miejscu, np. w aplikacji do zarządzania zadaniami.
