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 »

Interesting post over at test Obsessed on the definition of testing.

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 stumbled across an old article that I hadn’t seen before from QualityProgramming.org called “Bug Analysis: Laying the Ground for Bug Prevention”. It’s a very good article on how testing can enable continuous improvement.

A couple of thoughts after I read this article:

• In my experience, it’s the role of the developer to assess the reason for the defect, not the tester. I would never go through someone’s code – I wouldn’t know what to look for! Though I understand that others are much more technical in nature and enjoy this.
• While the activities that are described in the article are spot on, I think there is too much emphasis placed on the Quality Control (testing) team. The real owner of this function is Quality Assurance. QA is responsible for making sure there are lessons learned – doesn’t mean they will do all the work, but they need to be driving this.
• I’ve had mixed experiences doing these things myself. Many times I’ve done defect analysis and root cause analysis; documented my findings with charts and graphs; and presented them to project management/development to discover not much enthusiasm. Maybe it’s me, but I hope not! What have others experienced?