Testowanie Gier - Lista 4
===
###### tags: `TG`
[TOC]

## Treść zadania i dodatkowe informacje

Dla gry z zadania nr 2, dla której tworzyli Państwo historyjki użytkownika i scenariusze przypadków użycia należy założyć, że została dodana nowa funkcjonalność. Proszę ją opisać, a nastepnie **opracować proces testowy, obejmujący oprócz testowania nowej funkcjonalności testy regresji sprawdzające spełnienie (po wprowadzonym rozszerzeniu funkcjonalności) dotychczasowych wymagań funkcjonalnych i niefunkcjonalnych.**

***Uwaga:** Na początku należy zidentyfikować podstawowe wymagania funkcjonalne i niefunkcjonalne dotyczące tej gry. Następnie trzeba opisać, stosując znane techniki: historyjki użytkownika, scenariusze przypadków testowych nową funkcjonalność.*

Dokument powinien zawierać następujące punkty wynikające z czynności procesu testowego:
* planowanie i nadzór nad testami,
* analiza testów,
* projektowanie testów,
* implementacja testów,
* wykonanie testów,
* ocena kryteriów zakończenia i raportowanie,
* czynności zamykające test.

Opisując proces testowy należy m in przedstawić:
* strategie testowania,
* podejście do testowania,
* cele testowania,
* podstawę testów,
* podstawowe warunki testowe (co będzie testowane?),
* dla nowych scenariuszy przypadków użycia zaprojektować przypadki testowe,
* dla 3,4 wymagań niefunkcjonalnych zaprojektować przypadki testowe.

*Wiedza dot. procesu testowego jest upubliczniona na slajdach w wykładów, które są dostępne w systemie **MS Teams**, oraz w książce Adama Romana pt Testowanie i jakość oprogramowania.*

## Krótkie przypomnienie
:::success
W zadaniu z listy nr 2, trzeba było wybrać grę, a następnie opisać jej trzy funkcje w postaci historyjek użytkownika i związane z nimi scenariusze przypadków użycia.

Wybrałyśmy grę [**POU**](https://www.gry.pl/gra/pou).
Rozwiązanie zadania z listy nr 2 można znaleźć [**tutaj**](https://hackmd.io/vB3jYZ69Que8L59hsWZoQQ).
:::

## Nowa funkcjonalność
:::success
Gra zawiera wiele mini gierek. Nowa funkcjonalność to nowa minigierka (np. Sudoku, warcaby).
:::

### Wymagania funkcjonalne
:::success
* Czy gra znajduje się w tym samym miejscu co inne mini gry?
* Czy po wygraniu dostajemy punkty szczęścia?
:::

### Wymagania niefunkcjonalne
:::success
* Gra POU to gra na telefon, zatem wprowadzona aktualizacja musi działać na wszystkich dotychczasowych systemach (IOS, Android). Czy tak jest?
* Czy minigra włącza się tak samo szybko jak inne gry?
* Czy gra jest spójna kolorystycznie? Dopasowuje się do rozdzielczości ekranu?
:::

## Proces testowy
### Planowanie i nadzór nad testami
:::success
**(Na podstawie slajdu 17)**
#### Cel testów
Celem testów jest sprawdzenie, czy nowo dodana gra nie posiada błędów logicznych (rozgrywka przebiera według zasad), oraz czy jest ona kompatybilna z resztą aplikacji, czyli czy interakcja między całą aplikacją i minigrą jest taka, jak oczekiwano.

#### Planowanie testów - system
Do wykonania testów będziemy potrzebowali różne modele telefonów komórkowych z różnymi systemami operacyjnymi (Android, IOS...). Osoby testujące to zarówno dorośli jak i dzieci (pod obserwacją dorosłych), które stanowią największą grupę użytkowników aplikacji.

#### Planowanie testów - przebieg
Dla każdego telefonu (model + system operacyjny) będziemy potrzebowali conajmniej 2 osoby testujące, a w przypadku wykrycia problemów liczba ta zostanie zwiększona. Każdy z użytkowników będzie miał za zadanie wykonanie testów z dwóch kategorii: określonej sekwencji ruchów, jak też "zwykłego" pogrania. Testy będą się dzieliły na dwa rodzaje - takie w których użytkownik będzie grał z systemem (solo game) jak i w trybie mulitiplayer.

#### Planowanie testów, nadzór nad testami
Ilość testów będzie zależna od liczby występujących błędów. Jeśli podczas przebiegu 10 rozgrywek nie wystąpił żaden problem, to będziemy uznawali, że test przebiegł pomyślnie. Jeśli natomiast będą pojawiały się błędy, to rozgrywka dla danego telefonu liczba testów zostanie zwiększona i uszczcegółowiona.

Proces testowania będzie się odbywał według naturalnej kolejności rozpoczęcia rozgrywki. Najpierw zostaną sprawdzone możliwości dołączenia do rozgrywki, następnie rozpoczęcie, rozgrywka i zakończenie.

**(na podstawie slajdu 22)**
#### Nadzór nad testami - raport
Raporty z przebiegu testów powinny być składane po każdej rozgrywce, niezależnie czy wykryto błędy, czy nie. Powinno się w niech znajdować możliwie szczegółowy opis wejścia do rozgrywki jak i jej przebieg, zakończenie, oraz obserwacje. Do raportu powinien być umieszczony stream z przebiegu testu, aby można było dokładnie sprawdzić warunki wystąpienia błędu.

#### Porównywanie uzyskiwanych rezultatów z oczekiwanymi
Testy będą oceniane w sposób bardzo klarowny:
* działa
* nie działa to co jest tematem testu
* nie działa to co nie jest tematem testu
(Wyjaśnienie: testujemy przebieg rozgrywki, jeśli sama rozgrywka przebiega prawidłowo, ale np kasuje nam monety (co nie powinno mieć miejsca) to wynikiem testu jest *nie działa to co nie jest tematem testu*, jeśli natomiast zauważonoby problemy z samą rozgrywką, to wynikiem testu byłoby *nie działa to co jest tematem testu*)
:::

:::warning
**(na podstawie slajdu 11**)
**Przykładowa lista kontrolna dla planowania testów**
Czy:
* zdefiniowano strategie testowania?
* opracowano podejście do testowana dla danego systemu/platformy?
* ogólnie określono poziomy, kategorie, rodzaj i ilość testów?
* określono zasoby, tj. budżet, czas, narządzia testowania, ilość testerów?
* sporządzono plan i harmonogram testowania?

**Przykładowa lista kontrolna dla monitorowania i nadzoru**
Czy:
* zaplanowano odniesienie stanu czynności i produktów testowania do podstawy testów w sposób zrozumiały i odpowiedni dla interesariuszy?
* zaplanowano definiowanie celów i pomiar zaawansowania prac w oparciu o warunki testowe i grupy warunków testowych?
* zaplanowano metryki zrozumiałe dla interesariuszy?
* wyznaczono osoby odpowiedzialne za pomiar i udostępnianie wartości metryk oraz tworzenie i udostępnianie raportów?
* wyznaczono harmonogram dokonywania pomiarów i tworzenia raportów?
---

Jeśli podejdziemy do analizy tego punktu bardziej technicznie, to tak naprawdę sprawdzana (testowana) jest grywalność, na podstawie historyjek użytkownika.

Testerzy analizują i poprawiają historyjki użytkownika, aby zepewnić płynną oraz zgodną z oczekiwaniami rozgrywkę. Co więcej analizowany i testowanay jest przebieg rozgrywki (wstępnie i finalnie) również pod względem zgodności wersji na wielu rówżnych platformach. Sam kod jest testowany i poprawiany pod kątem poprawności i czytelności.

**Wynikajace z tej strategii *podejście do testowania***
Aby zagwarantować poprawność kodu:
* dokonuje się przeglądu kodu i zleca jego poprawę czytelności,
* wykonuje testy jednostkowe,
* wykonuj się testy integracyjne
* każda wykryta usterka, wymaga analizy i nowych testów

**Cele - kryteria zakończenia - przykłady:**
* przeprowadzenie testów wszystkich historyjek użytkownika, oraz testów akceptcyjnych
* zadowolenie klienta z rozgrywki
* osiągnięcie pokrycia kodu 90% w testach, oraz zapewnienie dobrych powiązań między komponentami aplikacji 100%
* osiągnięcie zadowalających wyników testów dotyczących wymagań niefunkcjonalnych i funkcjonalnych
:::

### Analiza testów
:::warning
**(na podstawie slajdu 24, 32)**
**Przykład listy kontrolnej dla analizy testów**
Czy:
* określono podstawę testów, co nią jest?
* podstawa testów jest jednoznaczna i testowalna?
* historyjki użytkownika spełniają warunki INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable)?
* w szczególności określono poprawność wprowadzanych danych, dokonywanych obliczeń, poprawności wyprowadzonych danych?
* określono warunki testowe?
* określono powiązania między elementami podstawy testów a warunkami testowymi?

Kierownik testów monitoruje wykonywane podczas analizy czynności i prowadzi działania korygujące

**Co jest również ważne - analiza testów i ich poziom szczegółowości**

Czynniki, które należy wziąć pod uwagę podejmując decyzję o poziomie szczegółowości, na którym będą określane warunki testowe, obejmują:
* Złożoność systemu/oprogramowania
* Ryzyko projektowe i ryzyko produktowe
* Związek pomiędzy podstawą testów, tym, co należy przetestować i sposobem, w jaki należy to przetestować
* Zastosowany cykl życia wytwarzania oprogramowania
* Stosowane narzędzie do zarządzania testami
* Poziom, na którym należy sprecyzować i udokumentować projektowanie testów i inne produkty testowania
* Umiejętności i wiedzę analityków testowych
* Poziom dojrzałości procesu testowego i organizacji (należy zauważyć, że wyższy poziom dojrzałości może wymagać większego poziomu szczegółowości lub dopuścić jej niższy poziom)
* Dostępność innych interesariuszy projektu w celu konsultacji

---
***Analizę testów dla danego poziomu testowania można przeprowadzić, jak zostanie ustalona podstawa testów tylko dla tego poziomu, zatem...***

Historyjki użytkownika są podstawą, muszą być na tyle dobre, aby mogły pokrywać wszelkie możliwe scenariusze obsługi aplikacji.

Można sprawdzić czy ustawienia rozgrywki są prawidłowo zaimplementowane. Określone warunki testowe funkcjonaności (czy to tej nowej, czy również tych wcześniej zaimplemantowanych) i wymagania (funkcjonalne i niefunkcjonalne) muszą być zdatne do testowania, aby te same testy dawały zawsze oczekiwany rezultat.

**Warto wspomnieć, że szczegółowe definiowanie warunków testowych niesie z sobą korzyści, tj.:**
* Pomaga kształtować i wpływać nie tylko na inne czynności z zakresu testowania, ale także na czynności z zakresu wytwarzania oprogramowania.
* Ułatwia projektowanie, implementację i wykonanie testów, wraz z wynikowymi produktami, które będą optymalizowane przez bardziej efektywne pokrycie szczegółowych miar i celów.
* Daje podstawę do łatwiejszego poziomego śledzenia w ramach poziomu testów.

Trzeba jednak pamiętać, że mają też wady, związane z potencjalną czasochłonnością, trudnością w utrzymaniu w ciągle zmieniającym się środowisku. A co więcej poziom formalizmów powinien być zdefinowany i funkcjonować w całym zespole.
:::

### Projektowanie testów
:::success
**(na podstawie slajdu 36)**
Jak wyżej pisałyśmy testy będą przeprowadzane zarówno przez dzieci (grupę docelową) pod nadzorem opiekunów, jak też przez grupę zawodowych testerów.
Obie grupy będą przeprowadzały rozgrywki w sposób losowy jak też w sposób dokładnie określony przez scenariusz.

#### Przypadki testowe
Testy będą się dzieliły na kolejne grupy, w których będziemy testowali poniżej wymienione funkcjonalności:
1. Wejście do rozgrywki
W tej grupie zostaną sprawdzone wszystkie możliwości wejścia do rozgrywki, jak też możliwe ustawienia startowe, takie jak gra z kolegą/komputerem, czy wybranie koloru planszy.
2. Rozpoczęcie rozgrywki
Sprawdzimy z jakim ppb zostanie przydzielony pierwszy ruch. Czy gracze poruszają się "przemiennie".
3. Rozgrywka
Zostanie sprawdzone, czy gracze nie mogą wyjść poza plansze. Czy jest możłiwe kantowanie, przywrócenie pionka do gry i nielegalne ruchy. Zostanie też sprawdzone, czy wszsytkie dopuszczalne ruchy są możliwe.
4. Zakończenie rozgrywki
Zostanie sprawdzone, co dzieje się podczas zakończenia rozgrywki. Czy dobry gracz wygrywa, czy system informuje o braku możliwych ruchów (pat). Czy prawidłowo zostają przyznane punkty. Co się dzieje podczas zakończenia rozgrywki, kiedy są mozliwe ruchy.
:::

:::warning
**Przykład listy kontrolnej dla projektowania testów:**
Czy dla wszystkich elementów warunków testowych i podstawy testów zaprojektowano testy?
W szczególności czy:
* zaplanowany testy dla wszystkich ról i wszystkich występujących na ekranach funkcji menu ?
* określono co i jak będzie sprawdzane podczas przeglądów kodu?
* zaprojektowano testy dot. wymagań niefunkcjonalnych?
* opracowano zawartość ankiet ankiet dot. użyteczności?
* zaprojektowano testy sprawdzających warunki określone w umowach SLA?

---

Należy upewnić się, że wszystkie warunki testowe oraz podstawy testów zostały pokryte. Każda nowo wporowadzona funkcjonalność (w tym przypadku u nas jest to dodanie nowej minigierki) ma i musi mieć zaplanowne testy, zasady sprawdzania kodu. Wymagane jest również zadbanie o czytelność kodu, a wymagania niefunkcjonalne jak i funkcjonalne są pokryte testami.
:::

### Implementacja testów
:::success
Adnotacja jak w przypadkach testowych:
1. Wejście do rozgrywki
* Wejście do rozgrywki przez pokój gier -> wejście w multiplayer ze znajomym
* Wejście do rozgrywki przez pokój gier -> wejście w multiplayer z obcym
* Wejście do rozgrywki przez pokój gier -> wejście w singleplayer
2. Rozpoczęcie rozgrywki
* Sprawdzenie czy poprawna osoba zaczyna rozgrywkę
* Sprawdzenie poprawności ruchów pionków (czy poruszają się tak jak tego oczekujemy)
3. Rozgrywka
* sprawdzenie czy gracze poruszają się naprzemiennie
* próba ruchu w momencie ruchu przeciwnika
* sprawdzenie, czy można wyjść poza planszę
4. Zakończenie rozgrywki
* Sprawdzenie czy po zakończonej rozgrywce możliwy jest ruch
* Sprawdzenie czy odpowiedni gracz wygrał
* Sprawdzenie remisu, czyli gdy żaden z graczy nie może się poruszyć
* Sprawdzenie, czy odpowiedni gracz otrzymał punkty zwycięstwa
* Sprawdzenie czy punkty zwycięstwa są przyznawane w odpowiedniej wysokości

Wyniki testów będą przechowywane jako pary - film, opis. W poprzednich działach zostało dokładnie wyjaśnione co będą one zawierały.

Testy będą spisane w formie scenariuszy - listy kroków, które testerzy będą muslieli ręcznie wykonać. Należy się upewnić, czy rozumieją oni wszystkie scenariusze.

Sprzęt będzie przygotowywany przez oddzielny zespół, którego zadaniem będzie przygotowanie na telefonach odpowiedniego obrazu systemu operacyjnego, oraz zainstalowanie gry.
:::

:::warning
**Implementacja testów = przygotowanie wykonywania testów**

*W kontekstach formalnie udokumentowanych przypadków testowych, implementacja testów jest działaniem, w ramach którego wdraża się projekty testów jako konkretne przypadki testowe, procedury testowe i dane testowe.*

---
Przykłady:
* Czy wszystkie testy aplikacji (te jednostkowe i integracyjne też) zostały zaimplemantowane?
* Czy sam kod jest odpowiednio napisany i zawiera serwery testowe?
* Czy działa automatyczne uruchamienie testów (czy istnieją odpowiadające za to skrypty)?
:::

### Wykonanie testów
:::success
Wykonanie testów zostało częściowo omówione w poprzednim paragrafie

**(na podstawie slajdu 47)**
Wykonywanie testów będzie nadzorowane przez wyznaczoną do tego osobę. Jej zadaniem będzie sprawdzanie, czy sprzęt został odpowiednio przygotowany, sprawdzenie losowo wybranych testów, oraz pilnowanie, aby każdy był odpowiednio dokumentowany.

Piorytety testów będą tym wyższe, im częście będzie wykrywany błąd w danym obszarze testowym.
:::

:::warning
Wykonywanie testów rozpoczyna się po dostarczeniu przedmiotu testów i spełnieniu kryteriów wejściowych do wykonania testów.

Kryteria wejścia zwykle mogą zawierać następujące zagadnienia:
* dostępność i gotowość środowiska testowego,
* gotowość narzędzi testowych w środowisku testowym,
* dostępność testowalnego kodu,
* dostępność danych testowych.

**Przykład listy kontrolnej dla wykonania testów**
Czy:
* spełniono warunki wstępne do wykonywania testów ?
* testy wykonywanie są zgodnie z harmonogramem?
* metryki testów są przesyłane, gromadzone i analizowane?

---

Dostępne narzędzia posłużą do uruchomienia zaprojektowanych testów.
Otrzymane rezultaty pomogą określić czy wszystko działa jak powinno, w razie ewentualnych błędów zostanie zwrócona informacje o danym niedziałającym elemencie i dotyczącym go teście.
Do przebiegu samych testów posłużą nam opisane już wcześniej w rozwiązaniu listy nr 2 przypadki testowe. Te brakujące również zostaną wzięte pod uwagę i będą pokryte.
Cały proces będzie kontrolowany przez kierownika ds. testowania, którego zadaniem jest monitorowanie postępu prac zgodnie z wcześniej przygotowanym planem, zadbanie aby otrzymane wyniki zostały przeanalizowane i w razie potrzeby zostały przeprowadzone czynności do pomyślnego zakończenia.

Warto spojrzeć również na powyższą **listę kontrolną dla wykonania testów**, która będzie wykonywana dla każdej serii testów.

:::

### Ocena kryteriów zakończenia i raportowanie
:::success
Testy w danej wersji programu zostaną zakończone w momencie, gdy zostaną wykonane wszystkie przypadki testowe. Testy zostaną zakońćzone w momencie gry wszystkie zakończą się skucesem, oraz nie będą wprowadzane żadne nowe poprawki dotyczące zarówno minigry, jak i elementów, które mogą mieć wpływ na jej poprawne działanie.
Raportowanie będzie się odbywało w taki sposób w jaki pisałyśmy powyżej.

Możliwe będzie zakończenie kolejnych faz testów osobno, ponieważ nie mają one ze sobą związku. Aby zakończyć testy, trzeba będzie pomyślnie zakończyć każdą z faz.

#### Metryki
W każdym z przypadków testowych dla kolejnej poprawki będziemy mierzyli procentową ilość defektów (liczba testów zakończonych porażką / liczba testów).
Kolejan miara będzie się odnosiła do ilośći wykonanych przypadków testowych w czasie. Tzn ile jeszcze testów musimy wykonać, aby zakońćzyć testy.
:::

:::warning
**Typowo kryteria zakończenia mogą składać się z:**
* miar staranności, takich jak pokrycie kodu, funkcjonalności lub ryzyka,
* estymat gęstości błędów lub miar niezawodności,
* kosztu,
* istniejącego ryzyka, takiego jak niepoprawione usterki lub brak pokrycia pewnych obszarów,
* harmonogramów np. zdefiniowanych na podstawie czasu pozostałego do wypuszczenia produktu na rynek.

---
* Metryki testowania można sklasyfikować, jako należące do jednej lub więcej następujących kategorii:
* Metryki procesowe, które mierzą wydajność procesu testowania lub rozwoju oprogramowania, takie jak odsetek defektów wykrytych przez testowanie.
* Metryki osobowe, które mierzą wydajność poszczególnych osób lub grup, takie jak implementacja przypadków testowych zgodnie z harmonogramem.
* Każda metryka może należeć do dwóch, trzech, a nawet czterech kategorii.

Stosowanie metryk umożliwia testerom raportowanie wyników w sposób spójny i umożliwia spójne śledzenie postępów w czasie.

**Kierownik Testów musi w szczególności wziąć pod uwagę następujące kwestie:**
* Definiowanie metryk
* Śledzenie metryk
* Raportowanie i interpretacja metryk
* Wiarygodność metryk

**Postęp testów monitorowany jest w pięciu podstawowych wymiarach:**
* ryzyka produktowe (jakości),
* defekty,
* testy,
* pokrycie,
* zaufanie.

**Czy zdefiniowane metryki są:**
* czytelne?
* śledzone?
* raportowane i właściwie interpretowane ?
* wiarygodne?
Czy osiągnięto kryteria zakończenia (cele) testowania?

---

Nieco inaczej...
Należy zadbać o dobranie dobrych metryk. Jest to bardzo ważne podczas oceny kryterów i raportowania.
Dzięki dobrej metryce można określić postęp podczas procesu rozwoju aplikacji (tutaj akurat gry POU), np. w jakim stopniu istnieje pokrycie z testami.
Nasze metryki powininy dostarczać szczegółowe informacje o testach, jaki obszar obejmują, a także jakie błędy tam występują.

Warto zadbać o to, aby posługiwać nie nie zbyt dużą liczbą metryk, ale zadbać o czytelność, jednak powinny dostarczać odpowiednią ilość potrzebnych informacji.

:::

### Czynności zamykające test
:::warning
Czynności zamykające testowanie w sensie ogólnym, są to czynności związane z zakończeniem testów. Po stwierdzeniu ukończenia testowania, należy zapisać kluczowe dane wyjściowe z procesu testowania i przekazać je właściwej osobie lub zarchiwizować.

**Czynności te dzielą się na cztery główne grupy:**
* Kontrola zakończenia testowania
* Przekazanie artefaktów testowania
* Wyciągnięte wnioski
* Archiwizacja rezultatów, dzienników, raportów i innych dokumentów i produktów w systemie zarządzania konfiguracją.

Dla przykładu, należy sie zastanowić czy nastąpiły:
* kontrola zakończenia testowania,
* przekazanie artefaktów testowania,
* analiza i wyciągnięte wnioski,
* archiwizacja rezultatów, dzienników, raportów i innych dokumentów i produktów w systemie zarządzania konfiguracją.

---

Innymi słowy, należy zadbać, aby:
* Każda znaleziona usterka została naprawiona i przetestowana
* Elementy, które są niemożliwe do zrealizowania powinny być udokumentowane i pozostawione do możliwego zrealizowania w późniejszych wersjach gry
* Wyniki testów oraz informacje o samych testach zostały przekazane odpowiedniej grupie zajmującej się utrzymaniem gry
* Opisane testy, usterki i wymagania dotyczące testów były wystarczające, tzn. takie aby nie spowalniały postępów w pracach zespołu
* Wszystko zostało poprawienie zapisane (rezultaty, raporty porcesu testowego) dla kolejnych wersji gry
:::

## Podsumowanie
:::success
**STRATEGIE I PODEJŚCIE DO TESTOWANIA**
Grupą testerów będą użytkownicy aplikacji - dzieci. Będą one wykonywały testy pod nadzorem obserwatorów, których zadaniem będzie obserwacja i tworzenie raportów.
Testy będą przeprowadzane na różnych urządzeniach z różnymi systemami operacyjnymi.
****
**CELE TRSTOWANIA**
Cele testowania to:
* sprawdzenie czy rozgrywka przebiega poprawnie (nie można oszukiwać, użytkonicy nie wychodzą poza planszę, ruchy dozwolone są mozliwe do wykonania)
* sprawdzenie czy gra jest możliwa na wszystkich dotychczas obsługiwanych systemach operacyjnych
* sprawdzenie poprawnego oddziaływania gry na resztę aplikacji (dodanie gry nie popsuło innych fragmentów aplikacji)
****
**PODSTAWA TESTÓW**
Podstawą testów jest lista wswpieranych urządzeń mobilnych i oprogramowań.
****
**PODSTAWOWE WARUNKI TESTOWE**
Testowane będą fragmenty aplikacji, na które ma wpływ dodanie nowej minigry, tj: pokój z grami, wskaźnik szczęścia, jedzenia i zmęczenia, nowa minigra, czyli wszystkie miejsca, gdzie może wystąpić regrasja.
****
**NOWE SCENARIUSZE I PRZYPADKI TESTOWE**
W związku z nową funkcjonalnością pojawiają się nowe scenariusze użycia:

**Wynik gry**
1. Gracz wchodzi do pokoju rozgrywek
2. Gracz wybiera nową minigrę
3. Gracz wybiera rozgrywkę z komputerem
4. Gracz i komputer przemiennie wykonują ruchy
5. Gra się kończy
6. Zostają wyświetlone winiki gry

Tytuł: wynik gry
Środowisko: IOS, IPhone
Warunki wstępne: Otwarta aplikacja POU, użytkownik posiada już konto
Kroki wykonania: wejście do pokoju rozgrywek, wybranie nowej minigry, rozpoczęcie rozgrywki z kompurerem, wykonywanie kolejnych ruchów, doprowadzenie do zakończenia rozgrywki
Oczekiwany rezultat: informacja o wygranej użytkownika, jeśli ten zwyciężył, albo informacja o wygranej komputera, jeśli ten zwyciężył, wpp informacja o remisie.
Warunki końcowe: gracz jest zalogowany, znajduje się w pokoju rozgrywek, jeśli wygrał ma więcej monet, wpp liczba monet jest bez zmian

**Wykonanie dwóch ruchów pod rząd**
1. Gracz wchodzi do pokoju rozgrywek
2. Gracz wybiera nową minigrę
3. Gracz wybiera rozgrywkę z kolegą
4. Gracze przemiennie wykonują ruchy
5. Gracz nr 1. próbuje wykonać ruch dwókrotnie
6. Gra wyświetla komunikat o tym, że musi poczekać na swoją kolej

Tytuł: Wykonanie dwóch ruchów pod rząd
Środowisko: IOS, IPhone
Warunki wstępne: Otwarta aplikacja POU, użytkownik posiada już konto
Kroki wykonania: wejście do pokoju rozgrywek, wybranie nowej minigry, rozpoczęcie rozgrywki z kompurerem, wykonywanie kolejnych ruchów, wykonanie dwóch ruchów pod rząd
Oczekiwany rezultat: informacja o tym, że jest ruch przeciwnika, brak wykonania ruchu
Warunki końcowe: gracz jest zalogowany, jego pionki pozostają bez zmian

****
**DLA 3,4 WYMAGAŃ NIEFUNKCJONALNYCH ZAPROJEKTOWAĆ PRZYPADKI TESTOWE**

Gra POU to gra na telefon, zatem wprowadzona aktualizacja musi działać na wszystkich dotychczasowych systemach (IOS, Android). Czy tak jest?
1. Dla każdego wspieranego systemu powtórz:
1. Zainstaluj aplikację
2. Otwórz aplikację
3. Przejdź do zakładki minigry
4. Znajdź nową minigrę
5. Kliknij w obrazek minigry, aby w nią zagrać
6. Wybierz tryb solo/multiplayer
7. Zagraj w grę
8. Po zakończeniu rozgrywki wróć do zakładki minigry
9. Wyjdź z aplikacji

Czy nowa minigra włącza się tak samo szybko jak inne gry?
1. Zainstaluj aplikację
2. Otwórz aplikację
3. Przejdź do zakładki minigry
4. Znajdź nową minigrę
5. Włącz czasomierz
6. Kliknij w obrazek minigry, aby w nią zagrać
7. Zatrzymaj czasomierz
8. Powtórz punkty 2-7 kilkukrotnie (10 razy)
9. Porównaj otrzymane wyniki z czasami włączania innych minigier

Czy gra jest spójna kolorystycznie? Dopasowuje się do rozdzielczości ekranu?
1. Zainstaluj aplikację
2. Otwórz aplikację
3. Przejdź do zakładki minigry
4. Znajdź nową minigrę
5. Kliknij w obrazek minigry, aby w nią zagrać
6. Sprawdź czy nie zmieniła się rozdzielczość
:::