How to develop a checklist for unit, integration and system testing

Wow, this is a big question. As I sit here thinking about answering, I'm a little overwhelmed. My instincts tell me to ask a lot of questions, but I can't do that since Expert Q&A isn't that kind of forum. Instead, let me provide you with some resources that might help you ask a lot of questions. I suspect the best thing you can do is work to understand what's truly expected of you, and then based on your context, you'll be able to figure out what you need in place to get everyone on the same page.

When I'm faced with a new project and I'm not sure where to start, I normally pull out the Satisfice Heuristic...

Test Strategy Model. You can either think of this as a checklist of sorts (all the things you need to think about), or you can think of this like I do, the tool I use to help me build my strategies, plans and checklists. Each section of this document contains things you'll need to think about:

• Test techniques: What types of testing techniques will you be doing at each of the three stages (unit, integration and system)? What would you need to support those types of testing in terms of people, processes, tools, environments or data?
• Product elements: What product elements will you be covering in each of those stages? To what extent will different types of elements be covered in each stage? How will you measure that coverage, track it, manage it from a documentation and configuration management perspective?
• Quality criteria: What types of risks will your testing be looking for with each stage of testing? Will you look at performance at each level? What about security? How will you need to build environments, integrate with service providers, or find tools to do all the different types of testing you'll need to do?
• Project environment: What factors will be critical to your success and the success of the in-house team as you take over this work? How will you take in new work, structure your release schedules, or move code between teams, phases or environments?

Recognize that as you think of those questions, it's a matrix of concerns. A decision (or lack of decision) in each of those categories affects the scope of the decisions in the other three. So you'll most likely find yourself approaching the problem from different perspectives at different times. Then, each day as you learn a little bit more, you can continue to narrow the scope of the work, more clearly define what you think you'll need, and communicate that to the rest of the team.