‍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:

• 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-QY.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 (Important)

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

1. Run Q1 to get BoardId for board name “QA Pack #1 — Ordering”
   
   
2. Copy returned BoardId into subsequent queries
   
   
3. Run Q2 using BoardId to get List IDs for Todo, Doing, Done
   
   
4. Run DB checks:
   
   
   
   • Q7 (list position duplicates within the board — expect 0 rows)
     
     
   • Q9 (invalid list positions < 0 — expect 0 rows)
     
     

Expected

• Q1 returns exactly one BoardId (or correct BoardId chosen if duplicates exist)
  
  
• Q2 returns 3 lists with sensible Position values
  
  
• Q7 returns 0 rows
  
  
• Q9 returns 0 rows
  
  

Evidence

• UI video: TC-00-UI.mp4
  
  
• DB:
  
  
  
  • TC-00-Q1.png
    
    
  • TC-00-Q2.png
    
    
  • TC-00-Q7.png
    
    
  • TC-00-Q9.png
    
    

Result

PASS

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 display behavior across different machines/browsers.
  
  

Ticket Reorder Within a List

TC-01 (P1) — Reorder ticket within a list: bottom → top

Steps

1. Open board “QA Pack #1 — Ordering”
   
   
2. 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 Todo (verify ordering)
  
  
• Q11 for Task 10 (verify list + updated position)
  
  
• Q5 (duplicate positions across board — expect 0 rows)
  
  

Evidence

• UI video: TC-01-UI.mp4
  
  
• DB:
  
  
  
  • TC-01-Q4.png
    
    
  • TC-01-Q11.png
    
    
  • TC-01-Q5.png
    
    

Result

PASS

TC-02 (P1) — Reorder ticket within a list: top → bottom

Steps

1. Drag Task 01 to the bottom of Todo
   
   

Expected

• Task 01 is last in Todo
  
  

DB Checks

• Q4 for Todo
  
  
• Q5 (expect 0 rows)
  
  

Evidence

• UI video: TC-02-UI.mp4
  
  
• DB:
  
  
  
  • TC-02-Q4.png
    
    
  • TC-02-Q5.png
    
    

Result

PASS

TC-03 (P1) — Adjacent ticket swap within a list

Steps

1. Move Task 03 just above Task 02 in Todo
   
   

Expected

• Task 03 appears immediately above Task 02
  
  

DB Checks

• Q4 for Todo
  
  
• Q5 (expect 0 rows)
  
  

Evidence

• UI video: TC-03-UI.mp4
  
  
• DB:
  
  
  
  • TC-03-Q4.png
    
    
  • TC-03-Q5.png
    
    

Result

PASS

TC-04 (P1) — Middle ticket insertion within a list

Steps

1. Drag Task 09 to sit between Task 04 and Task 05
   
   

Expected

• Inserted correctly; surrounding tickets shift cleanly
  
  

DB Checks

• Q4 for Todo
  
  
• Q12 (gap detection — expect 0 rows)
  
  
• Q5 (expect 0 rows)
  
  

Evidence

• UI video: TC-04-UI.mp4
  
  
• DB:
  
  
  
  • TC-04-Q4.png
    
    
  • TC-04-Q12.png
    
    
  • TC-04-Q5.png
    
    

Result

PASS

Ticket Move Between Lists

TC-05 (P1) — Move ticket from Todo → Doing (to top)

Steps

1. Drag Task 04 from Todo → top of Doing
   
   

Expected

• Ticket disappears from Todo
  
  
• Ticket appears at top of Doing
  
  

DB Checks

• Q11 for Task 04 (ListName = Doing)
  
  
• Q4 for Todo
  
  
• Q4 for Doing
  
  
• Q5 (expect 0 rows)
  
  

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
    
    

Result

PASS

TC-06 (P1) — Move ticket from Doing → Done (empty list)

Steps

1. Drag Task 11 from Doing → Done (Done is empty)
   
   

Expected

• Done now contains exactly 1 ticket
  
  

DB Checks

• Q11 for Task 11 (ListName = Done)
  
  
• Q4 for Done
  
  
• Q10 (ticket counts per list)
  
  
• Q5 (expect 0 rows)
  
  

Evidence

• UI video: TC-06-UI.mp4
  
  
• DB:
  
  
  
  • TC-06-Q11.png
    
    
  • TC-06-Q4.png
    
    
  • TC-06-Q10.png
    
    
  • TC-06-Q5.png
    
    

Result

PASS

TC-07 (P1) — Move ticket into middle of target list

Steps

1. Drag Task 05 from Todo → Doing between Task 11 and Task 12
   
   

Expected

• Inserted in Doing at the drop position
  
  

DB Checks

• Q11 for Task 05 (ListName = Doing)
  
  
• Q4 for Doing (relative ordering)
  
  
• Q5 (expect 0 rows)
  
  

Evidence

• UI video: TC-07-UI.mp4
  
  
• DB:
  
  
  
  • TC-07-Q11.png
    
    
  • TC-07-Q4.png
    
    
  • TC-07-Q5.png
    
    

Result

PASS

TC-08 (P1) — Move ticket back and forth between lists (state stability)

Steps

1. Move Task 06 Todo → Doing
   
   
2. Immediately move Task 06 Doing → Todo
   
   

Expected

• Ticket ends in Todo once (no duplicates/ghost state)
  
  

DB Checks

• Q11 for Task 06 (final ListName = Todo)
  
  
• Q5 (expect 0 rows)
  
  

Evidence

• UI video: TC-08-UI.mp4
  
  
• DB:
  
  
  
  • TC-08-Q11.png
    
    
  • TC-08-Q5.png
    
    

Result

PASS

TC-09 (P1) — Move last ticket out of a list

Preconditions

• Done contains exactly 1 ticket (Task 11)
  
  

Steps

1. Move that ticket Done → Todo
   
   

Expected

• Done becomes empty
  
  

DB Checks

• Q4 for Done (0 rows)
  
  
• Q10 (Done TicketCount = 0)
  
  
• Q5 (expect 0 rows)
  
  

Evidence

• UI video: TC-09-UI.mp4
  
  
• DB:
  
  
  
  • TC-09-Q4.png
    
    
  • TC-09-Q10.png
    
    
  • TC-09-Q5.png
    
    

Result

PASS

Persistence and Refresh

TC-10 (P1) — Ticket reorder persists after refresh

Steps

1. Reorder Todo to an obvious order (Task 01 between Task 04 and Task 05)
   
   
2. Run Q4 for Todo and save as “Before Refresh”
   
   
3. Refresh the page
   
   
4. Run Q4 for Todo again as “After Refresh”
   
   

Expected

• UI order unchanged after refresh
  
  
• DB ordering matches before refresh
  
  

DB Checks

• Q4 before refresh
  
  
• Q4 after refresh
  
  

Evidence

• UI video: TC-10-UI.mp4
  
  
• DB:
  
  
  
  • TC-10-Q4-before-refresh.png
    
    
  • TC-10-Q4-after-refresh.png
    
    

Result

PASS

TC-11 (P1) — Cross-list move persists after refresh

Steps

1. Move Task 07 Todo → Done
   
   
2. Run Q11 for Task 07 (“Before Refresh”)
   
   
3. Refresh
   
   
4. Run Q11 again (“After Refresh”)
   
   

Expected

• Task 07 is still in Done after refresh
  
  

Evidence

• UI video: TC-11-UI.mp4
  
  
• DB:
  
  
  
  • TC-11-Q11-before-refresh.png
    
    
  • TC-11-Q11-after-refresh.png
    
    

Result

PASS

TC-12 (P1) — Board persistence after logout/login

Steps

1. Perform:
   
   
   
   • One reorder (Task 01 between Task 02 and Task 03)
     
     
   • One move (Task 11 Doing → Done)
     
     
2. Run Q6 (“Before Logout”)
   
   
3. Log out
   
   
4. Log back in
   
   
5. Open board
   
   
6. Run Q6 (“After Login”)
   
   

Expected

• Board UI order matches snapshot; persistence holds
  
  

Evidence

• UI video: TC-12-UI.mp4
  
  
• DB:
  
  
  
  • TC-12-Q6-before-logout.png
    
    
  • TC-12-Q6-after-login.png
    
    

Result

PASS

TC-13 (P1) — Persistence after navigating away and back

Steps

1. Reorder or move a ticket
   
   
2. Navigate away (another board/page), then return
   
   
3. Run Q11 for the moved ticket
   
   

Expected

• Change persists after navigation
  
  

Evidence

• UI video: TC-13-UI.mp4
  
  
• DB:
  
  
  
  • TC-13-Q11.png
    
    

Result

PASS

Notes / 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.
  
  
• Optional improvement (not executed): run Q11 before navigation as baseline.
  
  

List Reordering

TC-14 (P1) — Reorder lists

Steps

1. Drag Done to far left (before Todo)
   
   

Expected

• List order updates in UI
  
  

DB Checks

• Q2 (list order by Position)
  
  
• Q7 (expect 0 rows)
  
  
• Q9 (expect 0 rows)
  
  

Evidence

• UI video: TC-14-UI.mp4
  
  
• DB:
  
  
  
  • TC-14-Q2.png
    
    
  • TC-14-Q7.png
    
    
  • TC-14-Q9.png
    
    

Result

PASS

Notes (UX)

• List drop zone preview width appears fixed and can look longer/shorter than the dragged list depending on ticket count.
  
  

TC-15 (P1) — Reorder lists multiple times + refresh

Steps

1. Move Todo right, then left again
   
   
2. Run Q2 “Before Refresh”
   
   
3. Refresh
   
   
4. Run Q2 “After Refresh”
   
   

Expected

• Final list order persists after refresh
  
  

Evidence

• UI video: TC-15-UI.mp4
  
  
• DB:
  
  
  
  • TC-15-Q2-before-refresh.png
    
    
  • TC-15-Q2-after-refresh.png
    
    

Result

PASS

Notes / Limitation

• Because the starting and final positions of Todo ended up the same, this case can’t prove the move truly persisted vs. not happening.
  
  
• Improvement (not executed): end in a different final list order before refresh.
  
  

TC-16 (P1) — Move tickets after list reorder

Steps

1. Reorder lists
   
   
2. Move Task 12 Doing → Todo
   
   

Expected

• Ticket drag/drop still works after list reorder
  
  

DB Checks

• Q11 for Task 12 (ListName = Todo)
  
  
• Q5 (expect 0 rows)
  
  

Evidence

• UI video: TC-16-UI.mp4
  
  
• DB:
  
  
  
  • TC-16-Q11.png
    
    
  • TC-16-Q5.png
    
    

Result

PASS

“Try to Break It” High-Value Negatives

TC-17 (P1) — Rapid drag stress (same list) + integrity checks

Steps

1. For 30 seconds, drag random tickets around in Todo quickly
   
   
2. Stop and run Q4 for Todo
   
   
3. Run Q5, Q8, Q12
   
   

Expected

• No duplicates, no invalid positions, no gaps
  
  

Evidence

• UI video: TC-17-UI.mp4
  
  
• DB:
  
  
  
  • TC-17-Q4.png
    
    
  • TC-17-Q5.png
    
    
  • TC-17-Q8.png
    
    
  • TC-17-Q12.png
    
    

Result

PASS

TC-18 (P1) — Rapid drag stress (cross-list) check

Steps

1. Rapidly move the same ticket across lists 10 times
   
   
2. Refresh
   
   
3. Run Q11 for that ticket
   
   

Expected

• Ticket ends up in exactly one list and stays there after refresh
  
  

Evidence

• UI video: TC-18-UI.mp4
  
  
• DB:
  
  
  
  • TC-18-Q11.png
    
    

Result

PASS

Notes / Limitation

• Ideally should include a pre-refresh DB check as baseline (not executed).
  
  

TC-19 (P2) — Two-tab conflict check

Preconditions

• Same authenticated user
  
  
• Board “QA Pack #1 — Ordering” open in Tab A and Tab B
  
  
• Tab B is not refreshed after Tab A’s change (stale state)
  
  

Steps

1. Open the same board in Tab A and Tab B
   
   
2. In Tab A, reorder Task 01 from position 1 to after Task 10 (move Task 01 to bottom)
   
   
3. Without refreshing Tab B, in Tab B reorder Task 10 from bottom to before Task 01 (move Task 10 to top)
   
   
4. Refresh both tabs
   
   
5. Run Q4 for Todo to capture final DB order
   
   
6. Run Q5 to confirm no duplicate positions exist
   
   

Expected

• Data integrity holds: final DB state is valid (no duplicates; no missing tickets)
  
  
• Conflict rule holds: final persisted order must deterministically preserve the complete ordering intent of at least one submitted reorder (e.g., last-write-wins)
  
  
• Must not converge to a third “hybrid reset” order that matches neither client outcome
  
  

Evidence

• UI video: TC-19-UI.mp4
  
  
• DB:
  
  
  
  • TC-19-Q4.png
    
    
  • TC-19-Q5.png
    
    

Result

FAIL

Actual

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 occur. 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

1. Attempt dropping a ticket on non-list areas (header / blank space)
   
   
2. Confirm it snaps back / drop is prevented
   
   
3. Run Q11 for that ticket
   
   

Expected

• No state change in DB
  
  

Evidence

• UI video: TC-20-UI.mp4
  
  
• DB:
  
  
  
  • TC-20-Q11.png
    
    

Result

PASS

‍