Cześć,
Witam Cię w 4 odcinku podcastu Szkoły Testowania. Dzisiaj zajmiemy się podstawowymi zasadami, jakich należy przestrzegać podczas testowania. Zaczynamy!
Ważne jest, aby osiągnąć optymalne wyniki testów podczas przeprowadzania testów oprogramowania, bez odchyleń od celu. Ale w jaki sposób określić, że postępujesz zgodnie z właściwą strategią testowania? W tym celu należy przestrzegać pewnych podstawowych zasad testowania. Przyjrzymy się dzisiaj siedmiu z nich.
Aby zrozumieć, należy jednak rozważyć scenariusz, w którym przenosi się np. jakiś plik z folderu A do folderu B. W jaki sposób byś przetestował taki scenariusz? Pomyśl o wszystkich możliwościach. Kilka z nich, które mi przychodzą do głowy to:
- Próba przeniesienia otwartego pliku.
- Próba przeniesienia/skopiowania pliku do folderu, do którego nie masz uprawnień.
- Foldery są na tym samym dysku, a pojemność dysku jest pełna.
- Foldery mają taką samą nazwę.
- Albo np. załóżmy, że mamy do przetestowania 15 pól wejściowych, a każde z nich ma 5 możliwych wartości, liczba kombinacji wyniesie w takim przypadku 5^15.
Gdybyś chciał przetestować wszystkie możliwe kombinacje, to czas wykonania i koszt projektu znacznie wzrośnie. Więc potrzebujemy pewnych zasad i strategii, aby zoptymalizować wysiłek związany z testowaniem.
Oto 7 z nich.
Nie ma możliwości przeprowadzenia szczegółowych testów.
Tak, dobrze słyszałeś. Szczegółowe testy wszystkiego nie są możliwe. Zamiast tego potrzebujemy optymalnej ilości testów w oparciu o ocenę ryzyka aplikacji. Ale najważniejsze pytanie brzmi: w jaki sposób określić to ryzyko? Aby odpowiedzieć na to pytanie, zróbmy pewne ćwiczenie. Jaka operacja wg Ciebie może spowodować np. awarię systemu operacyjnego? Pewnie większość z Was odpowie: otwarcie 10-20 różnych aplikacji w tym samym czasie. Więc jeśli testowalibyśmy ten system operacyjny, zdalibyśmy sobie sprawę, że usterki występują podczas wielozadaniowości i muszą być dokładnie przetestowane, co prowadzi nas do następnej zasady, którą jest… z angielskiego…
Defect Clustering.
Defect Clustering to nic innego jak to, że niewielka liczba modułów zawiera większość wykrytych defektów. Jest to zastosowanie zasady Pareto do testowania oprogramowania: czyli około 80% problemów występuje w 20% modułów.
Na podstawie doświadczenia można zidentyfikować takie problematyczne moduły. Ale to podejście ma swoje własne wady. Jeśli te same testy będą powtarzane w kółko, ostatecznie te same przypadki testowe nie będą już znajdowały nowych błędów.
Trzecią zasadą jest tzw. Paradoks Pestycydów.
Powtarzające się stosowanie tej samej mieszanki pestycydów w celu wyeliminowania owadów w rolnictwie z czasem doprowadza do wytworzenia przez owady odporności na stosowane pestycydy, przez co staną się one nieskuteczne. To samo dotyczy testowania oprogramowania. Jeśli ten sam zestaw powtarzanych testów zostanie przeprowadzony, metoda ta będzie bezużyteczna w wykrywaniu nowych błędów. Aby to wyeliminować, przypadki testowe muszą być regularnie sprawdzane i poprawiane, dodając nowe i różne przypadki testowe, aby pomogły znaleźć jak najwięcej błędów podczas wykonywania testów. Testerzy nie mogą po prostu polegać na istniejących technikach testowych. Muszą oni nieustannie dążyć do udoskonalania istniejących metod, aby testowanie było bardziej efektywne. Ale nawet po całej tej ciężkiej pracy, nigdy nie możemy w 100% stwierdzić, że oprogramowanie jest wolne od wad i błędów. Przykład: zobacz na YouTube oficjalną premierę systemu Windows 98. Myślisz, że firma taka jak Microsoft nie przetestowałaby dokładnie swojego systemu i zaryzykowałaby swoją reputację tylko po to, aby zobaczyć, jak system operacyjny ulegnie awarii podczas publicznej prezentacji i wprowadzenia go na rynek?
Testowanie wykazuje obecność błędów.
Testowanie oprogramowania zmniejsza prawdopodobieństwo wystąpienia wad w oprogramowaniu. Ale nawet jeśli nie zostaną wykryte żadne wady, nie jest to żaden dowód, że oprogramowanie jest wolne od błędów. A co jeśli ciężko pracujemy, podejmujemy wszelkie środki ostrożności i upewniamy się, że oprogramowanie w 99% jest wolne od błędów, ale oprogramowanie nie spełnia potrzeb i wymagań klienta? O tym mówi 4 zasada, tj. Brak Błędów.
Brak Błędów.
Możliwe jest, że oprogramowanie, które jest wolne od wad w 99%, nadal nie nadaje się do użytku. Może tak być np. w przypadku, gdy system jest dokładnie przetestowany, ale pod kątem niewłaściwych wymagań. Testowanie oprogramowania to nie tylko wykrywanie usterek, ale także sprawdzenie, czy oprogramowanie odpowiada potrzebom biznesowym. Brak błędu jest błędem, tzn. wykrywanie i usuwanie usterek nic nie pomoże, jeśli budowa systemu jest bezużyteczna i nie spełnia potrzeb i wymagań. Aby rozwiązać ten problem, następną zasadą jest… Wczesne Testowanie.
Wczesne Testowanie.
Testowanie powinno rozpocząć się, jak najwcześniej w cyklu życia rozwoju oprogramowania. W ten sposób wszelkie usterki w fazie projektowania są wykrywane na wczesnym etapie. Znacznie taniej jest naprawić usterkę na wczesnym etapie. Ale jak wcześnie należy rozpocząć testy? Zaleca się, aby zacząć testy w momencie zdefiniowania wymagań.
Testowanie zależy od kontekstu.
Oznacza to, że sposób, w jaki testujesz np. witrynę e-commerce będzie się różnił od sposobu, w jaki testujesz komercyjną aplikację. Oprogramowania różnią się od siebie. Możesz używać innego podejścia, metodologii, technik i rodzajów testów w zależności od typu aplikacji.
Na koniec pewien mit, który mówi, że „Zasady służą tylko jako punkt odniesienia. I tak nie będę ich używał w praktyce”. Jest to bardzo nieprawdziwe. Zasady testowania pomogą Ci stworzyć skuteczną strategię testowania. Ale z nauką zasad testowania jest jak z nauką jazdy samochodem po raz pierwszy. Początkowo kiedy uczysz się jazdy samochodem, zwracasz uwagę na wszystko, jak drążek zmiany biegów, prędkość, sprzęgło, itp. Ale wraz z doświadczeniem, po prostu koncentrujesz się na prowadzeniu samochodu, reszta przychodzi naturalnie i automatycznie. Możesz nawet prowadzić rozmowy podczas jazdy ? To samo dotyczy zasad testowania. Doświadczeni testerzy przyswoili sobie te zasady do takiego poziomu, że stosują je już bez zastanowienia. Stąd mit, że te zasady nie są stosowane w praktyce, jest mitem.
I to tyle w dzisiejszym odcinku. Dziękuję Ci za Twój czas i za wszystko. Życzę udanego i produktywnego dnia. Do usłyszenia!
Cały odcinek można wysłuchać TUTAJ.
