---
# System prepended metadata

title: 'Сценарии за тестване:'

---

# Сценарии за тестване:
## **1. Първи сценарий – създаване на Компания (това е тествано, но за всеки случай)**
  - [x] Влизане с Админ: admin@example.com – password. 
  - [x] Създаване на компания.
  - [x] Създаване на 5 отдела.
  - [x] Създаване на 4 длъжности. 
  - [x] Създаване на Органиграма с тези 5 Отдела – (3-1-1). Като трима са Employee и двама са Ръководител ниско ниво и Ръководител високо ниво.
  - [x] Създаване на 5 Потребителя – задаване на роля подходяща за тяхното разпределение в Органиграмата – Employee/Manager
  - [x] Създаване на записи за редовна платена отпуска на служителите.


## **2. Втори сценарий – проследимо събитие Редовен Отпуск**
  - [x] Влизане с един от създадените Employee служители 
  - [x] Създаване на събитие Отпуск платен - Event ID 1
  - [x] Влизане със заместващия служител – проверка дали има нотификация – одобряване/отказване на събитието.
  - [x] Влизане с Менидъжъра на този служител – проверка за Нотификация – одобряване/отказване на събитието.
  - [x] Влизане с потребителя, който е създал събитието – финална проверка на Нотификации.
  - [x] Влизане с админа и проверка дали записа е записан в менюто за събития на потребителя. Дали дните правилно са отчетени според първоначалния запис за полагаеми дни.
  - [x] Сваляне на бланката от Админа и проверка на данните.

## **3. Трети сценарий – проверка на останалите събития**
  - [ ] Влизане с друг от създадените Employee и създаване по отделно на всички събития във системата – тези които имат нужда от одобрение, да се одобрят от Мениджъра, тези които нямат нужда да се финализират.
  - [ ] Да се провери дали всички записи излизат в календара и дали ги има в списъците.
  - [ ] Влизане с акаунта да ръководител ниско ниво – проверка на календара (дали визда всички събития на подчинени) и създаване на събитие, което иска одобрение, няма значение кое събитие. 
  - [ ] Влизане с акаунта на мениджъра високо ниво и създаване на събитие. Проверка на календара и на списъците дали вижда всички събития създадени до сега в компанията.
 
## **4. Четвърти сценарий – проверка на функционалноста за проследмист на събитията - Неплатен отпуск с трудов стаж и Ученически отпуск**
  - [ ] Влизане с акаунт на Employee и създаване на тези събития 
  - [ ] Проверка дали функционалноста е взела данните на събитето и ги е изчислила в данните на Потребители.

## **5. Свободна проверка:**
  - [ ] на акуратноста на данните в списъците от личното меню - замествания, одобрения, мои.
  - [ ] На получаването и изпращането на нотификации
  - [ ] Редактиране на Органиграма ( проверка на финкционалностите ако разменим вертикално два отдела)
  - [ ] Проверка на смяната на календара на компаниите – дали се променят адекватно и данните в календара – когато си HR или Admin с Company management
  - [ ] Тетване на бутона виж собствена информация (в центъра на календара – леко в ляво се намира) – изглежда че при натискане „назад“ след проверка на собствена информация се връщат в календара.
  - [ ] На акуратноста на данните при създаване на събития 


# Подобрения в UX:

* В много полета не може да се селектира текста чрез мишката, което е изключително неудобно.
* Полето "пол" (при създаване/обновяване на потребител) към момента приема две стойности (male/female) и трябва да се въведат ръчно и дословно, което е неудобно ако потребителят няма представа за възможните стойности. Може да се преправи на select input с две опции (преведени на български език).