We needed a smoke-test list before the next release surprised us.
The plan was to walk through the application together and identify the paths that needed a manual check before a production build. The same session could capture obvious defects and places where the interface was confusing.
A smoke test is deliberately smaller than a complete quality-assurance plan. It asks whether the main product still works after a change. Can a person enter the application? Can they complete the core setup? Can they move through the important actions without reaching a broken state?
Goodword had several connected surfaces by then, including mobile, web, and a browser extension. A change in one service could affect the others even when their screens had not changed.
The list needed steps and expected results. “Test search” was too broad. A useful check described the starting state, the action, and what should appear afterward.
We also wanted to identify which checks could later become automated. Manual testing was still useful for copy, layout, and the overall sequence. Repeated technical checks were candidates for a script or test suite once the expected behavior was stable.
The private source includes bugs, user feedback, and internal product priorities. Those details are not reproduced here. No customer records or product metrics are part of this article.
The public-safe event is the creation of the release checklist. After the public launch, the cost of a regression was higher because people outside the team could encounter it without warning.
I led the first walkthrough and asked the group to document the main workflows as we used them. The list was meant to be revised as the application changed.
It began as a practical pre-release check: open the current build, follow the paths a person depended on, and record enough detail that the same checks could be repeated next time.