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

Czy oprogramowanie jest gotowe do testów? Heurystyki Jamesa Bacha
Heurystyki testowania oprogramowania to rodzaj list kontrolnych, pozwalających nam definiować i redefiniować obszary aplikacji i procesu wytwórczego bazując na dobrych praktykach. Taką heurytykę znajdziemy również w odniesieniu do gotowości oprogramowania do bycia przetestowanym.

Poniższy tekst jest omówieniem pracy Jamesa Bacha (Satisfice, Inc.). Zdefiniował on cechy oprogramowania, których spełnienie potwierdza gotowość oprogramowania do testów.
 

Oprogramowanie przekazane do testów musi mieć następujące cechy:

Kontrolowalność (Controllability) – jako testerzy 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.

 

James Bach wyróżnia również 5 obszarów testowalności i o nich możecie poczytać w jego publikacji >>

Dowiedz się więcej o heurystykach >>

 

 

To powinno Cię zainteresować