Quality assurance testing is an important part of any software project, but QA is especially important on an agile project. This is because in an agile world, we are striving for higher quality, quicker turnaround times, and more frequent releases. This requires that QA is in step with the rest of the team.

On many of the projects that I have been on, the relationship between QA and the rest of the team is decidedly un-agile. Instead it has worked something like this:

• BA writes the technical specifications
• Developer starts working on the feature, and might discuss the feature with the BA to iron out the details
• Developer completes the feature and throws it over the wall to QA
• QA begins to test the feature

There are many problems with doing things this way.

• The QA team has not been included on any discussions about the feature, so they might not be privy to some important information that came out in dicussions between developers and BAs
• The developers have developed the feature without having a test plan from QA, so they don’t really know if QA will find bugs or not
• There was no discussion about how QA should test the feature, so QA might not know how to write a test plan
• It might take time for QA to write the test plan and test the feature, and by that time, the developers might be several days into the next feature
• This leads to situations where developers give features to QA without being sure that the feature is completely working (they just didn’t think of something)
• This leads to an “us vs. them” mentality between developers and QA people

This is not agile, this is more akin to the “Scrummerfall” methodologies that many projects fall prey to. The main problem I see with this is that there is no definition of “done”. If a developer doesn’t know what it takes for a feature to be complete, how can you expect them to complete a feature without any bugs?

I would argue that QA should be involved much earlier in the process. Before a developer writes code for a feature, they should have:

• Detailed technical specifications from a BA, including a list of acceptance criteria
• A test plan from QA outlining how QA will test the feature
• No outstanding questions on what the feature should do (or at the very least, a plan to get the answers within a short time, if it’s a minor question)

Now we have a true definition of what “done” is. Not only that, QA has been involved in discussions much earlier on in the process. QA will be able to discuss with the development team how they will test the feature and they can point out edge cases, potential problem areas, etc. This way, when a developer finishes with a feature, there should be no bugs, because the developer will go through the QA test plan to ensure that everything is working from a functional perspective (along with writing unit tests for their code to ensure that their code is working from a technical perspective).

This feels more like agile to me. Agile is more about building quality into the software development process instead of trying to verify quality through brute force testing. QA has now taken on a new, better role in the process.

• Preventing bugs instead of finding bugs
• Quality assurance, not quality control
• Collaboration with the development team, instead of trying to keep developers under control
• Removing the proverbial “wall” between QA and development

This may require QA to work differently than they have in the past. QA testers will need to be more involved in the software development process, with many of the skills that a BA would need. They might need to learn how to use automated testing tools, which may require some basic programming skills. QA testers will need work alongside BAs and developers while a feature is being developed, writing and refining test plans as you go. Sure, there is still going to be some manual clicking-through-the-app testing, but there should be much less of that now.

To me, this makes much more sense. Now the entire team is working together to build quality into the application. This means less bugs, better team morale, and faster delivery of software. And who doesn’t need more of that?

A lot happens from the time that a business owner envisions an idea in their mind and the time that the idea becomes software. The trick is getting through the whole software development process without losing the original idea.

Have you ever played that party game when you go around the circle whispering the same phrase and when you get to the end the phrase is completely different than when it started? Software development ends up like that a lot (especially when the business owner is changing the original idea!).

The problem is that we all speak a different languages. Developers speak one language, BAs another, PMs another, DBAs another, users another, business people another, executives another, and so on. So a large part of our job is learning how to translate what these people want into developer language (code), and doing it so that, in the end, the software speaks to them in their language.

Here’s a simple example:

Executive: “When we hire new employees, we need to make sure that they have a computer ready for them when they start.”

Business analyst: “User will enter the number of new employees on the screen. The system will check the inventory and make sure that we have enough machines, monitors, keyboards, and mice for the new employees. Each employee should have two monitors.”

Now it’s our turn. As developers, we have to do several translations in the process of writing the software. The DBA (or you) may have to design the database schema. You (the developer) have to write the code.

Remember, the goal is to not lose the original idea. That means that each time we “translate” the original idea, we need to do it little bits at a time.

Usually business analysts don’t give you specs that are written exactly how you want them. This is not a knock on BAs, but they speak a different language than us developers. What we really want from them is a set of acceptance criteria. In other words, we need to know what we have to do in order to complete the feature. Not only that, we need to know how we are going to test our feature so that we know that it’s working.

So let’s take the business analyst’s specs and translate them into acceptance criteria:

Given a stash of unused hardware
   When a user enters the number of new employees
      Then it should verify that we have one machine for each new employee
      Then it should verify that we have two monitors for each new employee
      Then it should verify that we have one keyboard for each new employee
      Then it should verify that we have one mouse for each new employee

   When we don’t have enough mice for new employees
      Then we need to order new mice so that we have one for each new employee

We’re not saying anything drastically different from what the business analyst said. But the way that we wrote it is important. Notice the use of the words given, when, then. Here’s the next translation:

public class Given_a_stash_of_unused_hardware
{
}

public class When_a_user_enters_the_number_of_new_employees 
    : Given_a_stash_of_unused_hardware
{
    [Test]
    public void Then_it_should_verify_that_we_have_one_machine_for_each_new_employee() 
    {
    }

    [Test]
    public void Then_it_should_verify_that_we_have_two_monitors_for_each_new_employee() 
    {
    }

    [Test]
    public void Then_it_should_verify_that_we_have_one_keyboard_for_each_new_employee() 
    {
    }

    [Test]
    public void Then_it_should_verify_that_we_have_one_mouse_for_each_new_employee() 
    {
    }
}

public class When_we_don't_have_enough_machines_for_new_employees 
    : Given_a_stash_of_unused_hardware
{
    [Test]
    public void Then_we_need_to_order_new_machines_so_that_we_have_one_for_each_new_employee() 
    {
    }
}

public class When_we_don't_have_enough_monitors_for_new_employees 
    : Given_a_stash_of_unused_hardware
{
    [Test]
    public void Then_we_need_to_order_new_monitors_so_that_we_have_two_for_each_new_employee() 
    {
    }
}

public class When_we_don't_have_enough_keyboards_for_new_employees 
    : Given_a_stash_of_unused_hardware
{
    [Test]
    public void Then_we_need_to_order_new_keyboards_so_that_we_have_one_for_each_new_employee() 
    {
    }
}

public class When_we_don't_have_enough_mice_for_new_employees 
    : Given_a_stash_of_unused_hardware
{
    [Test]
    public void Then_we_need_to_order_new_mice_so_that_we_have_one_for_each_new_employee() 
    {
    }
}

This is how you do behavior driven development. We took our acceptance criteria and wrote them out as code in the form of unit tests. These unit tests will prove that our code is working (when we get to that point) and it will also act as our documentation of what the code is supposed to do.

The reason that this is important is that we’re still in the middle of doing our translation. A lot of people take the tech specs and immediately start writing implementation code. But by doing that, you skip a step in the translation, and when you do that, you risk losing some of the original intent of the feature. This is one of the reason why writing tests before you write implementation code is important. First of all, if you write your tests first, then when they’re passing, you know that you’re done. Second, you’ve written out what the feature is supposed to do — nothing more, nothing less. This is going to help us implement the feature without losing the original intent of the person who thought it up.

Now, yes now, you can go write the implementation code. By focusing on what the end product should be and since you wrote your tests first, this part should be easy. It’s much easier to achieve your goal when you know what the goal is!

Estimation of features is a critical part of the software development process, especially if you are using an Agile methodology. The ability to accurately estimate features is an often overlooked skill that every developer should have.

As a project engineer, I’m responsible for making sure that we set realistic project timelines and that we actually carry those out. Managing expectations is one of my main responsibilities. This is where Agile is so nice — as long as you do it right.

When I start on a new project, usually one of the first things that happens is meeting with the client or whoever is sponsoring the project. In these initial meetings, at some point I will probably be asked one of two things: 1) how long will it take to accomplish X? 2) how much can we get done before X (some date)?

Let’s think about what is happening here. Your project sponsor is asking you to define what is realistic! This is great! You have one chance to set realistic expectations, and that time is now. Of course, you have to be fair — if you try to sandbag and say that it will take 4 days to add a button on a page, you will probably get called out. But even worse is if you underestimate things, because you will probably be held to your estimates. Once you give the sponsor the project timeline, they will take it to their bosses and spread the word around. So if you don’t get your project done on time or if it’s over budget, then the sponsor is in hot water. Not good.

If you aren’t asked one these two questions (i.e. they say, “We need to have X done by Y.”), that can still be OK. But if what they’re asking for isn’t realistic, now is the time to do something about it. No one likes to be told that what they want to do can’t be done or isn’t realistic. But I guarantee that they will be happier knowing about that up front than when you miss your deadlines.

Things to consider when estimating

When we estimate on our projects, we break functionality into features. Our criteria for features is that they should (usually) be something that can be tested and usually takes anywhere from 1/2 day to 10 days. There are lots of ways to do Agile and people do Agile in different ways, but most people break things up into features in some way.

The biggest problem I see with estimates is that people frequently underestimate things, and that’s usually because they don’t think of everything that goes into developing a feature. When I estimate, here are all of the things that I take into account:

• Reviewing the specs
• Asking questions about the specs and chasing down answers
• Doing the technical design and reviewing it with others on the team
• Writing the code
• Writing the unit tests
• Manually testing the code
• Fixing however many bugs you expect to have
• Working with external servers, web services, and other things that might slow you down
• Extra time if there are lots of uncertainties

In some cases, there might be more things to take into account.

One line that we always say about estimates is that “all estimates are wrong.” This statement is true on a feature-by-feature basis, but not for the project as a whole. This is because your project sponsor is going to hold you to your estimates. Whether that’s always fair or not is debatable, but that’s the way it is. You may not have all of the answers when you estimate a feature, and that decreases the chance that your estimate will be correct. So we need to try and have as many questions answered as possible before doing the estimating.

Sometimes you’ll start work on a project and realize that you’ve underestimated everything. This is not a good thing, but it happens. When this happens, you should re-estimate the features again so that your estimates can be accurate.

You’re also going to have the not-so-fun situation where you have to let your project sponsor know that it’s going to take longer to finish than you originally thought. Obviously this is not going to be a fun conversation, but the time it takes to develop a feature is the time it takes to develop a feature. You can change that reality. So the sooner you can adjust the expectations, the better chance you have of refocusing the project and righting the ship.

Estimating is a great tool for tracking progress and managing expectations, and it’s a reason that I’m such a big fan of Agile. It’s also a skill that every developer needs to master.