Version Control

This is the ability to recover any version of any document/software throughout the product history.

1. What are the project documents (examples, Design Specification, Requirements Specification, Functional Specification, Test Plans, Test Procedures, Test tools, Test Suite, Test results).
2. How do you control the project documents?
3. How is the software code base managed?
4. How are software builds distributed?
5. How are software builds approved?

Peer Reviews

This is a team review of a component (piece of code, test plan, test results, any artifact from the project).  It may be cross functional (as in the case of requirements), or it may be a single function (code review for software engineering).  However, it is more effective to have cross functional groups in the review (even for code you could add Design Verification).

6. How do you review the critical documents for understanding?
7. Who is on the review team?
8. How are defects captured (problems found in documentation)?
9. How do you review code?
10. Who is on the review team?
11. How do you review test plans, test procedures and test results?
12. Who is on the review team?

Requirements

The Functional Specification defines what features will be enhanced, added, or removed from a customer perspective.  The requirements are clear, testable, and necessary

13. Which document defines the product requirements?
14. How many documents define requirements?
15. How are changes incorporated?
16. How are they refined for engineering?
17. How are requirements defined throughout the organization?
18. Are they testable and measureable?
19. Who reviews/approves the requirements?

Software & Firmware

20. How are unit tests performed?
21. How are unit test results reported?
22. Are there any other tests performed prior to an internal release from engineering?
23. Which complexity metrics are you tracking?
24. What are the boundary conditions you have set to ensure software is not too complex?
25. How are builds managed?
26. What is the body of tests run to ensure a build is stable enough to proceed with testing? 
27. Does the test set work (have you run the tests, started working, and found the build was too buggy to work with)?

Testing

28. How do engineers test their components?
29. Where is the evidence of the engineering test results?
30. Where is the evidence of Design Verification Engineering test results?
31. Where is the evidence of Quality Assurance test results?
32. How is your automation testing tracked?
33. How are boundary conditions tested?
34. Which boundary conditions are tested?
35. How do you test for load and balance from these results?
36. How do you test for stress?
37. How do you test for performance?
38. Where are the transactions clearly defined for performance?

Reporting

39. How are the test results reporting working for you?
40. How comfortable are you will the results?  Are they meaningful?
41. Does your reporting reflect the product stability as it is delivered to customers?
42. Could you explain the critical measurements on your dashboard?
43. Are these measurements useful for you?
44. What would you like to see on your dashboard?
45. How much time does it take to collect the data?  Is it real-time?

Adding process moves effort to earlier cycles of the project.  If done effectively, this will remove test, debug, and retest time later in the project and reduce number of iterations required as the project nears delivery.  These problems are due to requirements misunderstandings, design misunderstandings and implementation errors.  While working with your team, the debug process is moved forward in the product life cycle, thereby improving the quality earlier in the analysis, design phases and continuing through the development and delivery preparation phase.