www.hans-eric.com

At some point someone made a promise. Now the team is in a bad position and struggling hard to meet the deadlines of the original plan.

I’ve been in that position more than once, and as a Scrum Master I have used the same strategy:

1. Working with the customer to lower expectations and make the plan more aligned with reality.
2. Find more time for the team to do its work.

The second part would make me cancel everything not immediately helping the team accomplishing its short-term goals. The retrospective meetings were always the first thing that went out the window, and I felt like I was helping the team by doing it.

That was before the first rule of holes was brought to my attention (by Henrik Kniberg).

The first rule of holes: When you’re in one stop digging.

That wonderful quote by Molly Ivins really got me thinking. To bring a derailed train back on track, the solution is not to make the engines run faster. Instead we need to make a careful evaluation of the situation, and find solutions that will help us achieve the end goal of getting the passengers and cargo reach its destination on time.

In software development terms, when the going gets tough, we need our retrospectives the most.

Another way I’ve violated the first rule of holes is the thing I wrote about in my previous post. Although I know that automated tests is one of the best ways to increase productivity, I came up with all sorts of excuses why “it wasn’t for us”. So, I’ve let my teams dig deeper holes and making a bad situation worse.

Yet another common violation is the building up of technical debt. We’re so busy digging for new features that we forget that we have to be able to ascend from the pit. We need to stop digging and clean the small messes before they become drainers of effort.

What holes have you created or ended up in? What did you do about it? I’d love to hear your stories.

Cheers!

Why? Because otherwise you’re bound to get bogged down by the swamp of regression testing.

Regression Testing in Incremental Development

Suppose we’re building a system using a traditional method; We design it, build it and then test it – in that order. For the sake of simplicity assume that the effort of acceptance testing the system is illustrated by the box below.

The amount of acceptance testing using a traditional approach

Now, suppose we’re creating the same system using an agile approach; Instead of building it all in one chunk we develop the system incrementally, for instance in three iterations.

An agile approach. The system is developed in increments.

New functionality is added with each iteration

Potential Releasability

Now, since we’re “agile”, acceptance testing the new functionality after each iteration is not enough. To ensure “potential releasability” for our system increments, we also need to check all previously added functionality so that we didn’t accidentally break anything we’ve already built. Test people call this regression testing.

Can you spot the problem? Incremental development requires more testing. A lot more testing. For our three iteration big  example, twice as much testing.

The theoretical amount of acceptance testing using an agile approach and three iterations, is twice as much as in Waterfall

Unfortunately, it’s even worse than that. The amount of acceptance testing increases exponentially with the number of increments. Five iterations requires three times the amount of testing, nine requires five times, and so on.

The amount of acceptance testing increase rapidly with the number of increments.

This is the reason many agile teams lose velocity as they go, either by yielding to an increasing burden of test (if they do what they should) or by spending an increasing amount of time fixing bugs that cost more to fix since they’re discovered late. (Which is the symptom of an inadequately tested system.)

A Negative Force

Of course, this heavily simplified model of acceptance testing is full of flaws. For example:

• The nature of acceptance testing in a Waterfall method is very different from the acceptance testing in agile. (One might say though that the Waterfall hides behind a false assumption (that all will go well) which looks good in plans but becomes ugly in reality).
• One can’t compare initial acceptance testing of newly implemented features, with regression testing of the same features. The former is real testing, while the second is more like checking. (By the way, read this interesting discussion on the difference of testing and checking: Which end of the horse.)

Still, I think it’s safe to say that there is a force working against us, a force that gets greater with time. The burden of regression testing challenges any team doing incremental development.

So, should we drop the whole agile thing and run for the nearest waterfall? Of course not! We still want to build the right system. And finding that out last is not an option.

The system we want is never the system we thought we wanted.

OK, but can’t we just skip the regression testing? In practice, this is what many teams do. But it’s not a good idea. Because around The Swamp of Regression Testing lies The Forest of Poor Quality. We don’t want to go there. It’s an unpleasant and unpredictable place to be.

We really need to face the swamp. Otherwise, how can we be potentially releasable?

The only real solution is to automate testing. And I’m not talking about unit testing here. Unit testing is great but has a different purpose: Unit-testing verifies that the code does what you designed it to do. Acceptance testing on the other hand verifies that our code does what the customer (or product owner, please use your favorite word for the one that pays for the stuff you build) asked for. That’s what we need to test to achieve potential releasability.

So, get out there and find a way to automate your acceptance testing. Because if you don’t, you can’t be agile.

Cheers!

This is a guest post by Janet J. Fleming.

Are You Going to Get Benefits from a Software Program Testing Job?
 
This is a good question….initially you must see if you have a certain type of personality to accomplish software testing. You ought to be organized, logical and thorough. You will be writing test cases depending on business and functional requirements – or in other words you should do. 
 
Then you’ve to implement those tests – often repeatedly. Your primary goal is always to be sure that no software goes out to your customer without all the bugs found. It’s rarely achievable, but should be your main goal. I always prefer to believe that your 2nd goal must be to have every developer hate you because you keep finding bugs inside their code 🙂
 
The answer if software testing is an excellent career option is dependent upon who’s asking the question. I’ll answer it as if my audience is definitely an engineer.
 
I’m flip, but sincere – my working practical experience has proven to me that the theory of software development never comes about in reality.
 
Theoretically, software testing is:
– Validating and recording that software program performs the functions it’s supposed to.
– Making sure and recording it doesn’t do anything whatsoever it is not designed to
 
This presupposes you have been told what it is supposed and not supposed to do. People you’re working for don’t always do this – they might not necessarily rely on you not to run away with their secrets.
 
Because software program is a business (except when you are doing work for the military) business guidelines apply a lot more strongly than engineering principles. Software testing is expensive, and so the decisions about goals and how much to do can be extremely based on ROI considerations.
 
Inside the end-user relationship, the user’s perception just isn’t necessarily directly related to the physical world, and it’s also the user’s perception of whether your system works that finally rules inside the minds of management, whose job is purely to ensure no one is complaining concerning the software.
 
Therefore, the truly practical explanation of software testing could be summarized as 3 goals:
 
1° Verify the people that use software believes it’s doing whatever they require it to accomplish
 
2° Verify that this software doesn’t do anything immediately detectable that is not desirable for the user.
 
3° Verify that any undesirable action has a sufficient length period that the software will look to perform properly long enough for you to make it to another round of VC investment or sell the business 🙂 
 
And you? Do you consider Software Testing could be the right career path?

Who am I ?: Janet J. Fleming is writing for the software testing course online blog, her personal and non-commercial in nature hobby web site to offer free strategies for software testing novices/specialists to help them get a new work.