Carnegie Quality

I recently read Michael Shrivathsan’s post on 7 Traits of a Successful Product Manager (well worth a read, IMO). I thought I’d take a crack at a list for Test Managers. So here’s my list of 7 Successful Traits of Successful Test Managers.

Communication

As a test manager, you communicate – a lot. You need to be aware of the different consumers of your information (such as business stakeholders, developers, project managers, etc…) and their different needs. You need to be able to produce both written and verbal communication at different levels. For example, a status report needs to have some sort of executive summary so the readers can quickly understand the testing status, but also have sufficient detail included for those who need it. During status meetings, you’ll be asked to briefly summarize testing activities, but you’ll also need to be prepared to drill down on specifics. One of the key pieces of value the test manager brings to the project is data – and people will quickly assess your ability to provide that data in the form that they need.
Continue Reading »

As testing professionals, we face problems nearly every day. A key testing resource becomes unavailable. The delivery date to test slips by 2 days, but the test dates remain frozen. Project management needs an assessment on project quality a day after the code reaches test. I could go on – but you get the picture.

In this post, I’ll discuss some common techniques for analyzing and identifying solutions – and also provide some links to additional information.

Continue Reading »

I recently posted a template for a risk management plan. The plan discusses, among other things, how to identify risk. I thought I would spend some space talking about identifying risk from a testing perspective.

But first let me ask a question about why we do risk identification. Is it possible to release a defect-free product? I suppose it depends on your point of view, but speaking practically, the answer is no. In the real-world we have constraints – limited testers, limited schedule, not enough tools, etc… So it is with this realization – no software can be perfect – that risk identification becomes so critical.
Continue Reading »

I’ve just posted a new Test Plan Template. Feedback is always appreciated, so feel free to leave a comment.

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:

1. Define the Test Strategy
2. Document the Test Plan
3. Prepare the Test Scripts
4. Execute the Test Plan
5. Deliver Metrics and Lessons Learned

Test Strategy

You should start with the test strategy. The strategy document defines:

• Any applicable quality assurance guidelines to be followed
• Overall approach to testing (e.g. use of automated test tools, need for regression testing, etc…)
• Overall responsibilities for testing
• The test phases that will be executed and various information about each phase (e.g. description, timing, roles and responsibilities, etc…)

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.

The Test Plan

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):

• Scope (including what won’t be tested)
• Quality risks
• Schedule (including planned test iterations)
• Entry, exit, and stopping criteria
• Test configuration(s)/environment(s)
• Roles and responsibilities
• Defect reporting (including references to documentation on how to use the defect tracking tool)
• Release management
• Test case status and metrics reporting

Test Scripts

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.

Test Execution

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).

Test Metrics and Lessons Learned

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?