Test jako weryfikacja specyfikacji

Test jako weryfikacja specyfikacji
Młodzieżowo-korporacyjne "czelendżowanie" można odnieść również do weryfikowania specyfikacji wymagań w ich dowolnej formie, poprzez pisanie testów.

Napisanie testu jest sprawdzeniem dokumentu opisującego zachowanie oprogramowania. Jeśli zrobione jest to w przemyślany sposób, wówczas tester ma możliwość, by ocenić jakość wymagania. Specyfikacja wymagań może być nośnikiem wielu defektów, a test (przypadek testowy) pozwala je ujawnić. Niemożność stworzenia jednoznacznego wymagania może być sygnałem, że również programiści mogą napotkać problem z budowaniem oprogramowania.

a. 

Wymaganie: "Aplikacja ma być szybka".
Test: "Uruchom aplikację -> sprawdź czy jest szybka".

Klasyczny przypadek testowy, gdzie w parze z wymaganiem nie idą żadne szczegóły, które pozwalają je zweryfikować. 
Możemy zaraportować błąd wymagania.
Możemy spróbować zaproponować interpretację dla "szybko".
Test: "Uruchom aplikację -> sprawdź czy odpowiada w czasie poniżej 1s.".

b. 

Wymaganie: "Aplikacja ma działać bezawaryjnie 365 dni w roku, 7 dni w tygodniu, 24h na dobę".
Test: "Uruchom aplikację -> sprawdź czy będzie działać bez przerwy przez cały rok".

Tak. Rok obserwacji oprogramowania. Na jednej wersji. 
Wymaganie jest tak "ostre", że koszty testowania są niewspółmierne do możliwych korzyści. Który projekt może pozwolić sobie na to, aby po zakończeniu dewelopmentu testować niezawodność przez następne 365 dni? Prawdopodobnie jedynie krytyczne pod względem bezpieczeństwa. W każdym innym przypadku nie ma to sensu. Można zaraportować błąd wymagania.

c.

Wymaganie: "Aplikacja ma możliwość zakładania konta".
Test: "Uruchom aplikację -> załóż konto".

Pojawiające się pytania: "czy każdy może założyć konto? czy proces zakładania konta wymaga podania adresu e-mail? czy trzeba kliknąć link aktywacyjny?" i wiele innych sugerują, że nie jesteśmy w stanie zaprojektować dla takiego wymagania testu. Bardzo możliwe również, że programiści będą mieli problem z określeniem "jak to ma działać". 

Możemy zaraportować błąd, ale przez test możemy również zaproponować własną interpretację wymagania. Jednak tworząc takie przykłady, musimy potwierdzić je z jego autorem.
Test: "Uruchom aplikację -> przejdź do ekranu zakładania konta -> uzupełnij pola formularza -> kliknij link aktywacyjny -> zaloguj się w aplikacji".

Tester oprogramowania może klasycznie przeglądać wymagania, aby ujawnić ich problemy. Może również od razu przejść do tworzenia testów i potraktować ten proces jako weryfikację testowalności. 

To powinno Cię zainteresować