Buying, Building, and Reviewing Tech Work — Lesson 3
QA, Bugs, and Change Management
Learning Objectives
- 1Distinguish between bugs, change requests, and scope additions.
- 2Participate effectively in QA and testing processes.
- 3Manage change requests without derailing the project.
Bugs versus change requests
A bug is something that does not work as agreed. The form submission button does nothing. The page layout breaks on mobile. The email notification goes to the wrong address. Bugs are the vendor responsibility to fix at no additional cost because they represent incomplete work.
A change request is something that works as agreed but you want it to work differently. You approved a blue button and now want it green. The form works but you want to add three more fields. The layout matches the approved design but you want the sections in a different order. Change requests are new work and may have cost implications.
The distinction matters for budgeting and relationships. Calling a change request a bug creates conflict. Accepting bug-level work as "just a change" costs you money. Clear acceptance criteria (from the previous lesson) make this distinction much easier to navigate.
Effective QA participation
QA (Quality Assurance) is not just the developer job. Your team should test the delivered work from the user perspective. Can you complete the main task the website is designed for? Do forms work with real data? Do emails arrive? Does everything work on your phone? Are there spelling errors or missing content?
Create a testing checklist for your team: test every form, test on mobile, test all links, test with real content (not lorem ipsum), test the admin panel, test email notifications, test the purchase flow, test accessibility basics (can you navigate with a keyboard? is text readable?).
Report bugs clearly: describe what you did, what you expected to happen, and what actually happened. Include the browser, device, and a screenshot or video if possible. "The form is broken" is unhelpful. "On iPhone Safari, submitting the contact form shows a blank page instead of the confirmation message — screenshot attached" is actionable.
Managing changes without derailing projects
Changes during a project are inevitable. The key is having a process for evaluating them. For each proposed change, ask: Is this a must-have for launch or a nice-to-have for later? What is the cost and timeline impact? Does this change affect other completed work?
Maintain a change log that tracks every approved and deferred change with its impact. This creates transparency about how scope evolved and why the project took longer or cost more than the original estimate.
The most effective change management habit is asking "can this wait until Phase 2?" Most changes can. The ones that cannot are usually bug-level issues or critical user experience problems. Deferring non-critical changes keeps the project on track for launch.
Case Study
The change log that saved the relationship
Situation
A website project went 40% over budget. The client was frustrated. The developer was frustrated. When they reviewed the change log, they found 23 approved change requests that the client had submitted during the project. Each seemed small at the time — a new page here, an additional form field there — but together they added significant work.
Analysis
The change log provided objective evidence of how the scope evolved. Neither party was at fault — the project grew through mutual decisions. Going forward, they agreed that any change request over two hours of work would require a written estimate and approval before implementation.
Takeaway
A change log protects both parties. It transforms a budget dispute from "the vendor overcharged" versus "the client kept adding things" into an objective record of decisions made together.
Reflection Questions
- 1. In your last project, were there changes that could have waited until after launch?
- 2. Does your organization have a process for evaluating change requests during a project?
Key Takeaways
- ✓Bugs are failures to meet agreed specifications; change requests are new work.
- ✓Your team should participate in QA testing from the user perspective.
- ✓Report bugs with specific steps, expected behavior, actual behavior, and screenshots.
- ✓A change log creates transparency and prevents budget disputes.