Do you find this helpful? Do you have tips or advice? How can I improve? Please let me know @engineerturnspm or engineerturnspm@gmail.com

Quality is hard. You have to get a lot of things right. You should care because you, your team and your company’s reputation depends on it.

I listed things that I found as value-add when I was managing a small to medium size software projects with less than 1000 users. Consider working with specialized quality assurance experts as product’s complexity increases.


  • Have a quality plan that describes, at the minimum, the quality focal, the process, the measurements and tools.
    • Get the management and your team to review and agree with quality plan.
      • The management cares about things like is it hitting all the major milestones and data to back it up? Is it on budget?  How risks, issues, opportunities are managed?
      • The team cares about the additional work they have to do on the top of just coding.
  • Peer review is effective. It is useful to do them when a deliverable is completed and before signing off and handing off to the next person. Any project deliverables can be peer review – most focused on code, requirement documents, test plans/scripts.
  • Measurements
    • Budget and schedule
    • Risks, issues, opportunities
    • Peer reviews
    • Pre-release defects
    • Post-release defects
    • Emergency post-release defects
    • (If project is strategic and require significant resources, use earned value management. Caution – overhead costs.)
  • Types of Tests
    • Unit testing – done by the developer. Test the smallest piece of code such as functions, methods, classes. Pre-release defects are identified.
    • Integration testing – done by the developer &/ analyst. Make sure the changes work as it goes from one module to the next. Pre-release defects are identified.
    • System testing – done by the developer &/ analyst. Make sure the interconnected systems work as it goes from one system to the next system. Pre-release defects are identified.
    • Acceptance testing – done by limited set of end users. Pre-release defects are identified.
  • Include non-functional requirements in testing. Security, scalability, performance, availability testing should be automated and completed during integration testing and system testing. There’s too many instances of it works on my machine but break when more people use it.
  • Traceability matrix is important to connect the requirements to the tests. You also find out the test coverage of the requirements. You can manually create one using Excel. Use a tool such as Team Foundation Server is better.
  • Use a software tool to track quality. Team Foundation Server is an example – it tracks bugs and it makes it easy to include useful information in recreating a bug and fixing a bug.
  • Automate as many testing, reporting and communications as you can. Setup repeatable processes.


  • Trust but verify test processes every time you work with a new group.
  • Ask for evidences if a vendor says everything is tested and passed. Otherwise, test everything in your control.
  • Understand the difference between quality assurance and quality control. Assurance is proactive and focus on processes. Control is reactive and product related.
  • Consider training on processes and tools. Make it as easy as possible for the team.
  • Give the team enough time to do quality work and peer reviews in your team operating rhythm.
  • Doing it right the first time you create a document/write code. Watch out for the information hand-off from one team to another. Misunderstandings and miscommunications can be reduced by having discussions and asking more in-depth questions.
  • Before starting work, check that you are given the correct information given.
  • Defects should be triaged, the decision recorded and communicated with stakeholders. You’ll get questions on why something hasn’t been fixed yet and you need a good reason.
  • Consider training and written instructions so that defect data are entered correctly and useful information is included.
  • Setup a dashboard for easy tracking and reporting. Using Pivot tables can give you extra information that isn’t come with the built-in reporting
  • Talk about it with your team and other teams. Learn from their successes and mistakes.
  • Consider audit done to ensure processes are followed as they are written and fix any gap.
  • Prototyping is good when you face ambiguous requirements. You’ll also notice learning and feedback take place as you do peer reviews & prototyping.
  • Review plan and metrics regularly. Make everyone understands what is measured, why and how they’ll be used (Especially for the deliverables they create). Periodic reviews with the team to incorporate learning and feedback.