How to develop a checklist for unit, integration and system testing
When taking IS development in-house, learn how to develop a checklist to make sure test environments are in place and people know what to do.
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.