Files
paya-university-fault-system/features/US-05-verify-repair.feature
T
amir 97e5a85569 Standardize analysis docs and add user story features
Align docs/analysis files on one structure: metadata header, unnumbered
"مقدمه", numbered sections, and a final "نکات و پرسش‌های باز" section.

- user-story.md: add "نیازمندی‌های مرتبط" (FR refs) to each US, number
  the sections, and update the last-updated date
- requirements-specification.md: define "گزارش‌دهنده" and align the
  closing section name
- activity.md: add metadata header and مقدمه, drop English actor labels,
  give each diagram an AD-NN id, and add a status line
- CONTRIBUTING.md: record the analysis docs standard as section ۷
- features/: Gherkin scenarios for US-01, US-05 and US-15
2026-11-02 22:07:30 +03:30

52 lines
3.3 KiB
Gherkin
Raw Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# مرجع: US-05 ، FR-14 ، AD-05
Feature: تأیید یا رد نتیجه تعمیر توسط گزارش‌دهنده
به عنوان یک دانشجو یا استاد
می‌خواهم پس از اعلام رفع خرابی، آن را تأیید یا رد کنم
تا بتوانم از بسته شدن صحیح گزارش مطمئن شوم
Background:
Given گزارش شماره "R-100" با وضعیت "تعمیر انجام‌شده" و گزارش‌دهنده "student1" وجود دارد
Scenario: تأیید نتیجه تعمیر توسط گزارش‌دهنده
Given کاربر "student1" وارد سامانه شده است
When نتیجه تعمیر گزارش "R-100" را تأیید می‌کند
Then وضعیت گزارش "R-100" به "بسته‌شده" تغییر می‌کند
And تاریخچه گزارش ثبت تأیید گزارش‌دهنده را نشان می‌دهد
Scenario: رد نتیجه تعمیر بدون ذکر دلیل
Given کاربر "student1" وارد سامانه شده است
When نتیجه تعمیر گزارش "R-100" را با دلیل خالی رد می‌کند
Then پیام خطای "ذکر دلیل رد الزامی است" نمایش داده می‌شود
And وضعیت گزارش "R-100" بدون تغییر "تعمیر انجام‌شده" می‌ماند
Scenario: رد نتیجه تعمیر با ذکر دلیل
Given کاربر "student1" وارد سامانه شده است
When نتیجه تعمیر گزارش "R-100" را با دلیل "خرابی هنوز برطرف نشده است" رد می‌کند
Then دلیل رد در تاریخچه گزارش ثبت می‌شود
And گزارش برای پیگیری بیشتر علامت‌گذاری می‌شود
Scenario: کاربر دیگری نمی‌تواند نتیجه تعمیر را تأیید کند
Given کاربر "student2" وارد سامانه شده است
When سعی می‌کند نتیجه تعمیر گزارش "R-100" را تأیید کند
Then پیام "دسترسی مجاز نیست" نمایش داده می‌شود
And وضعیت گزارش "R-100" بدون تغییر "تعمیر انجام‌شده" می‌ماند
Scenario Outline: تأیید یا رد فقط در وضعیت "تعمیر انجام‌شده" مجاز است
Given گزارش "R-101" با وضعیت "<وضعیت>" وجود دارد
When کاربر "student1" سعی می‌کند نتیجه تعمیر گزارش "R-101" را تأیید کند
Then عملیات انجام نمی‌شود
And پیام "این گزارش در وضعیت قابل تأیید نیست" نمایش داده می‌شود
Examples:
| وضعیت |
| ثبت‌شده |
| ارجاع‌شده |
| در حال تعمیر |
| بسته‌شده |
Scenario: کلیک دوباره روی تأیید یک تغییر وضعیت بیشتر ایجاد نمی‌کند
Given کاربر "student1" وارد سامانه شده است
When دو بار پشت سر هم روی دکمه تأیید کلیک می‌کند
Then وضعیت گزارش "R-100" فقط یک بار به "بسته‌شده" تغییر می‌کند
And تاریخچه گزارش فقط یک ورودی تأیید دارد