Szablon Planu Jakości

Kilka lat temu uczestniczyłam w szkoleniu ISTQB. Uważam, że prezentowana tam wiedza, schematy i procesy są bardzo sensowne - dlatego, że moja mentorka od początku mojej proacy pokazywała mi jak z nich korzystać.

Poniżej znajduje się schemat Planu Testów - my nazwaliśmy go Planem Jakości Projektu. Dopracowaliśmy go, zautomatyzowaliśmy wypełnianie go w naszym systemie Redmine i wielokrotnie szkoliliśmy nasz zespół w sposobie jego wypełniania. Dlaczego wielokrotnie? Plan jest długi i podczas jego wypełniania trzeba przemyśleć wiele aspektów jakości projektu (a nie każdy chce i potrafi to zrobić).
Przemyśleć, sprawdzić, ustalić - to najważniejszy cel wypełniania Planu Jakości.
Manifest Agile (który bardzo cenię) stawia dokumentację i przestrzeganie planu na drugim miejscu - zgadzam się z tym całkowicie - nie wypełniajmy planu dla smego wypełniania i generowania niepotrzebnej dokumentacji. Wypełniamy tyle, ile trzeba, a myślimy o wszystkim bo od nas zależy Jakość w projekcie.

1. Identyfikator
2. Wstęp
1. autoryzacja projektu
2. plan projektu
3. plan QA
4. plan zarządzania konfiguracją
5. polityka testów
6. standardy testów
3. Przedmiot testów
1. specyfikacja wymagań
2. specyfikacja projektowania
3. instrukcja obsługi/instalacji/funkcji
4. Testowane funkcje
5. Nietestowane funkcje
6. Podejście do testów
7. Kryteria przejścia/niezaliczenia testów
8. Kryteria zawieszenia/wznowienia testów
9. Rezultaty testów
1. plan testów
2. specyfikacja projektów testowych
3. specyfikacja przypadków testowych
4. przekazanie przedmiotu testów
5. logi z testów
6. raport incydentu testowego
7. podsumowanie raportu testów
10. Testowane zadania
11. Niezbędne środowisko testowe
12. Odpowiedzialność
13. Zapotrzebowanie na personel i szkolenia
14. Harmonogram
15. Ryzyka i nieprzewidziane wydatki
16. Pozwolenia/zatwierdzenia

Android - testy wydania

Kilka dni temu wysłałam kolejną wersję aplikacji, jeszcze ciągle w wersji próbnej, testowej, w trakcie pracy. Ogólnie wydawałoby się - nic poważnego. Ale jednak wysłałam ją komuś - to jest poważne, powinnam być za to odpowiedzialna. Zrozumiałam, że nie zrobiłam jej wcześniej absolutnie podstawowych testów wydania. Nawet nie mam przygotowanych... Pora to zmienić.

Testy wydania aplikacji - android (ogólne)

1. Aplikacja aktualizuje się z poprzedniej wersji do nowej (update)
2. Aplikacja w aktualnej wersji może być zainstalowana na "czystym" urządzeniu (na takim, na którym nie jest zainstalowana) (instal)
3. Aplikacja po wybraniu ikony włącza się i pokazuje ekran startowy (start)
4. Aplikacja po wybraniu przycisku cofinij wyłącza się (end)
5. Aplikacja wykonuje podstawową funkcję (work)
6. Aplikacja aktualizuje się do poprzedniej wersji (downgrade)

Testy wydania aplikacji - android (dodatkowe)

1. Aplikacja działa bez internetu (internet permission)
1. brak wyjątków
2. informacja o braku połączenia
3. niezakłócone działanie
2. Aplikacja działa przy obracaniu ekranu (orientation)
1. dźwięk
2. obraz
3. funkcje
3. ...

Testowanie funkcjonalne - projektowanie przypadków użycia

Przypadek użycia - Use Case

 Co to takiego?

[ISTQB] 

przypadek użycia: Ciąg transakcji w dialogu pomiędzy użytkownikiem a systemem z namacalnym rezultatem

[WIKIPEDIA]

Przypadek użycia przedstawia interakcję pomiędzy aktorem (użytkownikiem systemu), który inicjuje zdarzenie oraz samym systemem jako sekwencję prostych kroków. 

[Z mojego doświadczenia]

Spis kolejnych czynności wykonywanych przez użytkownika i reakcji systemu odpowiadających tym czynnościom. Przypadki użycia są bardzo skuteczne do analizy wymagań funkcjonalnych i projektowania scenariuszy testowych.
W praktyce wspomnianym użytkownikiem nie musi być człowiek, może być urządzenie np. terminal płatniczy i kasa fiskalna.
Dokładność przypadków użycia powinna być dostosowana do potrzeb, zbyt dokładne odwracają uwagę od głównej funkcji (mogą również pokrywać się z testami na niższych poziomach), za mało szczegółowe mogą spowodować niedoprecyzowanie wymagań lub niewykrycie defektów. 

Kiedy stosować?

• Do projektowania przypadków i scenariuszy testowych
• Podczas analizy wymagań 
• Do analizy przypadków alternatywnych (w tym negatywnych)
• Do dokładnego opisania działania danej funkcji (mogą zastąpić lub uzupełnić zbiór wymagań funkcjonalnych) 
• Gdy analizujemy konkretną funkcję systemu

Jak do tego podejść?

1.  Opisz kolejne akcje które pojawią się po wywołaniu wybranej funkcji - wybierz główny, poprawny przebieg
2. Jeśli w opisie przebiegu głównego użytkownik musi podjąć jakąś decyzję, dopisz przebieg atlernatywny - taki, w którym wybór użytkownika pada na inną opcję
3. Powtórz krok 2 dla każdego wyboru użytkownika
4. Przejrzyj wszystkie zapisane przypadki użycia i określ przypadki negatywne - zastanów się co mogłoby się stać nie tak w dowolnym punkcie tych przypadków (np. urządzenie się wyłączy, nie będzie dostępu do internetu)