Wiele błędów w oprogramowaniu pozostaje niewidocznych aż do zakończenia procesu jego tworzenia, a oznaczają one wyższe koszty oraz dłuższy czas realizacji projektu. Okresowe testowanie powstającego oprogramowania powinno zatem być postrzegane jako główne narzędzie kontroli kosztów i ryzyka podczas planowania projektu.
Każdy z nas albo brał udział, albo widział projekty rozwojowe różnego typu oprogramowania, które nie zakończyły się sukcesem i wdrożeniem, jak to było zaplanowane z wielu przyczyn, takich jak: zmiany zakresu projektu, nadmierne koszty lub problemy z harmonogramem realizacji. Dlatego też testowanie działania projektowanego oprogramowania, szczególnie gdy w trakcie realizacji projektu realizowane są wyżej wspomniane scenariusze, ma olbrzymie znaczenie dla poprawnej organizacji projektu już na samym jego początku.
Niestety często mamy do czynienia z sytuacjami, gdzie procedury testowania są jednym z pierwszych elementów wycinanych z programów realizacji, lub ograniczanych w sytuacjach, gdy istnieje nacisk na zmniejszenie kosztów lub skrócenie harmonogramu realizacji projektu. Taka strategia nie daje zamierzonego efektu, a wręcz przeciwnie, prawie zawsze daje skutek zupełnie odmienny od zamierzonego. Przeprowadzenie mniejszej liczby testów lub ich opóźnienie w procesie, nie wpływa znacząco na jakość rozwiązań. Powoduje tylko opóźnienie wykrycia problemów.
Znalezienie tego samego problemu we wczesnym etapie procesu opracowywania oprogramowania zamiast pod koniec, to znaczy podczas regularnego testowania oprogramowania, a nie dopiero podczas jego działania w aplikacji przemysłowej, jest wykładniczo tańsze i prawie zawsze wymaga mniej czasu na rozwiązanie tego problemu. Aby podkreślić ten fakt można rozważyć scenariusz, w którym znaleziono błąd oprogramowania (ang. bug) w zatwierdzonym już środowisku produkcyjnym:
- Problem musi być zidentyfikowany, zgłoszony i potencjalnie wykonana poprawka programowa
- Problem musi być odtworzony, zaklasyfikowany pod względem powagi i musi mu być przyznany priorytet
- Problem prawdopodobnie zostanie odtworzony ponownie przez dewelopera oprogramowania i usunięty
- Usunięcie problemu wymaga wdrożenia i przetestowania w środowisku testowym
- Usunięcie problemu wymaga wdrożenia i przetestowania w środowisku walidacyjnym
- Usunięcie problemu wymaga wdrożenia w środowisku produkcyjnym
Podane wyżej kroki nie obejmują aprobat, inspekcji kodów (ang. code reviews), raportów o stanie, zarządzania zmianami etc. Jednak już samo to ilustruje, że wymagane jest coraz więcej czasu i zasobów do odnajdowania i naprawy błędów oprogramowania w trakcie jego używania w produkcji przemysłowej, w porównaniu do wykonywania tego typu czynności podczas testowania programu w fazie wczesnego opracowywania. Ten zaprezentowany pokrótce najgorszy scenariusz, dobrze ilustruje wniosek ogólny: identyfikacja błędów oprogramowania później ? w trakcie jego używania ? jest kosztowna. A ma to znaczenie jeszcze przed rozważeniem kosztów związanych z potencjalnym wpływem błędów na produkt, klienta czy markę firmy.
Im później od opracowania oprogramowania odnajduje się w nim błąd, tym droższe jest jego usunięcie. Z tego powodu testy powinny być traktowane jako główne narzędzie kontroli kosztów i ryzyka podczas planowania projektu realizacji nowego oprogramowania. Ukształtowanie planu projektu tak by znalazły się w nim etapy procedur testowych (ang. test cases), będących częścią projektu funkcjonalnego i technicznego lub istniejących równolegle z nim, jest bardzo skuteczne, ponieważ:
1. Zapewnia, że uwzględnienie procedur testowych ma miejsce na samym początku projektu. Wówczas zapobiega to możliwości redukcji lub wycięcia z projektu odpowiednich procedur testowych przez osoby decyzyjne w sytuacji zaistnienia nacisków na redukcję kosztów, lub czasu realizacji projektu. Modelujemy odpowiednio projekt, w zasadzie aby się zabezpieczyć przed samymi sobą.
2. Proces procedur testowych często uwydatnia obraz gotowego rozwiązania w oczach użytkownika końcowego. Realizacja procedur testowych i ich analiza wraz z osobami zainteresowanymi oraz użytkownikami końcowymi, jeszcze przed opracowaniem oprogramowania, daje okazję do identyfikacji nieporozumień i niedomówień przed rozpoczęciem kodowania, co zmniejsza ryzyko konieczności ponownego wykonania pracy od początku.
3. Analizy wyników procedur testowych dostarczają deweloperom oprogramowania dodatkowych informacji, które umożliwiają odpowiednie rozszerzenie projektu i czynią je bardziej zrozumiałymi. Daje to dodatkowe gwarancje, że deweloperzy wyraźnie rozumieją jak powinno wyglądać gotowe rozwiązanie, co zmniejsza prawdopodobieństwo wprowadzenia błędów oprogramowania na samym początku. Całkowite unikniecie tych błędów oznacza olbrzymie oszczędności czasu i kosztów. Szczególnie w porównaniu do minimalnego czasu poświęconego na tworzenie właściwych procedur testowych; procedur które byłyby i tak utworzone w późniejszym etapie realizacji projektu.
4. Obecnie deweloperzy posiadają odpowiednie, rygorystyczne skrypty testowe (ang. test script), których używają przy testowaniu swojego oprogramowania, które z kolei powinno ściśle pasować do skryptów testowych walidacji końcowej. Najtańszym sposobem odnalezienia i likwidacji błędów oprogramowania jest wykonanie procedur testowania tego oprogramowania, tak więc dostarczenie deweloperom dodatkowych narzędzi, które zwiększają poziom detekcji błędów już na początku projektowania jest niezwykle wartościowe.
O ile wprowadzenie takiej małej zmiany, wymagającej opracowania odpowiednich procedur testowych przed realizacją projektu oprogramowania, w teorii może wydawać się rzeczą trywialną, w praktyce może mieć głęboki pozytywny wpływ na projekt.
Niniejszy post został napisany przez Jasona Sampersa. Jason jest architektem aplikacji w firmie Maverick Technologies, będącej wiodącym dostawcą rozwiązań dla automatyki, oferując usługi dla przemysłu przetwórczego w takich dziedzinach, jak: automatyka przemysłowa, produkcja strategiczna oraz integracja przedsiębiorstwa.
