Testowanie oprogramowania

Z Encyklopedia Zarządzania
Wersja z dnia 11:43, 19 maj 2020 autorstwa Sw (dyskusja | edycje) (Infobox update)
(różn.) ← poprzednia wersja | przejdź do aktualnej wersji (różn.) | następna wersja → (różn.)
Testowanie oprogramowania
Polecane artykuły

Testowanie oprogramowania to proces obejmujący wiele czynności, takich jak planowanie testów, monitorowanie i nadzór nad testami, analiza, projektowanie testów, implementacja testów, wykonywania i ukończenie testów, pomagający tworzyć spójne i poprawnie działające oprogramowanie. Do innych działań, które obejmuję proces testowania oprogramowania mogą należeć między innymi raportowanie o postępie i wynikach testów oraz dokonywanie oceny jakości przedmiotu testów (Olsen K., s. 18). Jednym z podstawowych podziałów jaki można dokonać jest podział na testowania dynamiczne (gdy włączenie testowanego modułu jest wymagane) i testowanie statyczne (przy wyłączonym obiekcie testowym) (Pietrzak B., s. 9).

Poziomy wykonywania testów

Proces wytwarzania oprogramowania składa się z kilku etapów/ faz, w których wykonuje się charakterystyczne testy. Testy te można podzielić w następujący sposób (Pawlak R., s. 65):

  • testy modułowe (jednostkowe),
  • testy integracyjne wewnętrzne,
  • testy systemowe,
  • testy integracyjne zewnętrzne,
  • testy akceptacyjne (odbiorcze).

Zasady testowania

W testowaniu oprogramowania możemy wyróżnić siedem zasad (Olsen K., s. 16-18):

  • Zasada pierwsza - Testowanie ujawnia usterki, ale nie może dowieść ich braku

Proces testowania może ujawnić występujące w oprogramowaniu defekty, ale nie może potwierdzić, że dany obiekt jest od nich wolny. Co można zinterpretować na kilka sposobów - np.: brak wykrycia jakichkolwiek błędów czy bugów nie świadczy o poprawności testowanego systemu.

  • Zasada druga - Testowanie gruntowne jest niemożliwe

Zasada ta mówi o tym, że nie da się przetestować wszystkiego (tzn. każdej kombinacji warunków założonych oraz danych wejściowych). Należy więc swoje starania skierować na odpowiednie czynniki i elementy testowanego obiektu (poprzedzając to gruntowną analizą samego systemu, analizą ryzyka czy technik testowania jakich należy użyć w konkretnym przypadku).

  • Zasada trzecia - Wczesne testowanie oszczędza czas i pieniądze

Zasada ta wiąże się głównie z aspektami finansowymi - wykrycie błędów na wczesnym etapie projektu, pozwala na ich szybkie usunięcie - bez konieczności mocnego ingerowania w gotowy, złożony produkt.

  • Zasada czwarta - Kumulowanie się defektów

Zasada ta mówi o tym, że duża część błędów, które zostały wykryte podczas testowania przed oddaniem oprogramowania do użytkowania lub defekty występujące podczas użytkowania występują w małej liczbie modułów. Na tej podstawie można postawić tezę, że przewidywane grupy defektów i faktyczne grupy defektów, które zostały zaobserwowane podczas testowania/ eksploatacji są istotną częścią analizy ryzyka, którą wykonuję się aby odpowiednio skierować wysiłki związane z testowaniem.

  • Zasada piąta - Paradoks pestycydów

Nazwa tej zasady jest metaforą nawiązującą do środków ochrony roślin - a konkretniej do ich działania. Pestycydy po pewnym czasie użytkowania nie są w stanie wyeliminować szkodników. Bardzo podobnie jest w przypadku testowania oprogramowania - powtarzanie tych samych testów, skutkuje brakiem wykrywalności nowych bugów i błędów. Aby prawidłowo i skutecznie szukać defektów, możliwe że konieczna będzie zmiana strategii, typów, bądź założeń początkowych.

  • Zasada szósta - Testowanie zależy od kontekstu

Testowanie wykonuje się w różny sposób i w różnych branżach, dziedzinach i technologiach. Konieczne jest rozróżnienie i odpowiednie dostosowanie się testera do warunków w jakich przyjdzie mu pracować (testowanie strony internetowej czy nowego oprogramowania dla szpitala koniecznego do przeprowadzania operacji, gdzie o ludzkim życiu może decydować niewykryty wcześniej błąd).

  • Zasada siódma - Przekonanie o braku błędów jest błędem

Zasada ta jest dość prosta w interpretacji - oprogramowanie, zawsze jest obarczone błędem. Trzeba sobie tylko zadać pytanie, czy błąd odnaleziony przez testera jest konieczny aby całość oprogramowania działała poprawnie i czy jego usunięcie jest ekonomicznie i użytkowo uzasadnione.

Testowanie oprogramowania w projektach informatycznych

W przeszłości można wyszukać wiele przykładów oprogramowania i systemów, które zostały przekazane do użytkowania, ale na skutek błędów uległy awarii lub z innych powodów nie były w stanie sprostać potrzebom użytkowników. Dzięki właściwym technologiom testowania — stosowanym we właściwy sposób na odpowiednich poziomach testów i na konkretnych etapach cyklu życia oprogramowania — częstotliwość występowania tego rodzaju defektów może zostać znacznie zmniejszona. Bardzo często rozwiązania takich problemów są bardzo proste (kontrolowanie odpowiedniego poziomu komunikacji na linii projektant – programista – tester – klient/ użytkownik, poprawa user stories. Zazwyczaj przy zwinnym podejściu do tworzenia oprogramowania podobne sytuacje zdarzają się rzadziej niż w modelach tradycyjnych, co wynika z faktu testowania oprogramowania w krótkich odstępach czasu, systematycznie wraz z wprowadzanymi przez programistów zmianami (Olsen K., s. 13).

Bibliografia

Autor: Paweł Łącki