# Testowanie gier
## Zad 2 L1
### Heurystyki Nielsena
#### 1. Pokazuj status systemu
Strony internetowe lub specyficzne oprogramowania należy tworzyć z myślą o osobach, które nigdy wcześniej z nich nie korzystały – dla przykładu, tworząc sklep internetowy, na pewno masz na celu pozyskiwanie nowych klientów, którzy dokonają zakupu tylko wtedy, kiedy wejdą na prostą i intuicyjną ścieżkę zakupową i nic po drodze nie wzbudzi ich wątpliwości. Dlatego niezbędne jest to, aby użytkownik serwisu czy aplikacji zawsze był informowany o statusie akcji, którą podejmuje i co może dalej wykonać.

Do podstawowych elementów, które informują użytkownika o miejscu, w którym się znajduje oraz statusie podejmowanych akcji należą:

* znacznik title,
* nagłówek H1,
* oznaczenia aktywnych kategorii menu,
* breadcrumbs.
#### 2. Zachowaj zgodność pomiędzy systemem a rzeczywistością
W przypadku tej heurystyki chodzi przede wszystkim o unikanie żargonu, który będzie niezrozumiały dla użytkowników. Warto odpuścić sobie enigmatyczne określenia. Należy tłumaczyć skutek czynności, które wykonuje użytkownik serwisu w prosty i zrozumiały dla wszystkich sposób. Dotyczy to zarówno komunikatów słownych, jak i graficznych. Przykładem mogą być tutaj choćby muzyczne serwisy streamingowe, w których przyciski funkcji odtwarzacza odpowiadają tym, jakie są doskonale znane z używanych od dekad magnetofonów.

Użytkownik powinien czytać Twoją stronę jak otwartą książkę. Dlatego warto trzymać się przyjętych standardów, np. umieszczenia wewnętrznej wyszukiwarki po prawej stronie menu czy oznaczania linków niebieskim kolorem czcionki i podkreśleniem.

Bardzo ważne jest także informowanie użytkownika o tym, co się stanie po kliknięciu w dany element. Tutaj klasyczny przykładem jasnego informowania o skutku działania, są przyciski CTA, np. „Kup teraz”.

#### 3. Daj użytkownikowi pełną kontrolę
Użytkownicy serwisów internetowych czują się pewniej, jeśli mają pełną kontrolę nad tym, co robią w czasie wizyty na stronie. Dlatego powinni mieć możliwość swobodnych działań, np. łatwej zmiany kategorii sklepu, usunięcia produktów z koszyka czy rezygnacji z dalszych kroków na ścieżce zakupowej, czyli innymi słowy rezygnacji z zakupu.

Przed ostatecznym krokiem, czyli np. dokonaniem zakupu, użytkownik musi mieć jeszcze możliwość rezygnacji (najlepiej bez konieczności podawania przyczyny), a także musi zostać poinformowany, że podjęta w tym momencie czynność ma już charakter nieodwracalny – np. przycisk „Zamawiam z obowiązkiem zapłaty”.

#### 4. Trzymaj się standardów i zachowaj spójność
Musisz wziąć pod uwagę to, że użytkownicy serwisów internetowych lubią przyjęte rozwiązania i oczekują, że zostaną one zastosowane na wszystkich stronach, które odwiedzają. W tym kontekście Jakob Nielsen i Ralf Molich opracowali konwencję spójności zewnętrznej i wewnętrznej, dzięki którym użytkownicy serwisu nie będą musieli zastanawiać się nad każdym elementem strony, ale będą rozumieć je z automatu i korzystać z nich intuicyjnie.

Spójność zewnętrzna to ogólnie przyjęte standardy, które sprawdzają się niemal we wszystkich serwisach. Jej elementy to m.in.:

podlinkowanie do strony głównej logotypu, który umieszczony jest w lewym górnym rogu lub u góry na środku strony;
wyszukiwarka i symbol koszyka w prawym górnym rogu strony;
główne menu, umieszczone w górnej lub bocznej części strony, a na urządzeniu mobilnym po kliknięciu ikony trzech poziomych pasków.
Z kolei spójność wewnętrzna to utrzymanie w całym serwisie jednej konwencji stylistycznej, np. jednakowych fontów, spójnej kolorystyki, podświetleń przycisków po najechaniu na nie kursorem, umiejscowienia opisów czy sposobie informowania o następstwach czynności i błędach.

#### 5. Zapobiegaj błędom
Ta heurystyka ma pomóc w tym, aby możliwie najskuteczniej zapobiec popełnieniu błędu przez użytkownika strony. W tym celu stosuje się m.in. informacje o wyprzedaniu produktu lub braku dostępności wybranego wariantu (np. informacja „Wyprzedane” lub przycisk „Powiadom mnie o dostępności”). Bardzo ważne jest też ułatwienie w czasie wpisywania przez użytkownika wymaganych danych, np. poprzez przygotowanie formatek na wpisanie adresu, kodu pocztowego czy numeru telefonu.

#### 6. Pokaż, zamiast zmuszać do zapamiętania
Sklepy internetowe mają duże możliwości do tego, żeby móc skutecznie przypominać użytkownikom o działaniach, które zamierzali podjąć lub podjęli, ale z powodu wielu czynności mogli o nich zapomnieć. Dlatego warto jest umieszczać sekcje „Ostatnio przeglądane”, które pomogą szybko odnaleźć oglądane wcześniej produkty, których użytkownik nie kupił przy pierwszych odwiedzinach strony, ale zamierza to zrobić. Jest to szczególnie istotne, gdy użytkownik ma problem z ich ręcznym znalezieniem choćby ze względu na to, że zapomniał nazwy produktu, wyniki wyszukiwania uległy zmianom czy w sklepie nastąpiła zmiana struktury kategorii.

Pomocne są też podglądy koszyka – kupujący może sprawdzić, czy znajdują się w nim wszystkie produkty, które zamierza kupić bez wchodzenia do koszyka i wychodzenia z niego.

#### 7. Elastyczność i efektywność
Ta heurystyka Nielsena i Molicha to po prostu ułatwienie i skrócenie wykonywania wszystkich czynności w obrębie serwisu. Kilka funkcjonalnych przykładów to m. in.:
checkbox „Zaznacz wszystkie” przy wyrażeniu zgód;
możliwość skopiowania koszyka z ostatnich zakupów;
możliwość wybrania wielu filtrów i kliknięcia przycisku „Filtruj” zamiast automatycznego ładowania się filtrów po wybraniu każdego z osobna.
Szczególnie brak tego ostatniego ułatwienia potrafi być irytującym błędem UX. Załóżmy, że chcesz kupić białą, bawełnianą koszulę z długim rękawem i włoskim kołnierzem, w rozmiarze 40. Teraz wyobraź sobie, o ile szybciej wyświetlą Ci się produkty spełniające wszystkie warunki, kiedy zaznaczysz wszystkie filtry i klikniesz „Gotowe”, niż kiedy wyniki będą filtrowały się automatycznie za każdym razem po kliknięciu pięciu(!) filtrów (kolor, materiał, rękaw, typ kołnierzyka, rozmiar).

#### 8. Dbaj o estetykę i umiar
Tutaj w zasadzie można ograniczyć się do stwierdzenia „mniej znaczy więcej”. Formularze zamówienia czy rejestracji powinny zawierać jedynie najważniejsze informacje i niezbędne opcje, podane w estetycznej i przejrzystej formie.

#### 9. Zapewnij skuteczną obsługę błędów
Tutaj mamy nawiązanie do piątej heurystyki. Jeśli pomimo starań użytkownik popełnił błąd, należy mu go jasno wskazać i podpowiedzieć rozwiązanie. Przykładem będą tu jasne komunikaty, np. „Login XXX jest już zajęty” i sugerowanie wyboru loginu XXX11. Podobnie w przypadku haseł – jeśli hasło proponowane przez użytkownika nie spełnia warunków, warto jasno mu podpowiedzieć, co powinien do niego dodać, np. „Hasło musi zawierać dużą literę”.

#### 10. Zadbaj o pomoc i dokumentację
Nie w każdym interfejsie da się zastosować proste i intuicyjne rozwiązania. Niektóre systemy ze swojej natury będą bardziej złożone, w związku z czym użytkownik będzie potrzebował pomocy, np. samouczka, sekcji pomocowej czy rozbudowanej sekcji FAQ (najczęściej zadawanych pytań). Ważne jest, żeby sekcje te były przejrzyste i w klarowny sposób wyjaśniały problem. Dzięki temu użytkownicy łatwiej poradzą sobie z nim samodzielnie i nie będą musieli kontaktować się bezpośrednio z obsługą lub – czego żaden właściciel serwisu sobie nie życzy – zamykać strony.

## Ocena strony Testerzy.pl

### 1. Pokazuj status systemu
Wszystko poza sekcją usługi spełnia heurystykę w naszej opinii. Strona usług jest niejasna gdzie zaczynają się linki do konkretnych usług, a gdzie są po prostu elementy tła.

### 2. Zachowaj zgodność pomiędzy systemem a rzeczywistością
Strona spełnia tą heurystykę. Jedyne co może blokować uzytkowików w tej heurystyce to używanie niepotocznych słów jak "Akredytowany". Nie są to jednak słowa żargonowe.

### 3. Daj użytkownikowi pełną kontrolę
Nie da łatwo wycofać z możliwości rezerwacji szkolenia. Co daje nam problem gdy ktoś wejdzie tam przez przypadek.

### 4. Trzymaj się standardów i zachowaj spójność
Strona spełnia tą heurystykę.

### 5. Zapobiegaj błędom
Strona spełnia tą heurystykę.

### 6. Pokaż, zamiast zmuszać do zapamiętania
Strona spełnia tą heurystykę.

### 7. Elastyczność i efektywność
Strona spełnia tą heurystykę.

### 8. Dbaj o estetykę i umiar
Strona spełnia tą heurystykę.

### 9. Zapewnij skuteczną obsługę błędów
Strona spełnia tą heurystykę.

### 10. Zadbaj o pomoc i dokumentację
Nie widzimy żadnego wsparcia dla osób nie zaznajomionych ze stroną. Tj. nie ma dokumentacji ani żadnego samouczka uczącego użytkownika jak korzystać ze strony. Co prawda istnieje infolinia ale jest ona przystosowana raczej do zgłaszania błędów.

## Lista 2
### Z1
* **Jako** gracz grupowy, **chcę** mieć łatwy dostęp do listy znajomych, **aby** móc łatwo grać ze znajomymi.
* **Jako** nowy gracz, **chcę** mieć dostęp do różnych bohaterów, **aby** wiedzieć kogo kupić na stałe.
* **Jako** kompetetywny gracz bez stałej grupy znajomych, **chcę** mieć możliwość znalezienia podobnych mi graczy, **aby** móc zagrać w cyklicznym turnieju "clash".
### Z2
#### Główny scenariusz 1
1. Użytkownik klika przycisk GRAJ,
2. Użytkownik wybiera tryb gry i potwierdza wybór,
3. Użytkownik znajduje znajomego na liście znajomych,
4. Użytkownik klika PPM (prawym przyciskiem myszy) na wybranego znajomego i wysyła mu zaproszenie,
5. Użytkownik czeka na potwierdzenie,
6. Po dołączeniu znajomego można rozpocząć rozgrywkę.
#### Alternatywne scenariusze 1
2. 1. Użytkownik cofa się do Menu głównego,
3. 1. Użytkownik nie posiada znajomych, można rozpocząć grę,
4. 1. Użytkownik kliknął inny przycisk,
a Wykonywana jest przypisana jest temu guzikowi funkcja,
2. Użytkownik zaprosił złego znajomego,
a Użytkownik może wyrzucić tą osobę z drużyny albo zagrać z nią w grę,
3. Poczekalnia jest pełna zaproszenie nie zostaje wysłane,
5. 1. Zaproszenie nie zostało przyjęte lub zostało odrzucone, powrót do kroku 4,
6. 1. Gracze mają zbyt dużą różnicę rang graczy gra się nie zacznie,
2. Jeden z graczy ma leave-buster : gra zacznie się z opóźnieniem,
3. Gracze nie wybrali swojej pozycji - gra nie może się zacząć dopóki tego nie zrobią,
4. W poczekalni jest zła liczba osób do wybranego trybu gry - gra się nie zacznie,
#### Główny scenariusz 2
1. Użytkownik klika przycisk GRAJ,
2. Użytkownik wybiera tryb gry i potwierdza wybór,
3. Użytkownik znajduje grę,
4. Użytkownik w trakcie wyboru bohaterów ma dostęp do listy postaci które uprzednio zakupił i bohaterów z rotacji,
Wymogi rotacji (musi zawierać):
- przedstawiciela każdej klasy bohatera,
- postacie proste i skomplikowane (wg. skali dołączonej do każdego bohatera),
- postać na każdą z 5 ról,
5. Użytkownik wybiera postać i rozpoczyna nią rozgrywkę,
#### Alternatywne scenariusze 2
2. 1. Gracz nie wybiera trybu gry,
4. 1. Gracz nie zdążył wybrać bohatera - powraca do lobby i dostaje karę,
4. 1. Gracz wybrał postać z poza rotacji - gra postacią zakupioną wcześniej,
#### Główny scenariusz 3
1. Użytkownik zakłada drużynę clash,
2. Użytkownik klika zaproś gracza,
3. a Użytkownik wybiera wolnego agenta i klika zaproś,
3. b Użytkownik czeka na zgłoszenia do drużyny ludzi o podobnych umiejętnościach,
4. Po zebraniu 5 osób można rozpocząć grę,
5. Rozpoczęcie gry
#### Alternatywne scenariusze 3
2. 1. Użytkownik rozwiązuje drużynę,
3. a 1. Użytkownik losuje ponownie wolnych agentów i powraca do 3a,
3. a 2. Użytkownik odwołuje zaproszenie gracza powrót do 3a,
3. b 1. Nikt się nie zgłosił powrót do 2.,
3. (wspólny) - gracz opuścił drużynę / lub został z niej wyrzucony - powrót do 2.,
4. 1. Drużyna została rozwiązana,
4. 2. Koniec terminu zapisów na turniej przed zebraniem 5 osób,

## Lista 3
### CCCC - C and C++ Code Counter
Policzył dwa razy linijki kodu?
* WMpC - (Weigted Metod per Class) Miara tego jak bardzo "ciężkie" dla komputera są klasy. Jako predyktor czasu i wysiłku wymaganego do opracowania i utrzymania klasy możemy użyć liczby metod i złożoności każdej z nich.
* NOC - (Number of children) Jeżeli rozpiszemy sobie relacje między klasami i ich podklasami jako drzewo, gdzie podklasy będą dziećmi to NOC jest równy maksymalnej głębokości tego drzewa.
* CBO - (Coupling beetween objects) Parowanie pomiędzy obiektami zachodzi wtedy kiedy jeden obiekt odnosi się często do metod albo zmiennych z drugiego obiektu,
* MVG - (McCable's Cyclomatic Number) Liczba liniowo niezależnych ścieżek w programie. Im ta liczba jest wyższa tym bardziej skompikowany program.


### SonarQube

* Code smell - Problem związany z utrzymaniem w kodzie. Pozostawienie go bez zmian oznacza, że w najlepszym przypadku programiści zajmujący się utrzymaniem kodu będą mieli trudniej niż powinni, wprowadzając zmiany. W najgorszym przypadku będą tak zdezorientowani stanem kodu, że wprowadzą dodatkowe błędy podczas wprowadzania zmian.
* Security hotspot - Fragmenty kodu mające znaczenie dla bezpieczeństwa, które należy sprawdzić ręcznie. Po sprawdzeniu okaże się, że nie ma zagrożenia lub że istnieje podatny na ataki kod, który należy naprawić.
* Debt - Szacowany czas potrzebny do naprawienia wszystkich problemów z utrzymaniem i śmierdzeniem kodu.
* Vulnerability - Problem związany z bezpieczeństwem, który stanowi backdoor dla atakujących.
* Condition coverage (branch_coverage): W każdym wierszu kodu zawierającym pewne wyrażenia boolowskie pokrycie warunku odpowiada na następujące pytanie: „Czy każde wyrażenie boolowskie zostało ocenione zarówno jako prawda, jak i fałsz?”. Jest to gęstość możliwych warunków w strukturach sterowania przepływem, które były przestrzegane podczas wykonywania testów jednostkowych.

:::spoiler hasła do Sonarqube
Hasło do sonarqube : KacperMarcin123
ALTER USER sonar WITH ENCRYPTED password '321MarcinKacper';
:::
## Lista 4
### Nowa funkcja : Danie użytkownikom możliwości tworzenia prywatnych turniejów typu "Clash"

#### Historyjka użytkownika
**Jako** gracz, **chcę** stworzyć prywatny turniej "Clash" **aby** móc zorganizować zawody w swojej grupie znajomych.

#### Scenariusz przypadków użytkowania

##### Główny scenariusz
1. Użytkownik klika przycisk "Graj"
2. Użytkownik klika przycisk "Stwórz grę niestandardową"
3. Użytkownik wybiera tryb gry "Clash" i potwierdza wybór
4. Użytkownik wybiera rozmiar drabinki który jest potęgą liczby 2
5. Użytkownik zaprasza znajomych do lobby
6. Użytkownik czeka na potwierdzenie
7. Gracze dzielą się na 5-osobowe drużyny
8. Użytkownik rozpoczyna clasha
9. Gra tworzy drabinkę turniejową
10. Gracze grają wyznaczoną ilość rund w formacie BO1(Best of 1)
11. Po zakończonym finale wyświetla się wiadomość ogłaszająca zwycięską drużynę
##### Scenariusze alternatywne

1. 7.A) Liczba zaproszonych graczy nie jest równa 2^k * 5,
1. Gra blokuje przycisk rozpoczęcia rozgrywki,
2. powrót do punktu 5.
2. 7.B) Gracze podzielili się na nierówne drużyny,
1. Gra blokuje przycisk rozpoczęcia rozgrywki,
2. powrót do punktu 7.
3. 10.A) Któraś z drużyn opuściła rozgrywkę.
1. Przeciwna drużyna przechodzi dalej w drabince.

#### Testowanie scenariuszy alternatywnych
* planowanie i nadzór nad testami
* Typ przeglądu: review
* forma: scenariusze, uruchamiane na "sucho", przez przygotowanych wcześniej testerów

* analiza testów
* Zostaną przygotowane dokumenty z opisem oczekiwanych wyników dla testowanych funkcji i formularze zgłaszania błędów. Każdy inny rezultat należy traktować jako niezamierzony, udokumentować zajście, warunki jego powstania i przekazać wypełniony formularz po zakończeniu testów nadzroującemu testy.

* cele testów
* znalezienie usterek
* feedback co do uczuć grających i ogólnego "feeleingu" trybu gry

* projektowanie testów
* testy sformalizowane
* techniki testowania: testowanie w oparciu o przypadki użycia

* implementacja i wykonanie testów
* Tworzymy prywatny serwer z nową funkcjonalnością
* Zapraszamy wybrane osoby do przetestowania wybranych przypadków użycia

* ocena kryteriów zakończenia i raportowanie
* Testerzy wykonują scenariusze testowe i raportują, wypełniając formularz, czy przebiegły pomyślnie i czy napotkali podczas nich jakieś błędy
* oceniamy czy trzeba wykonać więcej testów

* czynności zamykające test
* sprawdzenie, które planowane scenariusze zostały wykonane
* udokumentowanie wyników i przekazanie ich do programistów
* przeanalizowanie wyników w celu stworzenia nowych testów
#### Przypadki testowe

**Główny**

----

##### Tytuł
**Poprawne stworzenie prywatnego turnieju**
##### Warunki wstępne
* Gracz posiada aktualną wersję gry,
* Gracz posiada dostęp do internetu,
* Gracz posiada odpowiednią ilość znajomych,
##### Kroki
1. Użytkownik klika przycisk "Graj"
2. Użytkownik klika przycisk "Stwórz grę niestandardową"
3. Użytkownik wybiera tryb gry "Clash" i potwierdza wybór
4. Użytkownik wybiera rozmiar drabinki który jest potęgą liczby 2
5. Użytkownik zaprasza znajomych do lobby
6. Użytkownik czeka na potwierdzenie
7. Gracze dzielą się na 5-osobowe drużyny
8. Użytkownik rozpoczyna clasha
9. Gracze grają wyznaczoną ilość rund w formacie BO1(Best of 1)

##### Oczekiwane rezultaty

Po zakończonym finale wyświetla się wiadomość ogłaszająca zwycięską drużynę i zniszczone zostaje lobby tego turnieju.

##### Warunki końcowe
Gra cofa graczy do menu głównego.

**7 A)**

----

##### Tytuł
**Liczba zaproszonych graczy nie jest równa 2^k * 5,**
##### Warunki wstępne

* W lobby jest nieodpowiednia liczba graczy

##### Kroki

1. Gracz próbuje rozpocząć rozgrywkę

##### Oczekiwane rezultaty

1. Gra blokuje przycisk rozpoczęcia rozgrywki,

##### Warunki końcowe
1. Powrót do punktu 5. *(5. Użytkownik zaprasza znajomych do lobby)*

**7 B)**

----

##### Tytuł
**Gracze podzielili się na nierówne drużyny**
##### Warunki wstępne

* Drużyny w lobby nie są dokładnie 5-osobowe

##### Kroki

1. Gracz próbuje rozpocząć rozgrywkę

##### Oczekiwane rezultaty

1. Gra blokuje przycisk rozpoczęcia rozgrywki,

##### Warunki końcowe
1. Powrót do punktu 7. *(7. Gracze dzielą się na drużyny)*

**10 A)**

----

##### Tytuł
**Któraś z drużyn opuściła rozgrywkę**
##### Warunki wstępne

* 2 drużyny są w trakcie rozgrywki

##### Kroki

1. Któraś z drużyn opuszcza rozgrywkę

##### Oczekiwane rezultaty

1. Przeciwna drużyna odnosi zwycięstwo i przechodzi dalej w drabince turniejowej

##### Warunki końcowe
1. Turniej jest rozgrywany dalej

## Lista 5
## Lista 6

## Jmeter