Ticketer — QA Pack #1: Ordering System Reliability
Test Cases + Execution Log (MySQL DB Verification)
Index — Test Case Summary
Click to view summary table
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.
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 — Reorder ticket within a list: bottom → top
Priority: P1
Purpose: Validate that a bottom-to-top reorder updates UI order and persisted DB ordering without duplicates or corruption.
Steps
- Open board “QA Pack #1 — Ordering”
- In List Todo, drag Task 10 to the top (above Task 01)
Expected
- UI shows Task 10 first in List Todo
- No duplicate/ghost tickets appear
DB Checks
- Q4 Get Tickets from List Todo (ordered) (To verify Todo ordering after moving Task 10 to the top)
- Q11 Get all details of Ticket Task 10 (To confirm Task 10’s persisted list + position details after reorder)
- Q5 Check for ticket position duplicates (should return 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 — Reorder ticket within a list: top → bottom
Priority: P1
Purpose: Validate that a top-to-bottom reorder updates UI order and persisted DB ordering without duplicates.
Steps
- Drag Task 01 to the bottom of List Todo
Expected
- Task 01 is last in List Todo
DB Checks
- Q4 Get Tickets from List Todo (ordered) (To verify Todo ordering after moving Task 01 to the bottom)
- Q5 Check for ticket position duplicates (should return 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 — Adjacent ticket swap within a list
Priority: P1
Purpose: Validate that swapping adjacent tickets updates ordering cleanly without position duplication.
Steps
- Move Task 03 just above Task 02 in List Todo
Expected
- Task 03 appears immediately above Task 02
DB Checks
- Q4 Get Tickets from List Todo (ordered) (To verify the adjacent swap is reflected in persisted ordering)
- Q5 Check for ticket position duplicates (should return 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 — Middle ticket insertion within a list
Priority: P1
Purpose: Validate that inserting a ticket into the middle shifts surrounding tickets correctly and preserves contiguous ordering (no gaps).
Steps
- Drag Task 09 to sit between Task 04 and Task 05
Expected
- Ticket Task 09 inserts correctly between Task 04 and Task 05
- Tickets surrounding Task 09 shift correctly
DB Checks
- Q4 Get Tickets from List Todo (ordered) (To verify persisted ordering after middle insertion)
- Q12 Check for ordering gaps inside each list (should be 0 rows)
- Q5 Check for ticket position duplicates (should return 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 — Move ticket from Todo → Doing (to top)
Priority: P1
Purpose: Validate cross-list move updates ticket list membership and ordering in both source and target lists without duplicates.
Steps
- Drag Task 04 from List Todo → top of Doing
Expected
- Ticket Task 04 disappears from Todo
- Ticket Task 04 appears at top of Doing
DB Checks
- Q11 Get all details of Ticket Task 04 (To confirm Task 04’s persisted ListName is Doing after move)
- Q4 Get Tickets from List Todo (ordered) (To verify source list ordering updates after removal)
- Q4 Get Tickets from List Doing (ordered) (To verify target list ordering updates after insertion at top)
- Q5 Check for ticket position duplicates (should return 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 — Move ticket from Doing → Done (empty list)
Priority: P1
Purpose: Validate moving into an empty list creates correct single-ticket state and list counts update correctly.
Steps
- Drag Task 11 from Doing → Done (Done is empty to begin with)
Expected
- List Done now contains exactly 1 ticket
DB Checks
- Q11 Get all details of Ticket Task 11 (To confirm Task 11’s persisted ListName is Done after move)
- Q4 Get Tickets from List Done (ordered) (To confirm Done contains exactly one ticket)
- Q10 Get Ticket counts per list (To verify Done count increased to 1)
- Q5 Check for ticket position duplicates (should return 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 — Move ticket into middle of target list
Priority: P1
Purpose: Validate cross-list insertion into a specific middle position preserves intended target ordering.
Steps
- Drag Task 05 from List Todo → Doing between Task 11 and Task 12
Expected
- Ticket Task 05 inserts in List Doing at the drop position
DB Checks
- Q11 Get all details of Ticket Task 05 (To confirm Task 05’s persisted ListName is Doing after move)
- Q4 Get Tickets from List Doing (ordered) (To verify target ordering reflects the middle insertion)
- Q5 Check for ticket position duplicates (should return 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 — Move ticket back and forth between lists (state stability)
Priority: P1
Purpose: Validate rapid cross-list moves do not create duplicates/ghost state and final persisted list membership is correct.
Steps
- Move Task 06 from List Todo → Doing
- Immediately move Task 06 from List Doing → Todo
Expected
- Ticket ends in Todo once (no duplicates/ghost state)
DB Checks
- Q11 Get all details of Ticket Task 06 (To confirm Task 06’s final persisted ListName is Todo)
- Q5 Check for ticket position duplicates (should return 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 — Move last ticket out of a list
Priority: P1
Purpose: Validate removing the only ticket from a list leaves it empty and list counts reflect 0.
Preconditions
- List Done contains exactly 1 ticket (Task 11)
Steps
- Move Ticket Task 11 from List Done → Todo
Expected
- List Done becomes empty
DB Checks
- Q4 Get Tickets from List Done (ordered) (To confirm Done returns 0 rows / is empty after the move)
- Q10 Get Ticket counts per list (To verify List Done TicketCount = 0)
- Q5 Check for ticket position duplicates (should return 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 — Ticket reorder persists after refresh
Priority: P1
Purpose: Validate that reordering persists across browser refresh and DB ordering remains identical before vs after.
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 Get Tickets from List Todo (ordered) (Before refresh: capture baseline persisted ordering)
- Q4 Get Tickets from List Todo (ordered) (After refresh: confirm persisted ordering is unchanged)
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 — Cross-list move persists after refresh
Priority: P1
Purpose: Validate that moving a ticket to a different list persists across refresh (list membership remains correct).
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 List Done after refresh
DB Checks
- Q11 Get all details of Ticket Task 07 (Before refresh: capture persisted list membership)
- Q11 Get all details of Ticket Task 07 (After refresh: confirm list membership is unchanged)
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— Board persistence after logout/login
Priority: P1
Purpose: Validate persistence across a full auth session reset (logout/login) using a board snapshot comparison.
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 snapshot; persistence holds
DB Checks
- Q6 Get board snapshot: show lists + tickets together in the exact UI order (Before logout: capture full board ordering state)
- Q6 Get board snapshot: show lists + tickets together in the exact UI order (After login: confirm snapshot matches persisted state)
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 — Persistence after navigating away and back
Priority: P1
Purpose: Validate persistence across in-app navigation (change board/page and return) without relying on refresh.
Steps
- Move Task 01 from List Todo → List Done
- Navigate to another board and then return
Expected
- Change persists after navigation
DB Checks
- Q11 Get all details of Ticket Task 01 (To confirm Task 01 remains in the target list after navigating away and returning)
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 — Reorder lists
Priority: P1
Purpose: Validate list reordering updates list positions correctly and preserves list ordering integrity (no duplicates/invalid positions).
Steps
- Drag List Done to far left (before Todo)
Expected
- List order updates in UI
DB Checks
- Q2 Get Lists from a board (ordered) (To verify persisted list ordering after moving Done to the far left)
- Q7 Check for list position duplicates within the board (should be 0 rows)
- Q9 Check for invalid positions for Lists (should be 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— Reorder lists multiple times + refresh
Priority: P1
Purpose: Validate list reordering remains stable across multiple moves and refresh (final ordering persists).
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 Get Lists from a board (ordered) (Before refresh: capture persisted list ordering after moves)
- Q2 Get Lists from a board (ordered) (After refresh: confirm ordering is unchanged)
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— Move tickets after list reorder
Priority: P1
Purpose: Validate ticket drag/drop remains functional after list order changes (no regression from list reorder feature).
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 Get all details of Ticket Task 12 (To confirm Task 12’s persisted ListName is Todo after move)
- Q5 Check for ticket position duplicates (should return 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 — Rapid drag stress (same list) + integrity checks
Priority: P1
Purpose: Stress same-list reordering under rapid actions and validate integrity constraints (no duplicates, invalid positions, or gaps).
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) (To verify the final persisted ordering after rapid reorders)
- Q5 Check for ticket position duplicates (should return 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 — Rapid drag stress (cross-list) check
Priority: P1
Purpose: Stress cross-list moves repeatedly and confirm the ticket ends in exactly one list and persists after refresh.
Steps
- Rapidly move Ticket Task 01 across lists 10 times
- Refresh
Expected
- Ticket ends up in exactly one list
- Ticket stays in its final position after refresh
DB Checks
- Q11 Get all details of Ticket Task 01 (To confirm final persisted list membership after stress moves + refresh)
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 — Multi-tab conflict check
Priority: P2
Purpose: Validate multi-tab conflict behavior when two clients reorder the same list without syncing, ensuring integrity holds and at least one reorder intent is preserved deterministically.
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
- 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
DB Checks
- Q4 Get Tickets from List Todo (ordered) (To verify the final persisted ordering in Todo after both conflicting reorders + refresh)
- Q5 Check for ticket position duplicates (should return 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 — Ticket drop onto invalid zones should not corrupt state
Priority: P2
Purpose: Validate invalid drop targets do not move/reorder tickets and do not mutate persisted ticket state.
Steps
- Attempt dropping ticket Task 01 on non-list areas (header / blank space)
Expected
- Ticket snaps back / drop is prevented in non-list areas
- No state change in DB
DB Checks
- Q11 Get all details of Ticket Task 01 (To confirm persisted list + position remain unchanged after invalid drop attempt)
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)