Testowanie oprogramowania
| 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
- Mikelsten D. (2020), Automatyzacja i nowe technologie., Cambridge Stanford Books.
- Myers G., Sandler C., Badgett T. (2011), The art of software testing., John Wiley&Sons.
- Olsen K., Parveen T., Black R., Friedenberg D., Hamburg M., McKay J., Posthuma M., Schaefer H., Smilgin R., Smith M., Toms S., Ulrich S., Walsh M., Zakaria E. (2019), Certyfikowany tester Sylabus poziomu podstawowego ISTQB® 2018, Stowarzyszenie Jakości Systemów Informatycznych, str. 12-20.
- Pawlak R. (2014), Testowanie oprogramowania. Podręcznik dla początkujących., Wydawnictwo Helion, str. 65-72.
- Pietrzak B. (2020), Wprowadzenie do testowania., Wydział Matematyki, Informatyki i Mechaniki Uniwersytetu Warszawskiego, str. 9.
Autor: Paweł Łącki
