TEST SUMMARY REPORT

Ticketer — QA Pack #1: Drag/Drop Ordering + Persistence (Staging)
Author:
Daniel Grabczewski
Report Date:
24/12/2025
Test Window:
23/12/2025 11:04AM – 3:12PM (NZT)
Environment:
Dedicated staging environment (URL omitted to prevent unwanted traffic)
Client:
Desktop Web — Windows 11
Browser:
Chrome 143.0.7499.170 (64-bit)
DB:
MySQL (staging schema, seeded test data) — Server: 8.0.44-0ubuntu0.24.04.2
DB Access:
Read-only (staging DB name: ticketer_db)
Build:
Commit SHA ed78b8c867a8be5acc0a5af087a564a7e4c474c5

1) Test Execution Summary

Total Test Cases Executed: 21 (TC-00 → TC-20)

Defects Raised: 1

2) Results Summary by Area

A) DB setup

  • TC-00 — PASS
  • Board + list IDs captured (Q1/Q2)
  • List positions valid (Q9=0)
  • No duplicate list positions (Q7=0)

B) Ticket reorder within a list

  • TC-01 — PASS (bottom → top)
  • TC-02 — PASS (top → bottom)
  • TC-03 — PASS (adjacent swap)
  • TC-04 — PASS (middle insertion + contiguity checks)

Outcome: Reorders consistently persisted to DB ordering (Q4) with no duplicate positions (Q5=0). Gap detection (Q12) returned 0 rows where executed.

C) Ticket move between lists

  • TC-05 — PASS (Todo → Doing top)
  • TC-06 — PASS (Doing → Done empty)
  • TC-07 — PASS (Todo → Doing middle)
  • TC-08 — PASS (back and forth stability)
  • TC-09 — PASS (move last ticket out of list)

Outcome: Moves verified via Q11 and list snapshots (Q4) with no duplicate positions (Q5=0). List counts updated correctly (Q10).

D) Persistence / stability

  • TC-10 — PASS (reorder persists after refresh)
  • TC-11 — PASS (move persists after refresh)
  • TC-12 — PASS (logout/login persistence + board snapshot Q6)
  • TC-13 — PASS (navigation persistence)

Outcome: State persisted across refresh, navigation, and re-auth, confirmed via pre/post query comparisons.

E) List reordering

  • TC-14 — PASS (reorder lists)
  • TC-15 — PASS (multiple list reorders + refresh)
  • TC-16 — PASS (ticket move after list reorder)

Outcome: List ordering reflected in DB (Q2), persisted after refresh, and did not break ticket moves. No duplicate list positions (Q7=0). No invalid list positions (Q9=0).

F) Stress / negative testing

  • TC-17 — PASS (rapid same-list stress)
  • Q5=0, Q8=0, Q12=0
  • TC-18 — PASS (rapid cross-list stress)
  • Q11 validates final state
  • TC-19 — FAIL (two-tab conflict)
  • DB integrity preserved (Q5=0)
  • Ordering intent not preserved for either tab; system reverted to canonical order after refresh
  • TC-20 — PASS (invalid drop zones)
  • Q11 unchanged; no DB state change

3) Key Findings

What this pack proves

  • Core Kanban interactions (ticket reorder/move, list reorder) are stable under normal usage in the tested environment.
  • Persistence works across refresh, navigation, and logout/login.
  • DB verification found no corruption patterns (no duplicate positions, no negative positions, no ordering gaps) across tested scenarios.
  • Rapid interactions did not break stored integrity in this dataset size.

Main risk discovered (defect)

  • Multi-tab conflict behavior (same user, no refresh) can discard both reorder intents.
  • Data remains “valid” (no duplicates), but user ordering outcome is lost to a hybrid order (mixed order of both)
  • Logged as TICKETER-BUG-001

Other observed UX quirks

  • Username label inconsistency (“signed in as testuser” vs “signed in as user”) observed after session expiry + re-login.
  • List drag “drop zone” placeholder appears fixed-length and can look mismatched versus list current length which depends on its ticket-count.

4) Recommendations / Next Steps

Highest-value follow-on packs

A) Network resilience (ordering under failure)

  • Simulate latency / dropped requests mid-drag
  • Confirm UI error handling and DB consistency

B) Auth + session reliability

  • Session expiry behavior
  • Label consistency
  • Re-login without stale UI states

C) Cross-browser testing

  • Edge and Firefox after Chrome pass

D) Regression mini-pack

  • After significant code changes, re-run: TC-01, TC-05, TC-10, TC-12, TC-14, TC-17, TC-19

5) Conclusion / Quality Call

QA Pack #1 executed 21 high-value manual test cases focused on ordering + persistence with DB verification. 20 passed and 1 failed.

Quality call:

  • Ordering and persistence appear fit for normal single-tab use in the tested staging environment.
  • However, two-tab conflict handling exposes a real user-impact defect (ordering intent can be discarded even though DB remains “valid”). This should be addressed or explicitly specified.

Appendix — Query Index Used

  • Q1 Get Board ID by board name
  • Q2 Get Lists from a board (ordered)
  • Q3 Get all tickets from a board (ordered)
  • Q4 Get Tickets from a list (ordered)
  • Q5 Check for ticket position duplicates (should return 0 rows)
  • Q6 Get board snapshot: show lists + tickets together in the exact UI order
  • Q7 Check for list position duplicates within the board (should be 0 rows)
  • Q8 Check for invalid positions for Tickets (should be 0 rows)
  • Q9 Check for invalid positions for Lists (should be 0 rows)
  • Q10 Get ticket counts per list
  • Q11 Get all details of one ticket
  • Q12 Check for ordering gaps inside each list (should be 0 rows)