The Test Plan Dashboard

This week I needed help develop a test plan for use in another area in the business, and found myself digging out my tried-and trusted Test Plan Dashboard (TPD) template.

The TPD is something I developed back at Kiwibank (through the suggestion of my line manager, Matt Winter), to have a simple, A3 sheet way of displaying what was planned for testing, in order to share with stakeholders and project managers.

I previously talked a little bit about it back in 2011 under Communication – Better Ways Of Doing It, however never showed the final version of what I used.

Anyway, here it is, filled out for a totally fictional project, the “Paint Mixer 2000” (by the way, if you're wondering, Mitre 10 is a New Zealand hardware chain),

I’ve found it to be an invaluable resource to help me fill out the big questions around the testing project.  Questions which of course all testers will be familiar with,

• Introduction – what is the project all about?
• In-Scope – what will we be testing?
• Out-Of-Scope – what won’t we be testing?
• Entry Conditions – when can we start?
• Exit Conditions – when can say we’re done?
• Timescales – how long do we think it’ll take?
• People – who’ll be working on the project?
• Test Environment – where will we best testing on?
• Risks – what could go wrong?

Put it to the test now.  Enlarge the image of the Paint Mixer 2000 TPD picture, and see if in just a few minutes you feel comfortable about what the product is, and what will be tested.

I’ve had phenomenal feedback from the TPD.  Originally designed as a tool to summarise a test plan, I’ve actually used it to revise the way I approach test planning over the years.  Instead of being derived from the test plan, I now use it as a consulting tool to help me build a test plan/strategy on medium to large projects, or as a substitute for a large plan on much smaller projects.

When I was on huge integration projects with a lot of testing elements (many of which you can't hope to be an expert in), I would take a blank copy around all the testing sections (including those external areas) and talk with the experienced testers there in that field or on that technology, and together we’d fill in and scope out what their testing phase would look like.

If you sit together with the experts, you can fill it in on your laptop within about 15-30 minutes, but rather than asking for a test plan at a later date and reviewing, the session is interactive and you can make enquiries of them, adding elements to either the In-Scope or Out-Of-Scope as you go.

Go around each section, and put a whole group of these together, which can be posted on the wall.  It’s like putting together pieces of a testing jigsaw.  Now when you’re looking at creating your master test plan, you can try to draw up who will be focusing on what – you may find there are some elements which simply don’t have a home, and maybe you need to negotiate to get them tested in a certain phase by yourself or an outside party.  It’s a great tool for building a big picture.

And as I learned from the BAs who I worked alongside with at Kiwibank, and used similar tools - it's about harnessing together a collaborated plan, which everyone feels listened to and ownership of, and harnesses everyone's expertise

Last year when I was working on the Building A Test Culture article that was published in the Testing Circus magazine, I was struck by something Janet Gregory said about “make testing visible”.  It’s a comment that gripped me from the moment I read it, and still does.

There is a lot of mystery around testing – much of this leads to misunderstanding.  That makes many testers understandably annoyed.  However for us as testers, the ball is squarely in our court to try and remove that.  I think the TPD is one way to do just that, because it’s a very visual way to look at what our testing charter and constraints are, and unlike a plan that’s kept in a draw, this can be kept on a wall, on display for all to see.  But not just for project managers and business owners – it should be visible for all testers as well, so they are comfortable about what they are testing to, and what the project goals are.

So have a go at making your own, play with it, get feedback and see if it helps to make testing more visible for you.

Returning To Test Estimation ...

A couple of years ago I touched on the subject of test estimation in my article Those Darn Test Estimates.  Following a recent conversation with Jari Laakso I found myself wanting to return to the subject.  Why?  Because although at the time I was happy with that article, today I find the article isn't good enough, the reason being that in the time that's passed, I've learned a few things ...

We are told that as testers the most important relationship we have is with developers, and whilst that's true for junior testers, as we take on more leadership of our team, things change.  Increasingly as we get senior it's our relationship with the project manager that becomes more and more key.  Oh, the rest of the team need to keep networking with those developers, but you become the key relationship point between the project manager and the test team.

For that relationship to work, it's important to know what matters to project managers.  Many people when they start in software testing think project managers are only interested in two things "hours booked" and "percentage done".  Do not be fooled!

Over the last two years at Kiwibank I have been very lucky to work in a business unit of project managers, business analysts, market managers and business owners.  As Dian Fossey did with gorillas, I have managed (through the miracle of co-location) to observe business people in their natural habitat, and in the process learn more about them.

But even that hasn't been quite enough.  To understand more of what I heard and what I saw, I used Johanna Rothman's Manage IT guide for practical project managers.  Not because I wanted to become a project manager, but because I wanted to understand them and their processes.

And so this, in a basic nutshell, is what I learned.  Project managers have two main focuses, which although they link in with "hours booked" and "percentage done" they are not "hours booked" and "percentage done".  They are,

• To manage the budget and timeline of the project.
• To manage the risks linked with the project.

The risks are important - in fact, project managers keep a register of risks much like we keep registers of defects.  There they list potential pitfalls, how likely they are, and how significantly they could impact the project if they were to occur.  Multiplying the likelihoods with the impact gives a list of the top risks, which the project managers focus on.

With that in mind, lets return to the subject of test estimates, and see how we can work more on the same page with project managers in the domain they understand.  Of late I've worked with a project manager named Annabelle, and we've thrashed around our recent test plans until they've worked as below.  It's been a positive relationship, and has really allowed me to see much better how elements of my plan are used,

Estimates - the good, the bad, the ugly

The starting point it to look at the project, the general scope, and just trying to size it up.  There is probably some absolutely fabulous formula out there to do this.  But I think there's just no substitute for past experience.

What past project does this most likely feel like?  Don't be afraid to ask around people to get their experiences as well.  Listen to their stories of how their past projects took more or less time that you experienced in any parallel projects of yours.  Where is the complexity?  What will slow us down?  Are processes we're testing instantaneous, overnight, monthly?  How will that affect how we test?

By now you should feel split three ways on three possible scenarios; "well if everything went perfect", "I guess we might have a few bugs and tests to redo, we normally do" and "OMG, we're screwed".  From Those Darn Test Estimates, that's what we'd normally call Best Case, Probable Case, Worst Case.

But wait, we're not finished ...

Now here's where we can have a meaningful dialogue with our project manager.  I'd always put into any plan a list of my assumptions, but the genius suggestion from Annabelle was that I add a column which said "Impact if wrong".  If my assumption was wrong, what would it mean for my plan and my timescales?  What would have to be redone?

To me this was a game changer, and suddenly I realised I was helping to communicate more to my project manager in a much more direct manner than asking Annabelle to "read between the lines".  Suddenly from a dry list of assumptions, a few of them would stand clearly out, because anyone reading can clearly see "well if they're wrong, this is going to hurt".  This inevitably leads to a conversation around "well how can we get more information to check this assumption or monitor it?".  Suddenly people are being proactive, over waiting for issues to happen.

This of course leads to the issue of risks.  Actually the word is such an important one in software development, it needs a capital, exclamation marks and all kinds of funky formatting ... Risks!!!

It was only recently I had the revelation that when I'm giving a list of risks (with likelihoods and impact of course), what I'm telling to my project manager is this 'these are the factors which will push testing onto the "Worst Case" time estimates over the "Probable Case" ones'.  If you think your project manager doesn't understand this, make it clear by writing that very statement near your table of risks.  It's something we sometimes take the danger of implying, but it needs to come out on the table and be made clear to all involved.

Now, us those conversations you had with other people to help you fill in these risks.  On a first draft, you should really throw to a larger group all the risks people have thought of (if your project if big enough, maybe workshop it), sometimes something that sounds innocent gets someone else thinking "wait a minute ...".  It's important to capture as many as possible, and then truncate and collect into themes.

Like with assumptions, once collected, a few will really just stand out with an "ouch factor", and no doubt make it into the project manager's risk register.  But they're not just there to be something you fall back on when things go bad "look, said it might be a risk, turned out it was".  They, particular the "ouch" ones, are something to be proactive about.  How can you tell early if this is happening?  What can we do about it?

Lets look back at some of the risks I identified first time around, and see if we can be more proactive ...

Software Delivered Late / Software Delivered Is Of Poor Quality

What testing is development planning to do?  Can testing get early copies of software to get a feel for what's being built?  Can testing talk to development about the testing planned to help development in their unit testing?  Can testing get visibility of the testing developers plan to perform for unit testing?

Notice all of these are about dropping the silo mentality between testing and development and working closer together over a passing of baton between development and testing phases.

The Delivery Chain

How can you get developers and testers working closer together, especially if you're not co-located.  How about a daily catchup even in phone conference?  Throw in video if you can (it's the 21st Century after all, and we work in IT).

If the software development is done out of country and you only get weekly builds, can you get the development to try out scenarios on your behalf?

If you are getting weekly builds and the software prevents basic testing because it's so buggy, can development prioritise on those key bugs and get a fix over asap?

Time Erosion

Keep a log of all the meetings needed.  Does everyone need to be at these meetings?  Are you getting value when everyone attends?  Some form of daily meeting can be invaluable, but most people will only need that one.  Leaders can attend other meetings on the teams behalf, and feedback anything key to the rest of the group, likewise providing information up the chain from testers on the ground floor.

It goes without saying - don't try and to major testing sprints over major holiday seasons, and try and work on personal appraisals before/after scheduled busy times.

Requirements

James Bach in his Rapid Software Testing course calls requirements a form of Oracle, or "model of how software's supposed to work".  An Oracle sets up an expectation of behaviour, so when we do something with software and it goes against our Oracle we know "well that's not right".

Requirements are the most obvious "model of how software's supposed to work" that we usually encounter but there are other kinds of Oracle as well.  Can your team,

• Talk to the business owners who put forward this project?
• Talk to end users about what they'll be doing with the system?
• Talk to a subject matter expert?
• Try out similar products which are already out there on the market?

All these things help testers build up a sense of "what the product should do, and what behaviour matters".

Novopay - the tale of a compelling event in the New Zealand IT industry

Open almost any book on testing, and it will start with a "cautionary tale" about software testing, where something was released into production, and it went wrong with devastating results.  They are the ghoulish "tales around the campfire" of our IT industry.

One problem I have found within the New Zealand industry is that as testers we love to focus on anything that goes "bang" and crashes.  In 2011, I was in one a talk about software testing to a group of new developers as part of the Summer of Tech, where our introductory speaker spoke of an Ariane 5 rocket where the parts had been individually tested, but put together into a new rocket.  As you can imagine, this rocket barely cleared the launchpad before it exploded. Another cautionary tale of "you didn't test enough".

What's interested is what happened next.  One of the audience interrupted with "but we're creating applications ... not rockets.  Our stuff is hardly critical like that".

To me, this reinforced how vital it is to have stories and tales of failure which are relevant to the audience.  I thought the tale was a wonderful one, but looking around the room, I saw it failed, because the audience simply did not believe it applied to them.

New Zealand is a small and very pragmatic country.  A lot of processes here are still fairly manual compared to my home country of England, and overall that's not a bad thing.  Here in New Zealand if something isn't broken, New Zealand attitude is "why try and fix it", so,

• In the UK for trains we have automated ticket vending machines (usually vandalised), automated turnstiles to get onto platforms etc.  We used to get told our ticket prices would have to go up above inflation to cover this automation and it's continual repair.  In New Zealand they just have an old fashioned conductor on the train who checks and clips tickets, and can sell you one for cash if you need one (without charging a fee).  Simple, but y'know it works.
• In the UK there were plans to build a so called "chip and bin" system for collecting rubbish.  The UK rubbish collection vehicles would scan your bin, which would then be weighed as it was disposed of.  Back at the main office this data would be collected, and an itemised bill created (your bill would have to be more to cover all this new technology which would have to be developed and maintained).  Again being super pragmatic, New Zealand councils just sell you council marked rubbish bags which have a charge on them for collection.  Only rubbish in council bags is disposed of.  The more you throw away, the more bags you need.  Elegantly simple yes?

An unfortunate by-product of this pragmatic way of doing things is the attitude of "she'll be right", which means if something goes wrong, don't worry, we'll be able to fix it.  This means on the whole New Zealanders can be a little bit more risk takers than their European or American counterparts.

In a testing consultancy I previously worked for, my test manager would talk about how New Zealand would have to face an inevitable "compelling event" for software testing.  Most other countries have had one, but so far although there had been failed there hadn't been one in New Zealand.

A "compelling event" is something that forces you to take action - a wake up call the the importance of the value of testing.  A compelling event isn't just software going bad when it hits production, it's software causing a very large and public pain that it unnerves the local IT industry as a motivation to not repeat that mistake, often with a gasp of "that so easily could have been us".  It's not a rocket blowing up half way around the world, it's software that fails but feels too close for comfort compared to what you're doing right now.

It's a compelling event because once it's happened it compels you to take a good hard look at your strategies around testing and quality and ask "are we (and not just testers here) doing enough?".

Sadly, we've finally had our big compelling event here - the Novopay saga.  Novopay was an online system for managing the payment of teacher and school staff salaries.  But sadly it has gone into production to go horribly wrong, with payments to these people missing in the system.  There have been schools where teachers are missing months of pay (and teachers aren't exactly in the most affluence of careers).  More than just being "missed payments", there have also been erroneous payments gone out from schools - some teachers who've never worked for a school, are receiving payments from that school - and schools are having to bring in extra staff to go through the Novopay payments with a fine tooth comb to work out what's payments are good, what payments are errors and what payments are missing.

The media have been in a frenzy over it, hounding senior staff at the Ministry Of Education (who are behind Novopay) saying they have found a report of "200 known bugs" in the production system when it went live.  It is terrifying to me as a senior tester is how bad that sounds when the media put it like that.

Of course when I worked on an avionic computer, it'd surprise people to know it flew under the strictest of safety conditions, but still there were 1,500 known bugs in the software.  The important message though isn't the bug count, but the severity.  But this is a very difficult dialogue to have with a set of press hounding for a "big story" and "potential coverup".

In an unusual move, the Ministry of Education has released the test plans for the Novopay project into the public domain.  I took a look through, and they show a fairly thorough planned approach was taken to testing, not the slap-dash "rush into production" that many in the press are claiming.  That was pretty unnerving - most of our "testing horror stories" like the Ariane rocket involve people simply not testing, thinking it would be "alright mate".

The documentation they have also shows a decent approach to several forms of functional testing, indeed going beyond what I would have initially thought to do,

http://www.minedu.govt.nz/theMinistry/NovopayProject/NovopayTestPlans.aspx

However for all it's success in testing, something has gone very wrong in production, there can be no doubt about that.  And it is causing real grief to people whose life it should be easing.

What went wrong?  Each of us will have our opinions about this, and no doubt all of us will be right to some extent, whilst at the same time knowing in our hearts how easily something like this could happen to us.

Testing is about identifying and helping to remove risks, but it does not guarantee a bug-free product.  We can test in the many different ways we expect our software to be used, we can check for all the problems we can imagine could happen.  But that will never cover everything, there will always be issues beyond our imagining.

But the imagination of any individual has it's limits.  We have to be careful not to find ourselves screaming "inconceivable" at every bug found in production.  In my opinion, this is why testing and quality is not just a "test team" ticket.  We need to be engaged with developers, business analysts, market managers, usability experts, end users to work out a whole scope of things to test (from areas of functionality to ways of using) that is beyond the imagination we as testers can summon when looking at requirements.  But by then our scope of testing has probably increased by several orders of magnitude, and we don't have unlimited time.

That's when we need to do some risk based analysis, and cover as much of it as possible, touching on all the "most likely" cases, then touching on samples in other areas.  If you find problems, then odds are there'll be others, so keep looking in that area.

For myself then , if there is a compelling lesson to be had from Novopay it is that we need to draw up our test plans as we always have done, and then ask of others "what could I have missed".

Getting your testing project into orbit!

If you look at a the underside of a rocket (hopefully not as it’s about to take off), you’ll find that there are two types of rocket engine with different functions,

• Propulsion. This is performed by the huge rocket engines, and are the workhorse of a rocket where most of the energy and fuel goes. It gives it the power to take off and escape the Earth’s pull and get into orbit.
• Steering and navigation. This is achieved both by much smaller engines (thrusters), and steering mechanisms on the big propulsion engines. They use much less energy but perform a vital function. They’re there to help to steer it and keep it on course.

A rocket launch will only be successful with a good balance of both propulsion and steering. Neglect the main boosters, and the rocket won’t have enough power, and will come plummeting down to Earth disastrously. But neglect the steering mechanisms and the rocket will be unstable and easily topple over, leading to a similar fireball.

Much like the engines of a rocket, I like to see testing activities as a similar context, they’re either for ‘moving us forward’ or ‘steering us in the right direction’.

Without doubt the activities that moves us and our project forward are those of actually executing tests, raising defect and reporting. This is how we add value to our products – we find problems and work with developers to resolve them. This is how we make our product better, and really we should aim to spend as much time and energy in here as possible.

And though we’d ideally like to spend less time on them, our steering activities are still important, because they make sure we’re on course with our main task. These activities include,

• Test estimation
• Test planning
• Requirements review
• Test scripting (and automation)

These actions by themselves have no real value, only in the way they have a relationship with our main activities.

In an ideal world you should look at the time and effort you spend on all these activities during testing a project. If you feel you’re spending more time on ‘steering’ activities than ‘main thrust’ activities something is wrong, and you’re not spending enough time on the core of where you deliver value.

This happened a few years ago – I worked on an automated project, where our scripts were often over 10 years old, and very badly coded in places. So frequently our scripts would often fall over and we’d spend a lot of time and effort during regression testing running them and fixing them. It became a bit of a joke that we ‘were getting very good at testing our scripts’ … but not so much our product.

Sometimes to just get it done it was easier to just run them manually! But that's the point. The value of these tests wasn't in supporting the automation, but to actually have the test execute the desired function in our test application.

The obvious and idealised model then for getting your testing where it needs to be is all about getting as much testing and hands-on the product as possible – this is your propulsion, your core activity as a tester.

But you also need to do just enough of the navigation tasks so that you know all this effort is pointed in the right direction to deliver what your business needs. If some task is becoming arduous (as with some of our automation), the big question has to be “is it really adding value to my core activity”. All your steering tasks should have a clear contribution towards your core tasks, if it’s not making the test execution phase better, then it’s probably excess baggage time-wise and needs a bit of trimming.

Test scripting is a good one for this. If you are writing complex and arduous scripts but having no access to your product when you do this, you have to wonder if this is going to really add value. How do you know your script will align to the finished product? Wouldn’t a lighter scripting approach, and using the product as you write them be better, because you’ll actually be doing some execution (and thus finding bugs as you go along).

Likewise with test plans. It can be tempting sometimes to try and make an iron-clad plan of all kinds of details, which is great if you have all that information to hand. However I’m frequently finding that no matter what you put in your test plan, there’s always something you’ve missed or has changed. Projects are almost living creatures with an ability to morph, change, grow from inception. Better to get a plan together, and up-issue it as changes evolve.

Get the balance right in your testing tasks, and there’s no heights you can’t reach …

Those darn test estimates …

How long is a piece of string?  I'm tempted to be a wise-ass and say that to project managers when they ask me “how long will it take to test my project?”.

That's actually unfair, experience gives us as testers an idea, based on similar projects, of how long it'll take to test.  But one of the problems is, testing is an activity which has a complex relationship with other factors in a project – we can keep testing and testing, but if development don't start fixing some bugs, we're going to be here forever!

So yes, we can look through the designed features and estimate how long it will take to script, and how long to execute those scripts.

But how long until the product is finished testing?

How long is a piece of string?

Having worked in a test consultancy, there is no doubt about the importance of estimates.  They need, when a project manager looks at them, to be attractive but also realistic, with some contingency.

What we introduced was a list of estimates for testing tasks for “best case”, “probable case” and “worst case”.


                BEST   PROB   WORST
Test Plan         1 2 4
Test Conditions   2      3      5
Test Scripting    4      7     10
Pre-Testing       2      4      6
UAT Execution     4      5      8
Retesting         2      5     10

This gives the test manager some leeway, usually if things go okay it should follow the Probable estimates.  If they book the Best case estimates, be very worried.

What I'm finding is my project managers are taking my estimates, adding the Probable case figures together and times it by an hourly rate to get a budget. I don't know why I'm so surprised ... makes sense, but I'm used to working against time and not $$$.

Unfortunately at the end of the last two projects we've been considerably over that budget.  There seems to be several factors at play which determine which of those estimate paths our testing is going to follow, and it's important to understand and recognise them.

Software Delivered Late

You book in a test contractor to help you test for 6 weeks.  They arrive on week 24 to start analysis and scripting, with some test execution happening in week 26 for 4 weeks.

Then your chief developer tells you there's going to be a 2 week delay getting the build together, it won't be available until week 30 now.

You've made a commitment to your test contractor, and are so obliged to pay him, and possibly find them other work.  If you can't get them to assist elsewhere, then by week 30, you're 4 weeks in and not testing yet.  You've blown over half your budget, and Lord help you if there's any more delays!

We all know developers can often deliver late.  Late software is going to burn up budget.  You need to work with your Project Manager to make them aware of their duty to get software to you as scheduled in order for your budget to be met.

Software Delivered Is Of Poor Quality

Kind of the flip side of late delivered software.  Your vendor has promised that the software delivered has been unit and system tested, and no bugs were found.

You wrote your test plan for acceptance testing, expecting the software to have been extensively tested beforehand, with a certain level of quality.  Your project manager and you are expecting what's delivered to be a candidate for release.  You turn it on, and immediately notice a dozen problems, not able to finish basic use cases.

The developers under duress delivered what they had available to schedule instead of flagging any delays.  Little if any testing has happened, and basic bugs are being discovered only now.  Testing 101 says "more bugs = more fixes = more builds = more retesting".

One thing I try and do with vendors is ask for a release note and end report for testing, detailing what defects were found and what were fixed.  This is a bit of a game of bluff.  If I receive an end report which says “everything was tested, and no defects were raised” I get suspicious.  Very suspicious.

I've also had vendors on conference calls inform me “we're running a build up now, you'll have the install delivered in an hour”.  I pull my project manager to one side when this happens and warn them that maybe that will mean no testing whatsoever has been done …

The Delivery Chain

If you have developers on-site who you can give defects to, they fix, build, test it's possible to get a build almost every day.

If they're off site, only receive defects daily, have to courier builds, you'll be hard pressed to get a build weekly.

If you have two weeks to test, and have a daily build, you'll have 10 opportunities to get it right.

If you have weekly builds it's not likely to happen.  Your second build will have to be perfect – and it usually takes about 3-4 even with an initially high quality piece of software (there are always tweaks needed).

Time erosion

It's so easy to happen.  You have,

• a daily half hour team meeting
• a one hour weekly project progress meeting
• a one hour weekly project technical meeting
• a daily 15 minute end-of-day defect wrap up meeting
• each day you spend half an hour writing a progress report for the concerned business owner

Oh you're giggling there, but we've all been there.  Did you add it all up?  Yes, you're losing about a day a week.  Look at your estimates, did you plan on there being so much leakage?

I'm finding we're increasingly working on projects where there are a large amount of meetings to keep track of progress.  This needn't be a bad thing, and small meetings daily can help set the direction and key priorities of the day/week.  But it's easy for reporting to actually delay any progress being made, and become a sizable and unknown overhead in itself.

And some projects need test management – how do you budget for that?  It's not a solid “task” again more an ongoing overhead.

Requirements?

Requirements?  We didn't have time to write down everything we asked for!

Due to constraints a project has been only broadly defined, but you're required to perform specific testing against it, to a limited timeframe.  Oh and business analysts are too busy to answer your questions, so just get on with it and you know, test!

This is a nightmare position to be in.  You press a button, a message is displayed.  But you have no idea if it's the right message or not.  There are some things you can do – you can check the application didn't die when you pressed the button, and the message made sense in the context of the button.

But if you have vague requirements, you can only vaguely test.  Such projects really feel like they're setting up the test project to fail.  And take the blame.

Another variant of this is you raise about 10 defects against requirements, there's a review, and a business analyst says “oh yes these aren't defects, I asked for these changes by phone from our vendor”.  If things aren't documented, how can anyone keep track of these changes?

Take it easy.  Take it nice and slow.  That's no way to go.  Does your PM know?

Thankfully there's usually a place for these factors in a test plan under risks and assumptions.  But I can't emphasise enough to you the importance to talking them over time and again with your project managers before you embark on any test estimates, so they can understand and more effectively evaluate the risks and the impact to budget.

Spinning Plates – The Test Manager's Stage Show

I've been a test manager about 6 months now all told ...  As a senior tester I used to scoff at what my old test manager got up to – but now I know!

If someone asked me what it's most like, to me it would be spinning plates …

We know the stage show.  Someone sets about 6 plates spinning, and keeps rushing between them to give them an extra bit of momentum to keep spinning and not fall off.

And that's pretty much what I do – our company has a whole host of projects in the pipeline.  I look at the future load for the next few months, and get involved in early meetings about them, review business requirements (if they exist), write the original master test plan, work out how much effort it should require to test, and try and organise test resources so we've got someone to do the actual testing.  And maybe a bit of sleight of hand to keep two projects from getting to testing at the same time ...

It means getting involved in a lot of projects.  Our department is part of customer delivery, and a lot of projects as you can imagine come through us for testing.  I always need to have a trick up your sleeve in case something comes late so we're not busting the budget.  Have a rabbit in the hat, just in case I need extra resource because time's running out.

As a rough rule of thumb (and don't tell my project managers) I always plan for myself to do pure test management … so when things get tight, I can go “all hands on the pump” and magic almost an entire tester out of thin air for 30(ish) hours a week.  Of course that can only be a short term band-aid, and on some projects that's not enough.

But all of the above can become tiring!

In Agile it's said you become much less effective if you're always task switching during the day.  Something like 20% they estimate.

Yesterday I kept track, and I worked on 5 projects during the period of the day.  Ouch!

Although joking about it on Twitter this morning I am starting to show some signs of fatigue.  Getting bits mixed up between projects, when someone asks me a question there's so much I am working on, it takes me a while to straighten it all out mentally.

At the beginning of the year after being “on the bench” (not working on site and doing desk based training) – I was sharp, eager.  Now come October, with an unforgiving workload, we're just getting by week to week.  All the promise of trying to improve processes in March has been whittled down to “just get it out the door” - and not by management, but by me.  The delays that are part of any testers lament have forced us into a level of technical testing debt, and we're having trouble getting things out to time because we're so close to delivery dates.

And I know I've talked about it before in this blog – but no-one wants to be the one to tell the business owner their delivery dates are unachievable, especially when everyone else is saying there's no problem.

I know people should have the courage to, but everyone quite rightly wants to give it their best shot at achieving it first.

So right now, I'm realising we're in a kind of testing deathmarch.  There are things we need still to get out this year.  But we have a freeze from late November onwards – I'm hoping we'll be able to catch up on ourselves a bit then, and hopefully set up 2012 for a bit of an easier year.

Otherwise I'm sure we're all headed somewhere in a very large basket ...