Index — Test Case Summary (QA Pack #1: Ordering)
Legend: P1 = highest risk / core reliability, P2 = secondary risk / edge cases
Key finding: TC-19 failed — multi-tab conflicting reorders converge to a fallback ordering that preserves data integrity but discards user reorder intent.
Ticketer — QA Pack #1: Ordering System Reliability
Test Cases + DB Verification Evidence (Executed)
Test Data Setup (Baseline)
Create a dedicated board in the staging environment:
- Board name: QA Pack #1 — Ordering
- Lists: Todo, Doing, Done
Create tickets in each list:
- Todo: Task 01 … Task 10 (10 tickets)
- Doing: Task 11 … Task 15 (5 tickets)
- Done: none
Evidence & File Naming Conventions
Each test case includes:
- UI video:
TC-XX-UI.mp4
DB evidence screenshots use:
TC-XX-Q#.png(e.g.TC-01-Q4.png)- If the same query is run multiple times in one TC, add a suffix:
- Example:
TC-05-Q4-for-todo.png,TC-05-Q4-for-doing.png - Example:
TC-10-Q4-before-refresh.png,TC-10-Q4-after-refresh.png
Execution Notes
▼ Click to read
Evidence approach used
- Where a pre-action DB snapshot is not present, the intended pre-state is demonstrated via UI recording, and the persistent post-state is verified via DB queries.
- Pre-action DB snapshots were captured for higher-risk persistence checks (refresh/logout). For lower-risk navigation checks, UI evidence was used for pre-state confirmation and DB evidence for post-state confirmation.
Limitation: This approach does not fully rule out a pre-existing UI/DB mismatch prior to the disruptive action. For higher assurance, a pre-action DB snapshot should be captured for every test case in future QA packs.
Baseline reset between test cases
Each test case begins from a known baseline board state. After completing a test, the board was manually reset before running the next case by reshuffling the tickets and lists to their default states. Where a test requires a different precondition, the required setup is performed and captured in evidence.
Note: This reset method is manual and may introduce setup mistakes (e.g., tickets added to the wrong list, missing tickets, incorrect ordering). Therefore, each test includes a pre-check to confirm the baseline state before executing steps; if the baseline does not match, the test must be marked Blocked until corrected.
All tests are recorded end-to-end so setup and outcomes can be independently re-verified. A future improvement is to replace manual seeding with an automated reset/seed mechanism (e.g., script).
Pre-Setup / One-Time DB Identifiers
TC-00 — Capture Board + List IDs (one-time setup)
Priority: P1
Purpose: Collect identifiers and perform initial DB validation.
Steps
- Run Q1 to get BoardId for board name “QA Pack #1 — Ordering”
- Copy returned BoardId into subsequent queries
- Run Q2 using BoardId to get List IDs for Todo, Doing, Done
- Run DB checks:
• Q7 (list position duplicates within the board — expect 0 rows)
• Q9 (invalid list positions < 0 — expect 0 rows)
Expected
- Q1 returns a single matching BoardId. If multiple rows match, select the correct BoardId and note the reason.
- Q2 returns 3 lists with sensible Position values
- Q7 returns 0 rows
- Q9 returns 0 rows
Result
PASS
Evidence
- UI video :
TC-00-UI.mp4
- DB:
- TC-00-Q1.png
- TC-00-Q2.png
- TC-00-Q7.png
- TC-00-Q9.png
Notes
- UX observation: username display changed from “signed in as testuser” to “signed in as user” after re-login due to session expiry. Account remained the same.
Limitations
- Did not test to identity differing display behavior across different machines/browsers.
Ticket Reorder Within a List
TC-01 (P1) — Reorder ticket within a list: bottom → top
Steps
- Open board “QA Pack #1 — Ordering”
- In Todo, drag Task 10 to the top (above Task 01)
Expected
- UI shows Task 10 first in Todo
- No duplicate/ghost tickets appear
DB Checks
- Q4 for list Todo (verify ordering)
- Q11 for ticket Task 10 (get all details of a ticket)
- Q5 (duplicate positions across board — expect 0 rows)
Result
PASS
▼ Click to view evidence
Evidence
- UI video :
TC-01-UI.mp4
- DB:
- TC-01-Q4.png
- TC-01-Q11.png
- TC-01-Q5.png
TC-02 (P1) — Reorder ticket within a list: top → bottom
Steps
- Drag Task 01 to the bottom of Todo
Expected
- Task 01 is last in Todo
DB Checks
- Q4 for list Todo (verify ordering)
- Q5 (duplicate positions across board — expect 0 rows)
Result
PASS
▼ Click to view evidence
Evidence
- UI video :
TC-02-UI.mp4
- DB:
- TC-02-Q4.png
- TC-02-Q5.png
TC-03 (P1) — Adjacent ticket swap within a list
Steps
- Move Task 03 just above Task 02 in Todo
Expected
- Task 03 appears immediately above Task 02
DB Checks
- Q4 for list Todo (verify ordering)
- Q5 (duplicate positions across board — expect 0 rows)
Result
PASS
▼ Click to view evidence
Evidence
- UI video :
TC-03-UI.mp4
- DB:
- TC-03-Q4.png
- TC-03-Q5.png
TC-04 (P1) — Middle ticket insertion within a list
Steps
- Drag Task 09 to sit between Task 04 and Task 05
Expected
- Inserted correctly; surrounding tickets shift cleanly
DB Checks
- Q4 for list Todo (verify ordering)
- Q12 (gap detection — expect 0 rows)
- Q5 (duplicate positions across board — expect 0 rows)
Result
PASS
▼ Click to view evidence
Evidence
- UI video :
TC-04-UI.mp4
- DB:
- TC-04-Q4.png
- TC-04-Q12.png
- TC-04-Q5.png
Ticket Move Between Lists
TC-05 (P1) — Move ticket from Todo → Doing (to top)
Steps
- Drag Task 04 from Todo → top of Doing
Expected
- Ticket disappears from Todo
- Ticket appears at top of Doing
DB Checks
- Q11 for ticket Task 04 (get all details of a ticket)
- Q4 for list Todo (verify ordering)
- Q4 for list Doing (verify ordering)
- Q5 (duplicate positions across board — expect 0 rows)
Result
PASS
▼ Click to view evidence
Evidence
- UI video :
TC-05-UI.mp4
- DB:
- TC-05-Q11.png
- TC-05-Q4-for-todo.png
- TC-05-Q4-for-doing.png
- TC-05-Q5.png
TC-06 (P1) — Move ticket from Doing → Done (empty list)
Steps
- Drag Task 11 from Doing → Done (Done is empty to begin with)
Expected
- List Done now contains exactly 1 ticket
DB Checks
- Q11 for ticket Task 11 (get all details of a ticket)
- Q4 for list Done (verify ordering)
- Q10 (ticket counts per list)
- Q5 (duplicate positions across board — expect 0 rows)
Result
PASS
▼ Click to view evidence
Evidence
- UI video :
TC-06-UI.mp4
- DB:
- TC-06-Q11.png
- TC-06-Q4.png
- TC-06-Q10.png
- TC-06-Q5.png
TC-07 (P1) — Move ticket into middle of target list
Steps
- Drag Task 05 from Todo → Doing between Task 11 and Task 12
Expected
- Inserted in Doing at the drop position
DB Checks
- Q11 for ticket Task 05 (get all details of a ticket)
- Q4 for list Doing (verify ordering)
- Q5 (duplicate positions across board — expect 0 rows)
Result
PASS
▼ Click to view evidence
Evidence
- UI video :
TC-07-UI.mp4
- DB:
- TC-07-Q11.png
- TC-07-Q4.png
- TC-07-Q5.png
TC-08 (P1) — Move ticket back and forth between lists (state stability)
Steps
- Move Task 06 Todo → Doing
- Immediately move Task 06 Doing → Todo
Expected
- Ticket ends in Todo once (no duplicates/ghost state)
DB Checks
- Q11 for ticket Task 06 (get all details of a ticket)
- Q5 (duplicate positions across board — expect 0 rows)
Result
PASS
▼ Click to view evidence
Evidence
- UI video :
TC-08-UI.mp4
- DB:
- TC-08-Q11.png
- TC-08-Q5.png
TC-09 (P1) — Move last ticket out of a list
Preconditions
- Done contains exactly 1 ticket (Task 11)
Steps
- Move Ticket Task 11 from Done → Todo
Expected
- List Done becomes empty
DB Checks
- Q4 for List Done (verify ordering)
- Q10 (Get Ticket counts per list)
- Q5 (duplicate positions across board — expect 0 rows)
Result
PASS
▼ Click to view evidence
Evidence
- UI video :
TC-09-UI.mp4
- DB:
- TC-09-Q4.png
- TC-09-Q10.png
- TC-09-Q5.png
Persistence and Refresh
TC-10 (P1) — Ticket reorder persists after refresh
Steps
- Reorder Todo to an obvious order (Task 01 between Task 04 and Task 05)
- Run Q4 for Todo and save as “Before Refresh”
- Refresh the page
- Run Q4 for Todo again as “After Refresh”
Expected
- UI order unchanged after refresh
- DB ordering matches before refresh
DB Checks
- Q4 for List Todo before refresh (verify ordering)
- Q4 for List Todo after refresh (verify ordering)
Result
PASS
▼ Click to view evidence
Evidence
- UI video :
TC-10-UI.mp4
- DB:
- TC-10-Q4-before-refresh.png
- TC-10-Q4-after-refresh.png
TC-11 (P1) — Cross-list move persists after refresh
Steps
- Move Task 07 Todo → Done
- Run Q11 for Task 07 (“Before Refresh”)
- Refresh
- Run Q11 again (“After Refresh”)
Expected
- Task 07 is still in Done after refresh
DB Checks
- Q11 for Task 07 before refresh (get all details of one ticket)
- Q11 for Task 07 after refresh (get all details of one ticket)
Result
PASS
▼ Click to view evidence
Evidence
- UI video :
TC-11-UI.mp4
- DB:
- TC-11-Q11-before-refresh.png
- TC-11-Q11-after-refresh.png
TC-12 (P1) — Board persistence after logout/login
Steps
- Perform a reorder : Move Task 01 between Task 02 and Task 03 in List Todo
- Perform a move : Move Task 11 from List Doing → Done)
- Run Q6 (“Before Logout”)
- Log out
- Log back in
- Open board
- Run Q6 (“After Login”)
Expected
- Board UI order matches Q6; persistence holds
DB Checks
- Q6 before refresh (get all details of a board)
- Q6 after refresh (get all details of a board)
Result
PASS
▼ Click to view evidence
Evidence
- UI video :
TC-12-UI.mp4
- DB:
- TC-12-Q6-before-logout.png
- TC-12-Q6-after-login.png
TC-13 (P1) — Persistence after navigating away and back
Steps
- Move Task 01 from List Todo → List Done
- Navigate to another board and then return
Expected
- Change persists after navigation
DB Checks
- Q11 for Task 01 (get all details of a ticket)
Result
PASS
▼ Click to view evidence
Evidence
- UI video :
TC-13-UI.mp4
- DB:
- TC-13-Q11.png
Limitations
- This case captured post-navigation verification only. It validates persistence, but does not include a pre-navigation DB snapshot like TC-10/11/12.
- Potential future improvement: run Q11 before navigation as baseline.
List Reordering
TC-14 (P1) — Reorder lists
Steps
- Drag List Done to far left (before Todo)
Expected
- List order updates in UI
DB Checks
- Q2 (get all lists from a board)
- Q7 (check for list position duplicates - expect 0 rows)
- Q9 (check for invalid positions for Lists - expect 0 rows)
Result
PASS
▼ Click to view evidence
Evidence
- UI video :
TC-14-UI.mp4
- DB:
- TC-14-Q2.png
- TC-14-Q7.png
- TC-14-Q9.png
Notes (UX)
- List drop zone preview length appears fixed and can look longer/shorter than the actual dragged list depending on ticket count.
TC-15 (P1) — Reorder lists multiple times + refresh
Steps
- Move list Todo right, then left again
- Run Q2 (“Before Refresh”)
- Refresh
- Run Q2 (“After Refresh”)
Expected
- Final list order persists after refresh
DB Checks
- Q2 before refresh (get all lists from a board)
- Q2 after refresh (get all lists from a board)
Result
PASS
▼ Click to view evidence
Evidence
- UI video :
TC-15-UI.mp4
- DB:
- TC-15-Q2-before-refresh.png
- TC-15-Q2-after-refresh.png
Limitations
- Because Todo started and ended in the same position, this case confirms refresh stability for the ‘no net change’ scenario, but doesn’t demonstrate persistence of a different final order.
- Potential future improvement: end in a different final list order before refresh.
TC-16 (P1) — Move tickets after list reorder
Steps
- Swap positions of Lists Todo and Done
- Move Task 12 from List Doing → Todo
Expected
- Ticket drag/drop still works after list reorder
DB Checks
- Q11 for Task 12 (get all details of one ticket)
- Q5 (duplicate positions across board — expect 0 rows)
Result
PASS
▼ Click to view evidence
Evidence
- UI video :
TC-16-UI.mp4
- DB:
- TC-16-Q11.png
- TC-16-Q5.png
“Try to Break It” High-Value Negatives
TC-17 (P1) — Rapid drag stress (same list) + integrity checks
Steps
- For 30 seconds, drag random tickets around in List Todo quickly
Expected
- No duplicates, no invalid positions, no gaps
DB Checks
- Q4 Get Tickets from list Todo (ordered)
- Q5 (duplicate positions across board — expect 0 rows)
- Q8 Check for invalid positions for Tickets (should be 0 rows)
- Q12 Check for ordering gaps inside each list (should be 0 rows)
Result
PASS
▼ Click to view evidence
Evidence
- UI video :
TC-17-UI.mp4
- DB:
- TC-17-Q4.png
- TC-17-Q5.png
- TC-17-Q8.png
- TC-17-Q12.png
TC-18 (P1) — Rapid drag stress (cross-list) check
Steps
- Rapidly move Ticket Task 01 across lists 10 times
- Refresh
Expected
- No duplicates, no invalid positions, no gaps
DB Checks
- Q11 for Task 01 (Get all details of one ticket)
Result
PASS
▼ Click to view evidence
Evidence
- UI video :
TC-18-UI.mp4
- DB:
- TC-18-Q11.png
Notes
- Ideally should include a pre-refresh DB check as baseline (not executed)
TC-19 (P2) — Multi-tab conflict check
Preconditions
- Be logged in as the same authenticated user across both tabs
- Board “QA Pack #1 — Ordering” open in Tab A and Tab B
Steps
- In Tab A, reorder Task 01 from position 1 to after Task 10 (move Task 01 to bottom)
- Without refreshing Tab B, in Tab B reorder Task 10 from bottom to before Task 01 (move Task 10 to top)
- Refresh both tabs
Expected
- No duplicates, no invalid positions, no gaps
DB Checks
- Q4 for List Todo (get Tickets from a list)
- Q5 (duplicate positions across board — expect 0 rows)
Result
FAIL
▼ Click to view evidence
Evidence
- UI video :
TC-19-UI.mp4
- DB:
- TC-19-Q4.png
- TC-19-Q5.png
Actual Result
After both conflicting reorders and refresh, both tabs converged to a third order that matches neither Tab A nor Tab B’s ordering outcome. Q5 returned 0 rows (no duplicates), confirming DB positional integrity, but reorder intent was not preserved.
Impact
Multi-tab usage can silently discard user-defined ordering and replace it with a fallback ordering, reducing trust in ordering reliability.
Notes / Analysis
System appears to apply a deterministic fallback when conflicting reorder operations happen. This maintains integrity but violates the expected conflict rule of preserving one committed reorder outcome.
TC-20 (P2) — Ticket drop onto invalid zones should not corrupt state
Steps
- Attempt dropping ticket Task 01 on non-list areas (header / blank space)
- Confirm it snaps back / drop is prevented
Expected
- No state change in DB
DB Checks
- Q11 for Task 01 (Get all details of one ticket)
Result
PASS
▼ Click to view evidence
Evidence
- UI video :
TC-20-UI.mp4
- DB:
- TC-20-Q11.png
Notes
- Ideally should include a pre-refresh DB check as baseline (not executed)