Jakiś czas temu zrobiłam kurs Software Testera, na którym poznawałam podstawy testowania. Jedną z najciekawszych rzeczy, jakich się wtedy nauczyłam, było 7 zasad testowania według ISTQB.
Dlaczego uważam, że są świetne i przydatne? Przeczytaj w artykule poniżej.
Sylabus ISTQB v4.0 wyróżnia 7 zasad testowania.
1. Testowanie pokazuje obecność defektów, a nie ich brak.
Testy dowodzą, że coś nie działa, ale nie mogą zagwarantować, że defektów nie ma.
Ta zasada pomaga ustalić realistyczne oczekiwania wobec tego, co mogą dać testy. Przypomina zespołowi, że choć testowanie jest kluczowe dla wykrywania defektów, nie zagwarantuje produktu całkowicie ich pozbawionego. Dzięki temu łatwiej zarządzać ryzykiem i wyznaczać sensowne cele jakościowe.
2. Testowanie wyczerpujące jest niemożliwe
Przetestowanie wszystkiego nie jest możliwe, poza prostymi przypadkami.
Świadomość ograniczeń zasobów testowych zachęca zespół do ustalania priorytetów. Prowadzi to do bardziej efektywnych strategii testowania, skupionych na obszarach o największym wpływie, co oszczędza czas i zasoby, a jednocześnie pozwala rzetelnie ocenić oprogramowanie.
3. Wczesne testowanie oszczędza czas i pieniądze
Im wcześniej zaczniemy testować, tym niższy koszt naprawy błędu i jego wpływ na resztę oprogramowania. Wykrywanie błędów powinno się zaczynać jak najwcześniej.
Wprowadzenie testów na wczesnym etapie rozwoju pomaga wykryć defekty, gdy ich naprawa jest tańsza i prostsza. Poprawia to jakość produktu, obniża koszty i skraca harmonogram, a sam proces wytwarzania oprogramowania staje się bardziej elastyczny i szybciej reaguje na zmiany.
4. Defekty skupiają się w grupach
Jeśli podczas testowania jeden z modułów ma wyraźnie więcej błędów niż pozostałe, bardzo prawdopodobne jest, że siedzi w nim ich jeszcze dużo więcej. Dzięki temu lepiej zaplanujemy strategię testowania i wskażemy moduły, które warto przetestować intensywniej.
Wiedza, że defekty mają tendencję do skupiania się w określonych miejscach, pozwala testerom skuteczniej kierować wysiłek. Ta zasada podpowiada, żeby więcej zasobów przeznaczać na obszary wysokiego ryzyka, co może poprawić skuteczność wykrywania defektów i ogólną jakość oprogramowania.
5. Testy się zużywają
Wielokrotne powtarzanie tych samych testów sprawia, że coraz słabiej wykrywają nowe błędy. Żeby przezwyciężyć ten paradoks, trzeba modyfikować testy, ale też pisać nowe.
Ta zasada podkreśla potrzebę rozwijania przypadków testowych i strategii tak, żeby wykrywały nowe defekty w miarę rozwoju oprogramowania. Zachęca do ciągłego ulepszania pokrycia testami i ich skuteczności, dzięki czemu proces testowania się nie starzeje i nie traci sensu.
6. Testowanie zależy od kontekstu
Nie ma jednego podejścia do testowania, które pasuje do wszystkiego. W różnych kontekstach testuje się inaczej.
Uznanie, że różne środowiska i rodzaje oprogramowania wymagają różnych podejść do testowania, sprawia, że strategia jest dopasowana do konkretnych potrzeb i ryzyk projektu. Ta elastyczność zwiększa dokładność i skuteczność testów.
7. Przekonanie, że brak błędów oznacza sukces, jest błędem
fallacy - pogląd, który wielu ludzi uważa za prawdziwy, a który w rzeczywistości jest fałszywy
Błędem jest oczekiwanie, że weryfikacja oprogramowania zapewni sukces systemu. Nie da się tu przetestować wszystkiego do końca, nawet jako testerzy nie możemy udowodnić braku błędów, więc mimo wielu przeprowadzonych testów nie możemy powiedzieć, że oprogramowanie nie zawiera żadnych błędów.
Ta zasada jest kluczowa, żeby dopasować wysiłki zespołu deweloperskiego do realnych potrzeb i oczekiwań użytkowników. Przesuwa uwagę z samego wyszukiwania defektów na tworzenie produktu, który dostarcza użytkownikom wartość, promując projektowanie i rozwój zorientowane na użytkownika.
Razem te zasady pomagają zespołowi testowemu i deweloperskiemu tworzyć bardziej niezawodne, wydajne i zorientowane na użytkownika produkty. Wspierają strategiczne planowanie, wdrażanie i ciągłe doskonalenie procesów testowych, dopasowując je do nadrzędnych celów projektu i organizacji.
