Siedem zasad testowania | Co oznaczają?

Czym jest siedem zasad testowania oprogramowania?

Są to zasady, które zostały zebrane i ustanowione wraz z rozwojem testowania i rozwojem oprogramowania przez ISTQB. Są uznawane za absolutną podstawę testowania.

Więc jeśli zajmujesz się jakimkolwiek aspektem testowania oprogramowania, warto w pełni przejrzeć i zrozumieć te standardy. Dzięki temu sprawdzisz czy przestrzegasz ich w swojej organizacji, ponieważ pomogą Ci one osiągnąć wysokie standardy jakości i dadzą Twoim klientom pewność, że oprogramowanie jest gotowe do wdrożenia produkcyjnego.

1. TESTOWANIE UJAWNIA USTERKI, ALE NIE MOŻE DOWIEŚĆ ICH BRAKU

Testujemy oprogramowanie w celu wykrycia problemów, aby można było je naprawić przed wdrożeniem produkcyjnym – dzięki temu mamy pewność, że nasz system działa zgodnie z oczekiwaniami. Jednak ten proces testowania nie potwierdza, że jakiekolwiek oprogramowanie jest całkowicie pozbawione defektów. Oczywiście! Testowanie pomaga znacznie zmniejszyć liczbę nieodkrytych defektów ukrytych w oprogramowaniu, ale znalezienie i rozwiązanie tych problemów nie jest samo w sobie dowodem, że oprogramowanie lub system jest w 100% od nich wolny. Ta zasada powinna być zawsze akceptowana przez zespoły i należy dołożyć starań, aby sprostać oczekiwaniom klientów.

2. TESTOWANIE GRUNTOWNE JEST NIEMOŻLIWE

Niemożliwe jest przetestowanie WSZYSTKIEGO – wszystkich kombinacji danych wejściowych i warunków wstępnych w oprogramowaniu. Dodatkowo sama próba zrobienia tego nie jest efektywnym wykorzystaniem czasu i budżetu. Wyobraźmy sobie, że w naszym testowanym oprogramowaniu mamy pole numeryczne, które przyjmuje dowolne liczby. Przetestowanie wszystkich kombinacji jest niemożliwe 🙂 Dlatego ważne jest aby dobrze zaplanować testy i skierować nasze wysiłki na te istotne elementy oprogramowania. Dzięki starannemu planowaniu i ocenie, pokrycie testami może pozostać doskonałe i zapewnić niezbędne zaufanie do oprogramowania, bez konieczności testowania każdego wiersza kodu.

3. WCZESNE TESTOWANIE OSZCZĘDZA CZAS I PIENIĄDZE

Wczesne testowanie ma fundamentalne znaczenie w cyklu wytwarzania oprogramowania. Może ono być wręcz wymagane w naszej organizacji. Przetestowanie samych założeń projektowych, dokumentacji przed rozpoczęciem kodowania i naprawienie znalezionego błędu będzie o wiele łatwiejsze i tańsze.

Wczesne testowanie jest również podstawową zasadą Agile, która postrzega testowanie jako czynność przez cały czas, a nie fazę (która w tradycyjnym podejściu kaskadowym byłaby na końcu).

4. KUMULOWANIE SIĘ DEFEKTÓW

Jest to zasada informująca nas o tym, że niektóre komponenty lub moduły oprogramowania zwykle zawierają najwięcej defektów lub są odpowiedzialne za większość awarii w wytwarzanym oprogramowaniu. Dlatego testowanie powinno być skoncentrowane właśnie na tych obszarach (proporcjonalnie do oczekiwanej – i później obserwowanej – gęstości defektów w tych obszarach).

Dzieje się tak szczególnie w przypadku dużych i złożonych systemów, ale gęstość defektów może być różna z wielu powodów. Defekty nie są równomiernie rozłożone w całym systemie, a im bardziej skomplikowany komponent lub im więcej jest zależności od stron trzecich, tym większe prawdopodobieństwo wystąpienia defektów.

Wiedza o tym może okazać się bardzo cenna dla twoich testów; jeśli znajdziemy jeden defekt w konkretnym module/obszarze, istnieje duża szansa, że odkryjemy tam o wiele więcej.

5. PARADOKS PESTYCYDÓW

Jeśli te same testy są wykonywane w sposób ciągły, to – chociaż mogą potwierdzić, że oprogramowanie działa (nie pojawiły się, żadne defekty) – w końcu nie znajdą nowych problemów. Ważne jest, aby stale przeglądać swoje testy i je modyfikować.

6. TESTOWANIE ZALEŻY OD KONTEKSTU

Metody i rodzaje przeprowadzanych testów mogą całkowicie zależeć od kontekstu oprogramowania lub systemów – na przykład sklep e-commerce może wymagać różnego rodzaju testów i podejść do testowania w porównaniu z interfejsem API. To, co testujesz, zawsze będzie miało wpływ na Twoje podejście.

7. PRZEKONANIE O BRAKU BŁĘDÓW JEST BŁĘDEM

Jeśli Twoje oprogramowanie lub system nie nadaje się do użytku (lub nie spełnia potrzeb użytkowników), to nie ma znaczenia, ile usterek zostanie znalezionych i naprawionych – nadal nie nadaje się do użytku. Innymi słowy nie ma znaczenia, jak wolny od defektów jest Twój system, jeśli użyteczność jest tak słaba, że użytkownicy nie są w stanie nawet poruszać się po oprogramowaniu.

Dlatego ważne jest, aby przeprowadzać testy, które są adekwatne do wymagań systemu. Powinieneś także testować swoje oprogramowanie z użytkownikami, aby zebrać informacje zwrotne, które można wykorzystać do zapewnienia i poprawy użyteczności. Pamiętaj, że mimo iż może wystąpić niewielka liczba defektów, nie oznacza to, że Twoje oprogramowanie nadaje się do wdrożenia produkcyjnego – spełnienie oczekiwań i wymagań klienta jest tak samo ważne, jak zapewnienie jakości.