Section 2. QA Automation Specification (UI Automation Checklist)

QA Automation Spec outlines instructions for automation engineers, defining which UI elements and test scenarios must be covered by automated tests (UI/E2E).

• Goal: Ensure interface testability right at the coding stage (Testability).
• What it includes:
  • Element Labeling: Mandatory unique test locators for key UI components. Use the data-testid attribute for Web, Key parameters for Flutter, and accessibilityIdentifier for Android/iOS.
  • Critical E2E Scenarios: A list of user flows that automation engineers must cover first (e.g., “Successful login \(\rightarrow\) Navigate to inventory \(\rightarrow\) Scan smart-tag \(\rightarrow\) Verify server-side status change”).
  • UI Integration Verifications: Requirements for how the UI should handle network errors (showing Error-state overlays on HTTP 500) and latency (displaying skeletons/loaders).

Section 3. Acceptance Criteria (Definition of Done)

Definition of Done (DoD) is a universal quality checklist. A task cannot be moved to the “Done” status if any single item from this list remains unfulfilled.

• Goal: Guarantee system stability, security, and code cleanliness before release.
• Standard DoD Checklist:
  1. Code fully matches the architectural design in the Scope of Work section.
  2. Unit tests are written (code coverage for new business logic must be at least 80%).
  3. Code Review is completed and approved by at least two Middle+ developers.
  4. No new warnings are reported by the linter or static analyzer (SonarQube).
  5. API specifications are updated in Swagger/Postman and aligned with dependent teams.
  6. UI components are labeled according to the QA Automation Specification (Section 2).
  7. The Git branch is named correctly according to the template rules.
  8. Database performance degradation checks passed (for tasks involving migrations).

---

11. Pull Request (PR) Template

When opening a PR in GitHub/GitLab, developers are required to completely fill out the description using the following markdown template:

## 📝 Description of Changes
<!-- Briefly describe what was done and what technical issue was resolved -->
- Implemented the smart-tag input UI screen in Flutter following the designs in FLUTTER-204.
- Integrated the client-side periodic system prefix validation method.
- Added error handling for cases when the Bluetooth connection to the reader is lost.

## 🔗 Related Task
- **Task ID:** #FLUTTER-204

## 🛠️ How to Test?
<!-- Step-by-step instructions for the code reviewer or QA engineer -->
1. Switch to branch `feature/flutter-204-scancode-ui`.
2. Run the application locally and go to the "Inventory" section.
3. Tap the "Scan" button and input the test ID `BPDS-TEST-99`.
4. Verify that the status banner turns green.

## 🧪 Pre-Review Checklist
- [ ] Code compiles locally without any errors or warnings.
- [ ] New unit tests are added; all existing tests pass successfully in CI.
- [ ] Unique `key` identifiers are added to the scan buttons (QA Automation requirement).
- [ ] Verified UI layouts across different screen resolutions (no layout overflows).