Czy oprogramowanie jest gotowe do testów? Heurystyki Jamesa Bacha

 

Heurystyki testowalności oprogramowania to rodzaj listy kontrolnej pozwalającej nam zdefiniować czy jesteśmy gotowi do testowania oprogramowania. Jest to również informacja dla wytwórców oprogramowania czy dostarczyli nam wystarczających podstaw do testów.

 

Poniższy tekst jest tłumaczeniem pracy Jamesa Bacha (Satisfice, Inc.) dostępnej na stronie: http://www.satisfice.com/tools/testable.pdf

Kontrolowalność (Controllability) – im lepiej kontrolujemy oprogramowanie, tym więcej możemy zautomatyzować i zoptymalizować.

• Istnieje możliwy do oskryptowania interfejs lub środowisko testowe umożliwiające sterowanie testowanym oprogramowaniem.
• Stany oprogramowania, stany sprzętu i zmienne mogą być kontrolowane przez testera. 
• Moduły, obiekty, warstwy funkcjonalne oprogramowania mogą być testowane oddzielnie.

Obserwowalność (Observability) – co widzimy jest tym, co może być przetestowane.

• Wcześniejsze stany systemu i zmiennych są widoczne lub możliwe do znalezienia (np. logi transakcji).
• Zróżnicowany wynik jest generowany dla każdej informacji wejściowej.
• Stany systemu i zmienne są widoczne lub możliwe do wyszukania podczas uruchamiania testów.
• Wszystkie czynniki wpływające na wynik są widoczne.
• Niepoprawny wynik jest łatwy do zidentyfikowania.
• Wewnętrzne błędy są automatycznie wychwytywane i raportowane poprzez samotestujący mechanizm.

Dostępność (Availability) - aby testować, musimy mieć gotowy obiekt testów.

• System ma niewiele defektów.
• Błędy nie blokują uruchamiania testów.
• Produkt jest rozwijany w cyklach funkcjonalnych (co pozwala na jednoczesne tworzenie oprogramowania i jego testowanie).
• Istnieje dostęp do kodu źródłowego.

Prostota (Simplicity) - im prostsze oprogramowanie, tym mniej testów.

• Projekt oprogramowania jest wewnętrznie spójny.
• Aplikacja jest prosta funkcjonalnie (np. minimalna ilość funkcjonalności, aby spełnić wymagania).
• Aplikacja jest prosta strukturalnie (np. moduły są spójne i luźno sprzężone).
• Kod jest prosty (na tyle prosty, że zewnętrzny obserwator może go efektywnie zrewidować).

Stabilność (Stability) - im mniej zmian, tym mniej problemów w testowaniu.

• Zmiany w oprogramowaniu nie są częste. 
• Zmiany w oprogramowaniu są kontrolowane i komunikowane. 
• Zmiany w oprogramowaniu nie powodują konieczności zmiany automatów testowych. 

Informacja (Information) - im więcej informacji mamy, tym mądrzej testujemy.

• Projekt oprogramowania jest podobny do innych produktów, które już znamy.
• Technologia użyta do wytworzenia produktu jest możliwa do zrozumienia (w skończonym czasie - przyp. red.).
• Zależności pomiędzy wewnętrznymi, zewnętrznymi i współdzielonymi komponentami są możliwe do zrozumienia.
• Cel działania oprogramowania jest zrozumiały.
• Użytkownicy oprogramowania mogą być łatwo zrozumiani.
• Środowisko, w którym aplikacja będzie używana jest zrozumiałe. 
• Dokumentacja techniczna jest dokładna i dostępna.

 

 

 

Najbliższe terminy szkoleń

Partnerzy

Narzędzia testerskie