Published by Brad Kuhn on 31 May 2007
Test Plan Template Posted
I’ve just posted a new Test Plan Template. Feedback is always appreciated, so feel free to leave a comment.
Published by Brad Kuhn on 31 May 2007
I’ve just posted a new Test Plan Template. Feedback is always appreciated, so feel free to leave a comment.
Published by Brad Kuhn on 25 May 2007
I recently received a question on a previous post of mine about what test documentation should be pulled together for management when you get assigned to manage a test project. I’ve been asked this before, so I thought the answer warranted a post.
Not all of us have managed a test phase or team before. I would summarize preparing and running a test project in five groups of activities:
You should start with the test strategy. The strategy document defines:
Some people don’t see the need for an overall test strategy and write test plans instead, but I prefer a summary level document like this one. One advantage to this approach is that you can develop your test strategy fairly early in the project – but test plans generally require that you’re further along in the project life cycle.
Don’t make the mistake of leaping immediately into the definition of test scripts after you’ve defined your test strategy – you need to flesh out a test plan for each test phase of the project. This includes unit testing (Development should develop this plan). I’ll be publishing a test plan template shortly, so I’ll provide more information in that post, but here’s the type of information the test plan should have (at a minimum):
Here’s a couple of posts that will help in planning and writing test scripts – the first one is on test case planning and execution, and the second one describes a test script template.
If you’ve put together a good test plan and developed a thorough set of test scripts, test execution is a snap! Well, not really – but a large amount of your total test effort should be spent in preparing for test execution. That way you won’t be swamped when all of the unforeseen emergencies land (and they will).
You should regularly deliver test metrics while you execute each test phase. I’ve written a previous post on test statistics, and I’d suggest you start there for some ideas. Also, at the end of testing don’t forget to put together a lessons learned, which should include what went well/could be improved for the next time. You don’t want to constantly hit the same difficulties over and over, do you?
Published by Brad Kuhn on 21 May 2007
Hopefully no one questions the need for testing to be involved in the requirements definition process. But what should that look like? In a large number of companies I’ve worked with, requirements get tossed over the wall to development and testing – perhaps with some discussion between the requirements team and the development team, but not much with the testing team. I’d like to share some suggestions on how the test team can improve requirements and increase the speed to production.
Requirements validation is a process whereby various groups sign-off on the requirements and essentially state – “Yes, this is what we want/agree to build.” Typically people think of validating requirements with the business representatives/stakeholders – but really validation should be performed with all project groups, including development and test. The test team should examine each requirement for the following:
Some of the better managed organizations I’ve seen have at least one person from the test team involved during the requirements gathering process itself, not just at the end. This way, they can help steer the direction requirements take to make sure those items above get addressed properly.
Another item that the test team should provide feedback is on the overall testability of the requirements. Yes, requirements should be testable – but what if a certain requirement can be verified, but testing it is beyond the current capabilities of the test team? For example, a requirement may necessitate an automated test tool that the team does not have. Does this mean that the requirement should be stricken? Or raised to Project Management/PMO as an issue? Or kept as is, but with a disclaimer? It depends on how your organization works. By the way, there’s an interesting discussion on Seilevel’s message board on this particular topic.
Another way that testing should be involved in requirements is on-going education. This is a bit different than validation, which is specific to a given project. Education deals with on-going efforts to improve the deliverables from the requirements process. Ideas to consider include:
Hopefully this post has given you food for thought. Remember, it’s a lot easier to fix issues with requirements than it is to deal with defects in the software, so make sure to take some time to address the items I’ve highlighted.
Published by Brad Kuhn on 18 May 2007
I’ve just posted a template for test case planning and execution. If you don’t have access to a testing tool, you’ll find this helpful in planning and tracking test cases.