Testowanie oprogramowania: Różnice pomiędzy wersjami

Z Encyklopedia Zarządzania
m (Infobox update)
 
(LinkTitles.)
Linia 13: Linia 13:
</ul>
</ul>
}}
}}
'''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.  
'''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).
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).
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).
Linia 28: Linia 28:
==Zasady testowania==
==Zasady testowania==
W testowaniu oprogramowania możemy wyróżnić siedem zasad (Olsen K., s. 16-18):
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'''
* [[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.
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 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 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 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 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 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 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'''  
* 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.
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'''  
* 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).
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 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.
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==
==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).
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==
==Bibliografia==
* Mikelsten D. (2020), [https://books.google.pl/books?id=Yx7NDwAAQBAJ&pg=PT26&dq=testowania+oprogramowania&hl=en&sa=X&ved=0ahUKEwi98qeppOjoAhUHNOwKHXdTCRoQ6AEIXDAF''Automatyzacja i nowe technologie.''], Cambridge Stanford Books.
* Mikelsten D. (2020), [https://books.google.pl/books?id=Yx7NDwAAQBAJ&pg=PT26&dq=testowania+oprogramowania&hl=en&sa=X&ved=0ahUKEwi98qeppOjoAhUHNOwKHXdTCRoQ6AEIXDAF''Automatyzacja i nowe technologie.''], Cambridge Stanford Books.
* Myers G., Sandler C., Badgett T. (2011), [https://books.google.pl/books?id=GjyEFPkMCwcC&printsec=frontcover&dq=testowania+oprogramowania+pdf&hl=en&sa=X&ved=0ahUKEwjf9rLMo-joAhWpwAIHHcGiC2MQ6AEIMDAB#v=onepage&q&f=false''The art of software testing.''], John Wiley&Sons.
* Myers G., Sandler C., Badgett T. (2011), [https://books.google.pl/books?id=GjyEFPkMCwcC&printsec=frontcover&dq=testowania+oprogramowania+pdf&hl=en&sa=X&ved=0ahUKEwjf9rLMo-joAhWpwAIHHcGiC2MQ6AEIMDAB#v=onepage&q&f=false''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.
* 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), [https://pdf.helion.pl/szteop/szteop.pdf''Testowanie oprogramowania. Podręcznik dla początkujących.''], Wydawnictwo Helion, str. 65-72.
* Pawlak R. (2014), [https://pdf.helion.pl/szteop/szteop.pdf''Testowanie oprogramowania. Podręcznik dla początkujących.''], Wydawnictwo Helion, str. 65-72.
* Pietrzak B. (2020), [http://wazniak.mimuw.edu.pl/index.php?title=Io-10-wyk-toc''Wprowadzenie do testowania.''], Wydział Matematyki, Informatyki i Mechaniki Uniwersytetu Warszawskiego, str. 9.
* Pietrzak B. (2020), [http://wazniak.mimuw.edu.pl/index.php?title=Io-10-wyk-toc''Wprowadzenie do testowania.''], Wydział Matematyki, Informatyki i Mechaniki Uniwersytetu Warszawskiego, str. 9.

Wersja z 05:52, 22 maj 2020

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.

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