Call Board:
Task Tracker &
QA Case Study
The problem
Everything lived in group texts
Our front desk team prepares for every concert and recital: printing programs, reserving tables, hanging posters, and posting on social media. We tracked all of it through memory and group texts, so things got missed and nobody knew which post was going up next.
- Role
- Developer and QA tester (solo project)
- Timeline
- 1 month
- Tools
- HTML, CSS, JavaScript, Playwright, GitHub Actions, Chrome DevTools, Claude (AI assistant)
Process
Build it, then test it like a real release
I built a task and social-post tracker for the Performing Arts front desk, then tested it the way a QA tester would. It passed all 18 scripted test cases, but exploratory, boundary and accessibility testing still found 10 bugs. I logged, fixed and retested each one, and backed every fix with an automated regression test.
1Gathered requirements
- Wrote 8 user stories with priorities (Must / Should) and acceptance criteria
- Every later test case traces back to one of these stories
2Designed and built the app (v1.0)
- Designed a two-table data model: Performances, and Tasks linked to a performance (drawing on my database coursework)
- Built four features in plain HTML, CSS and JavaScript: a performances overview with progress bars, a page for each performance with filters, add/edit/complete/delete for tasks, and an “Up Next” social media queue
- Saved data in the browser so anyone can try it from a link without logging in
3Planned the testing
- Wrote a test plan covering scope, approach, environments, a severity scale, and entry and exit criteria
- Wrote 18 test cases from the user stories, each with exact steps and expected results
4Executed the tests and hunted for bugs
- Ran all 18 test cases: all passed
- Then went beyond the script with exploratory testing (undoing actions, switching pages with filters on), boundary testing (longest titles, past dates), negative testing (damaged data, HTML typed into fields), date testing with a frozen clock, and an accessibility review (keyboard-only use, screen reader labels, WCAG color contrast)
- Found 10 bugs: 2 high, 7 medium, 1 low
5Reported the bugs
- Wrote each one up with steps to reproduce, expected and actual results, severity, environment and impact
6Fixed and retested (v1.1)
- For each bug, wrote an automated test first and confirmed it failed on v1.0, which proves the test really catches the bug
- Fixed the code, then confirmed the test passed on v1.1
- Added a guard test so one fix didn’t overcorrect (blocking past dates on new tasks, while still allowing edits to overdue ones)
7Automated the regression suite
- 33 Playwright tests (18 functional, 15 regression), each run on a desktop and a phone-sized browser
- Froze the clock in every test so date-based results are the same on any day
- Set up GitHub Actions to run the full suite automatically on every push
8Documented and released
- Wrote release notes for v1.0 and v1.1, linking each fix to its bug ID
- Wrote this case study
Highlights
Four things worth telling
The bug that didn’t look like a bug.
Checking an “In progress” task and then unchecking it reset it to “To do.” Nothing looked broken, but the team’s information was now wrong. I found it by asking “what happens if I undo this?”
One long word broke the phone layout.
A pasted Instagram link as a task title made the page 1,542 pixels wide on a phone.
Testing the future.
By freezing the clock at a future date, I saw what a recruiter would see next year: every show still “upcoming” and every task overdue. I made the demo data relative to today so it never goes stale.
Accessibility.
Measured contrast showed the keyboard focus ring at 1.6:1 (WCAG requires 3:1) and finished tasks at 2.4:1 (requires 4.5:1). Keyboard focus also jumped to the top of the page after every checkbox. All are fixed.
Results
From v1.0 to v1.1
| v1.0 | v1.1 | |
|---|---|---|
| Scripted test cases | 18 of 18 pass | 18 of 18 pass |
| Known bugs | 10 | 0 open |
| Regression tests | 14 of 15 fail* | 15 of 15 pass |
| Automated runs (desktop + phone) | n/a | 66 of 66 pass |
* The 15th is a guard test that passes on both versions by design.
Skills
What this shows
| Skill | Where it shows |
|---|---|
| Requirements and acceptance criteria | 8 user stories with priorities and acceptance criteria |
| Test planning and test case design | Test plan, 28 traceable test cases |
| Exploratory, boundary and negative testing | 10 bugs the scripted cases missed |
| Bug reporting and severity | Reproducible reports with steps, expected and actual results |
| Test automation | 33 Playwright tests, frozen clock, two screen sizes |
| CI/CD | GitHub Actions on every push |
| Accessibility (WCAG 2.1 AA) | Keyboard, screen reader and contrast fixes |
| Regression testing | A failing test before every fix, passing after |
| Documentation | Test plan, bug log, release notes, case study |
| Using AI tools effectively | Worked with Claude to speed up building and testing, then verified and understood every result |
What I learned
Passing isn’t the same as working
- Passing test cases isn’t the same as working software. Every one of the 10 bugs came from testing beyond the script.
- A regression test should fail before the fix, or it isn’t proving anything.
- Anything that depends on dates needs a controllable clock to be testable.
- A good bug report lets someone else reproduce the problem in a minute.
What’s next
Shared data and more testing
- Shared data (a small database) so the whole team sees the same board
- Manual testing on Safari for iPhone and with VoiceOver
- An automated accessibility scanner (axe) in the test suite