7 zasad testowania. Część 3
7 zasad testowania. Część 3
W niniejszym artykule zajmiemy się pozostałymi trzema zasadami testowania.
1 list 2016
3955
Other articles
Testowanie aplikacji za pomocą JUnit5 i JMock. Część 2
Jak przygotować się do certyfikacji IIBA. Wyzwania i hacki
Testowanie aplikacji za pomocą JUnit5 i Mockito. Część 2
Testowanie aplikacji za pomocą JUnit5 i Mockito. Część 1
Testowanie aplikacji za pomocą JUnit5 i EasyMock. Część 2
Testowanie aplikacji za pomocą JUnit5 i EasyMock. Część 1
Test Driven Development z użyciem JUnit 5. Część 6
Test Driven Development z użyciem JUnit 5. Część 5
Test Driven Development z użyciem JUnit 5. Część 4
Test Driven Development z uzyciem JUnit 5. Czesc 3
W niniejszym artykule zajmiemy się pozostałymi trzema zasadami testowania.
Zasada 5. Paradoks pestycydów
Jeżeli te same testy są wielokrotnie powtarzane, to w końcu ten sam zestaw przypadków testowych nie będzie w stanie wynaleźć nowych defektów. Skupiska defektów, o których wspomina czwarta zasada, mają tendencję do przemieszczania się. Dlaczego tak się dzieje?
Taka analogia została zaproponowana przez Borisa Beizera w 1983. Podał wtedy przykład stosowania pestycydów. Pestycyd zabija pluskwy, ale wielokrotne stosowanie tej samej trucizny na tym samym polu spowoduje wzrost odporności u pozostałych pluskiew. Jeżeli nadal stosuje się ten sam pestycyd, w końcu owady rozwijają oporność na niego i pestycyd przestaje działać. Wielokrotne stosowanie tych samych testów i tych samych metodologii w konsekwencji doprowadzi do defektów w oprogramowaniu, których już nie da się znaleźć za pomocą tych testów i tych metodologii.
Aby pokonać ten 'paradoks pestycydów', trzeba poddawać istniejące przypadki testowe regularnej analizie i modyfikacji, a także pisać różne nowe testy, służące do sprawdzenia różnych części systemu. Pomoże to znaleźć więcej defektów.
Zasada 6. Testowanie jest zależne od kontekstu
W różnych kontekstach testowanie jest wykonywane w różny sposób. Na przykład, oprogramowanie krytyczne ze względów bezpieczeństwa powinno być testowane inaczej niż sklep internetowy.
Zasada jest ściśle związana z pojęciem ryzyka. Czym właściwie jest ryzyko? Ryzyko to potencjalny problem. Prawdopodobieństwo (likelyhood) wystąpienia ryzyka w przyszłości wynosi od 0% do 100%; ryzyko także ma wpływ (impact), tj. negatywne konsekwencje których się obawiamy. Analizując ryzyko zawsze rozważamy te dwa aspekty - prawdopodobieństwo i wpływ. Na przykład, przechodząc przez jezdnię zawsze narażamy się na ryzyko że przejedzie nas samochód. Prawdopodobieństwo zależy od takich czynników jak intensywność ruchu drogowego, bezpieczne przejście, od tego jak dobrze widzimy i jak szybko jesteśmy w stanie iść. Wpływ zależy od tego, jak szybko jedzie samochód, czy mamy na sobie odzież ochronną, od naszego wieku, stanu zdrowia itp. W zależności od tych czynników człowiek może wybrać najlepszą dla siebie strategię przechodzenia.

To samo można powiedzieć o oprogramowaniu: różne systemy są połączone z różnymi poziomami ryzyka i wpływ problemów może znacznie się różnić. Niektóre problemy są dość trywialne, jednak inne mogą być kosztowne i szkodliwe - związane ze stratą pieniędzy, czasu czy reputacji biznesowej - a nawet mogą doprowadzić do urazu czy śmierci.
Poziom ryzyka może wpływać na wybór metodologii, technik i typów testów.
Zasada 7. Mylne przekonanie o braku błędów
Znalezienie i usuwanie defektów nie ma sensu, jeżeli zbudowany system jest bezużyteczny i nie spełnia wymagań i oczekiwań użytkowników.
Klienci - ludzie i organizacje, kupujące i używające oprogramowania do swojej codziennej pracy - nie interesują się defektami czy ilością defektów, o ile niestabilność oprogramowania nie wpływa na nich bezpośrednio. Nie ma dla nich znaczenia, na ile oprogramowanie spełnia udokumentowane wymagania formalne. Użytkowników oprogramowania interesuje bardziej, aby pomagało im w wykonaniu zadań w sposób efektywny. Oprogramowanie powinno odpowiadać ich potrzebom i jest oceniane przez nich z tego punktu widzenia.
Nawet jeśli zrobiono wszystkie testy i nie znaleziono żadnych defektów, nie daje to gwarancji, że oprogramowanie będzie spełniało wymogi i oczekiwania użytkowników.
Innymi słowy, weryfikacja i walidacja.
Weryfikacja to egzaminowanie systemu w celu ustalenia, czy spełnia zdefiniowane wymagania. Walidacja to sprawdzenie systemu w celu ustalenia, czy spełnia wymagania i oczekiwania użytkownika i jest dostosowany do jego potrzeb.
Część aktywności testowych powinna się koncentrować na weryfikacji, druga część na walidacji.
Teoretycznie, jeżeli wymagania zostały odpowiednio zebrane i przeanalizowane i nie wystąpiły zniekształcenia na etapie architektury i wytwarzania kodu, nie powinno być żadnych niezgodności. Ale życie, niestety, nie jest idealne.
Victoria Slinyavchuk
Consultant on Software Testing
Zasada 5. Paradoks pestycydów
Jeżeli te same testy są wielokrotnie powtarzane, to w końcu ten sam zestaw przypadków testowych nie będzie w stanie wynaleźć nowych defektów. Skupiska defektów, o których wspomina czwarta zasada, mają tendencję do przemieszczania się. Dlaczego tak się dzieje?
Taka analogia została zaproponowana przez Borisa Beizera w 1983. Podał wtedy przykład stosowania pestycydów. Pestycyd zabija pluskwy, ale wielokrotne stosowanie tej samej trucizny na tym samym polu spowoduje wzrost odporności u pozostałych pluskiew. Jeżeli nadal stosuje się ten sam pestycyd, w końcu owady rozwijają oporność na niego i pestycyd przestaje działać. Wielokrotne stosowanie tych samych testów i tych samych metodologii w konsekwencji doprowadzi do defektów w oprogramowaniu, których już nie da się znaleźć za pomocą tych testów i tych metodologii.
Aby pokonać ten 'paradoks pestycydów', trzeba poddawać istniejące przypadki testowe regularnej analizie i modyfikacji, a także pisać różne nowe testy, służące do sprawdzenia różnych części systemu. Pomoże to znaleźć więcej defektów.
Zasada 6. Testowanie jest zależne od kontekstu
W różnych kontekstach testowanie jest wykonywane w różny sposób. Na przykład, oprogramowanie krytyczne ze względów bezpieczeństwa powinno być testowane inaczej niż sklep internetowy.
Zasada jest ściśle związana z pojęciem ryzyka. Czym właściwie jest ryzyko? Ryzyko to potencjalny problem. Prawdopodobieństwo (likelyhood) wystąpienia ryzyka w przyszłości wynosi od 0% do 100%; ryzyko także ma wpływ (impact), tj. negatywne konsekwencje których się obawiamy. Analizując ryzyko zawsze rozważamy te dwa aspekty - prawdopodobieństwo i wpływ. Na przykład, przechodząc przez jezdnię zawsze narażamy się na ryzyko że przejedzie nas samochód. Prawdopodobieństwo zależy od takich czynników jak intensywność ruchu drogowego, bezpieczne przejście, od tego jak dobrze widzimy i jak szybko jesteśmy w stanie iść. Wpływ zależy od tego, jak szybko jedzie samochód, czy mamy na sobie odzież ochronną, od naszego wieku, stanu zdrowia itp. W zależności od tych czynników człowiek może wybrać najlepszą dla siebie strategię przechodzenia.

To samo można powiedzieć o oprogramowaniu: różne systemy są połączone z różnymi poziomami ryzyka i wpływ problemów może znacznie się różnić. Niektóre problemy są dość trywialne, jednak inne mogą być kosztowne i szkodliwe - związane ze stratą pieniędzy, czasu czy reputacji biznesowej - a nawet mogą doprowadzić do urazu czy śmierci.
Poziom ryzyka może wpływać na wybór metodologii, technik i typów testów.
Zasada 7. Mylne przekonanie o braku błędów
Znalezienie i usuwanie defektów nie ma sensu, jeżeli zbudowany system jest bezużyteczny i nie spełnia wymagań i oczekiwań użytkowników.
Klienci - ludzie i organizacje, kupujące i używające oprogramowania do swojej codziennej pracy - nie interesują się defektami czy ilością defektów, o ile niestabilność oprogramowania nie wpływa na nich bezpośrednio. Nie ma dla nich znaczenia, na ile oprogramowanie spełnia udokumentowane wymagania formalne. Użytkowników oprogramowania interesuje bardziej, aby pomagało im w wykonaniu zadań w sposób efektywny. Oprogramowanie powinno odpowiadać ich potrzebom i jest oceniane przez nich z tego punktu widzenia.
Nawet jeśli zrobiono wszystkie testy i nie znaleziono żadnych defektów, nie daje to gwarancji, że oprogramowanie będzie spełniało wymogi i oczekiwania użytkowników.
Innymi słowy, weryfikacja i walidacja.
Weryfikacja to egzaminowanie systemu w celu ustalenia, czy spełnia zdefiniowane wymagania. Walidacja to sprawdzenie systemu w celu ustalenia, czy spełnia wymagania i oczekiwania użytkownika i jest dostosowany do jego potrzeb.
Część aktywności testowych powinna się koncentrować na weryfikacji, druga część na walidacji.
Teoretycznie, jeżeli wymagania zostały odpowiednio zebrane i przeanalizowane i nie wystąpiły zniekształcenia na etapie architektury i wytwarzania kodu, nie powinno być żadnych niezgodności. Ale życie, niestety, nie jest idealne.
Victoria Slinyavchuk
Consultant on Software Testing