Carnegie Quality

I’ve posted a checkout test plan template at this link.

Checkout Testing Defined

Checkout testing has a very specific purpose – that is, to verify that a deployment (usually to a Production environment) was successful.  Checkout testing is concerned with making sure that the deployed system is complete, stable, and in working order.  Checkout testing is not concerned with finding defects within the developed code – hopefully the code went through numerous testing phases (e.g. unit, system, UAT) that identified all of the issues already.

Think about the typical weekend deployment – the technical team does all of the code migration activities, then usually one or two people are responsible for making sure things work.  The last thing you want after a long deployment weekend is to get a call at 8:00am Monday morning from a user complaining that the system doesn’t work, right?  Making sure that doesn’t happen is the purpose behind checkout testing.

Why Document a Test Plan for Checkout Testing?

If you take a look at my template, you’ll see that it is not a large document – so it shouldn’t take a lot of time to produce the document.  Why do it?  Two main reasons:

1. Rather than let your checkout testers just wing it, if you put some time into planning the checkout test you’ll stand a better chance of making sure you don’t miss something.
2. Having a documented checkout test plan will save you time and effort across deployments.  You’ll be able to pull out the previous deployment’s plan when the next release comes.  You can also improve the plan by making sure you perform lessons learned checkpoints at the end of your project (e.g. was something missed during checkout testing?  If so, document it so it gets into the next version of the plan).

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 »