If you’re a developer, why do you do the work that you do? What’s the goal of all of the frameworks, databases, code, and tests that we swim in every day? I’ve been doing this professionally for ten years now, and I’ve noticed an interesting progression, and it wasn’t one that I had pursued originally.

Early on, I wanted to work with new technology. The goal was to do cool stuff with the latest technology and find new, better ways to do what used to be harder in the previous year’s hotness. Working at a consulting company was great for this. I got to do new projects every 6 months that often were greenfield and we usually got to pick the technology. Now we were smart about it and we weren’t just doing “resume builder” projects where to tried to use some new framework for the wrong purpose. We were delivering value. Everyone would always hope that they would land on that cool project using the latest stuff, and whoever wasn’t on said project would want to talk to everyone on the project and see what they were doing.

Two years ago I joined a Ruby on Rails project and spent a year in the Rails world. This was the pinnacle of hot technology (at least at the time). I loved how elegant the Ruby language was, the Ruby gem ecosystem, and the Ruby community’s focus on quality and testing.

Eventually my time on that team came to an end and I came back to .NET. I have nothing against .NET, but in terms of geek cred, many people would consider .NET a step back from Ruby (but that’s not the point).

What I noticed from my transition to Ruby and back is that no matter what the technology, the code isn’t what’s important. What is really important is how we interact with users and how we can structure our process and teams to best deliver quality software in less time. We need to value people over the tools that we’re using.

The longer I’m in this business, the more I realize that software development is all about people. It’s about using technology to help improve the lives of the people who use our software, that somehow we can use our coding skills to help them be more successful at their job. It’s about the people that we work with on our team, it’s about helping them feel everything that comes along with working alongside others to help the team achieve a common goal. It’s about looking out for those team members who are feeling overwhelmed by their workload and struggling to hold on to their confidence.

I still geek out on code, and I’m still glad that I get to spend most of my workday writing code. The means may be the same, but the ends have changed.

There are many ideas and principles in software development that we believe to be true and often are non-negotiable for us.

Here’s a challenge for you – challenge the assumptions that you have. What if they’re not true?

For example (not that I believe any of this, just throwing it out there):

• What if TDD is a waste of time?
• What if estimating in hours is better than estimating in story points?
• What if pair programming is an inefficient use of your development team?
• What if pair programming is the most efficient use of your development team?
• What if a relational database is not the best way to store data?
• What would happen if you developed a given feature and put it into production without QA testing it at all?
• What if sitting in a co-located environment is less valuable than being able to sit in a cube with less distractions?

Like I said, I don’t necessarily believe anything I just said. I’m just trying to make your blood pressure rise a little bit when you think about some of your core principles being false.

The reason I think that this is a valuable exercise is that it forces you to think outside the box and honestly evaluate the way you do things. Most of our core principles depend on the situation. That’s why I get frustrated when people take a prescriptive process like Scrum and say that you have to follow the Scrum rules exactly as they’re laid out or you’re introducing “scrum-buts” into the process. If you haven’t adapted your process to fit your team and your environment, that would be a red flag to me that you might not understand your process or that your not trying hard enough to find ways to improve.

I don’t want to ever stop improving. I’m not going to be naive and think that I have everything figured out. At one point I thought that Windows Forms
data binding was awesome, and after that project was over, I realized that that was the totally wrong approach.

I really took to heart a quote that someone said at CodeMash a couple years ago, “If you don’t ever fail, you’re not trying hard enough.” It’s OK to fail, and when you do, you’ll learn something from it and come out a better person. But if you’re never willing to fail or too scared to consider that maybe your way is not the best way, you’re not going to take that next important step.

I’ve always said that software development is a series of translations — that we need to incrementally translate business processes to business requirements to acceptance criteria to test plans to tests to code to working software. This is why we write acceptance criteria in the Given/When/Then syntax — it’s a common language that developers, BAs, testers, and business people can use to make sure that we’re all speaking the same language. These kinds of requirements define what the system is supposed to do for the business.

All this is good, but there still are problems. Let’s say that your BA writes some requirements and you implement a feature. Several months later, you get a new requirement to change that code, or someone asks you what the code does for a certain feature. How do you find the code for that feature?

Or maybe you have some common validations that happen many times throughout the application. Are your BAs copying and pasting the rules for that validation over and over in the requirements documents?

What seems to be missing here is another layer of translation. We have too big of a jump from our typical business requirements to our code, and no way to map the two to each other. The acceptance criteria tell us what the code should do, but nothing tells us how to do it.

On my current project, they’ve come up with an ingenious way to solve this problem. (I have to preface all of this by saying that none of this was my idea and I can take zero credit for it. They were doing it long before I joined the team.)

Our system does transaction processing with incredibly complicated business rules. All operations are written as command classes and workflow classes (which are a series of commands).

Our requirements are structured the exact same way. In the requirements we have commands and workflows that are named the same as the classes in the code.

Example

Let’s say I’m building an order processing system. Here’s how we might break it all down.

High-level business requirements

When an order is processed, the order total is sum of the cost of the products + tax + shipping. Save the order information and the total price to the database.

Tax depends on where the order is being shipped:
Ohio – 7%
Michigan – 6.5%
Any other state – 0%

Shipping:
If sum of the cost of the products >= 25, shipping is free, otherwise $5.

System requirements

Workflow: Process Order
1. CalculatePriceOfProducts
2. CalculateTax
3. CalculateShipping
4. SaveProcessedOrder

Command: CalculatePriceOfProducts
Total Price = sum of price of each product on the order

Command: CalculateTax
Tax is calculated based on state the order is being shipped to. Can ship to US states only (including DC).
Ohio – 7%
Michigan – 6.5%
Any other state – 0%

Command: CalculateShipping
If total price of products in the order >= 25, shipping = $0
Otherwise, shipping = $5.

Command: SaveProcessedOrder
Save the following information to the database:
– Products in the order (save current price in case the price of a product changes after the order has been processed)
– Tax amount
– Shipping amount

Acceptance tests

We’ll write unit tests for each command. There are 153 different combinations of shipping (>25, =25, <25) and tax (51 states), so our unit tests will cover all of the permutations. We’ll write acceptance tests to cover some of the most likely scenarios.

Scenario: multiple products with total < 25, shipped to Ohio 
    Given an order with the following products:
        | Product  | Price | 
        | Mouse    | 4.00  |
        | Keyboard | 20.99 |
    And the order is being shipped to Ohio
    When I process the order
    Then the tax should be $1.75
    And the shipping should be $5.00
    And the total price should be $31.74

Scenario: one product with total = 25, shipped to Michigan 
    Given an order with the following products:
        | Product | Price | 
        | Mouse   | 25.00 |
    And the order is being shipped to Michigan
    When I process the order
    Then the tax should be $1.63
    And the shipping should be $0.00
    And the total price should be $26.63

Scenario: one product with total > 25, shipped to Indiana 
    Given an order with the following products:
        | Product | Price | 
        | Mouse   | 25.01 |
    And the order is being shipped to Indiana
    When I process the order
    Then the tax should be $0.00
    And the shipping should be $0.00
    And the total price should be $25.01

Why this is awesome

This has made everything so much easier for everyone. Developers and system analysts can easily communicate because we speak the same language. When we get new requirements that change existing code, the systems analysts even specify which commands and workflows we need to change. Now I know exactly where I need to go to change code without having to do any research!

Duplication is bad in code and it’s bad in requirements. When a new workflow needs to be created, they can reference existing commands without having to copy and paste requirements. The commands and workflows are in a big Word document with links so that I can easily navigate around the document.

Because all of the commands and workflows are outlined before we write the code, most of our design work is done for us. I know what classes I need to create. I know the specific things that each command needs to do, and I can easily unit test them. We have some older code in our application from before they switched to writing requirements in the command pattern. These classes tend to be too big and they’re much harder to decipher, partially because I can’t easily figure out how they map to the requirements. Every time we encounter one of these, we want to refactor it to match the requirements.

Estimation has become a lot easier. I can look at each command in a workflow and get a sense of how hard each one is (or which commands are existing commands that I can reuse), and I already know how I’m going to design my code for the most part.

Keeping requirements up to date is a challenge on any project, but this has helped us do a pretty good job of it. But when you have well structured requirements that don’t have stuff copied and pasted all over the place and you can easily compare a class and a section of the requirements with the same name, updating requirements becomes a lot easier.

The command pattern is a good fit for our application, but your app might not lend itself to the command pattern as well as ours. That’s fine, see if you can come up with another pattern if you want. But sit down as early as possible and see if you can come up with a way to structure your requirements and code using the same patterns.

As you can see in the example, we still have acceptance criteria in the Given/When/Then format. The acceptance criteria help define what the system is supposed to do and how we’re going to test it. The business requirements that we write in the command pattern define how the system is going to accomplish those goals. This method has filled that translation gap between business-focused requirements and code and has had a huge impact on our project.

Ah, requirements. Gathering requirements is really hard. I’m not a BA, but like most developers, we’ve had to gather requirements at some point. You have to meet with users who might not have enough time for you or might not be able to make up their mind. Then you have to take their ideas and understand the business problem enough so that you can write up requirements. You have to try and find the balance between giving the users what they’re asking for and giving the users what they really need but don’t know it yet. It’s a fine line for sure.

I’m not going to sit here and bash BAs for lousy requirements. I’ve been the one who wrote the requirements only to have a developer mock the requirements (they probably didn’t know that I wrote them or that I was listening, but that’s neither here nor there). I tried really hard and I thought I did a good job. But nevertheless, there were things that I didn’t really think of that the other developers thought of.

Since we know that requirements gathering is hard, what can we do to make sure that we don’t end up with ambiguous requirements, we make it easy to test, and we make sure that we actually give the users what they want?

The key is that we need to find common language that people in different roles can agree on so that we can all be on the same page. Users, BAs, QAs, and developers all think differently and speak different languages. So we need to find a better way to communicate and a better way to write requirements.

The way that we do this is using the Gherkin language, or Given/When/Then format. This goes something like this:

Feature: Transfer money between accounts
    As a user
    I want to be able to transfer money between active checking accounts
    So that I don't overdraw my account
    And I don't have to go to the bank to make the transfer

Scenario: Transfer positive amount
    Given a checking account "A" that has $100
    And a checking account "B" that has $50
    When I transfer $10 from account "A" to account "B"
    Then the transfer should be successful
    Then account "A" should have $90 
    And account "B" should have $60

At the top of the file we have background information about what the user wants to do and why they want to do it. Then we go step by step and identify all of the scenarios in the Given/When/Then syntax.

So what’s the big deal? Aren’t I just writing the same thing in another format? Yes, but the good thing about the Given/When/Then format is that it helps you find the holes in your requirements and think of all the details and edge cases. If you’re requirements are more in paragraph form with some bullet points, it’s really easy to miss things, even if you’re smart and trying to do a good job.

Essentially what we’re doing here is writing test scripts. As a developer, I want to know how QA is going to test my code. Not only that, I can take these scenarios and automate these tests with acceptance testing tools like SpecFlow or Cucumber or with plain old integration tests or unit tests.

What we did here was establish a common language between everyone involved. This will help BAs think in a detailed, logical way that ensures that they don’t miss things in the requirements. This will help developers because they won’t have to write code to hit a moving target or get stuck waiting for answers to requirements questions. This will help testers because all of their test plans get written up front before the development happens, so they don’t get stuck trying to figure everything out on their own after it’s been developed (and the BAs do a lot of their work because they write their test plans for them). Not only that, this gives the development team the chance to automate the tests. This will help users because once we get the Given/When/Thens done, we can take that to the user and ask them to confirm that we’re building the right thing. We’re still using their terminology, and the syntax will help them think of cases that maybe they hadn’t thought of initially.

If you write your requirements this way, if you get everyone involved up front, and if you write your code to make the tests pass, you should be completely done when you finish development. Because you wrote code against detailed requirements that were written without ambiguity in a manner that makes it easy to write tests for it, you should have no bugs (or at least very very few bugs). QA won’t have to spend lots of time afterwards trying to figure out how to test the feature. And hopefully the users are getting what they want.

The conventional wisdom on TDD and testing is that unit tests are the preferred kind of tests to write. They help you design your code, and they run fast. Integration tests and acceptance tests are important too, but you should have far fewer of these. They exist so that you can have some end to end tests and to help test things that you can’t easily test with a unit test.

You may have also seen the automated testing triangle diagram, which illustrates how you should have more unit tests than the other kinds of tests and how the unit tests are the foundation of your test suite.

The implication of all of these diagrams and ideas is that this is the best way to do it on every project. But is that true?

I would argue that there are situations where integration tests and acceptance tests are more important than unit tests.

But wait, you say, aren’t you the guy who is always speaking about TDD and the value of unit tests?!? Was that all a lie?

Once again, the correct answer is… it depends!

Take my current project for example. We are writing web services that do back end transaction processing. Our system is very configurable, so we can make the system work very differently based on some configuration tables in the database, and different configurations are used for different types of transactions.

We have a very well defined framework. Even before I start coding a feature, I know what classes I need to create because they were defined up front with a systems analyst. So I’m not really going to get any benefit from TDD designing my code because the design work is already done.

Because the system is so configurable, we can handle new kinds of transactions by inserting new configurations into the database. There is very little coding involved. Sure, I could write unit tests for the configurable components of the application, but unit tests can’t tell me if the system works correctly for my new configuration. The best way to do that is with acceptance tests.

Not only is our framework well defined, we follow the SOLID principles and have lots of small classes that work together. I could write unit tests for all of the small classes, and in some cases I do, but in
most cases I find that the unit tests aren’t testing very much. Not only that, they tend to have lots of stubs and mocks, which makes the unit tests very brittle. Usually the integration tests and acceptance tests are more brittle, in our case, it seems to be the other way around. Nothing seems like a waste of time more than updating an existing unit test that broke because you refactored a seemingly unrelated class, especially when you have a nice acceptance test that is working just fine.

I’ve just shot down many of the positive arguments for unit tests on our project. Because it’s very important for us to test that our system is configured correctly, acceptance tests become very
important.

Well, if I already have a big suite of acceptance tests, do I really need unit tests to test things that are well covered by acceptance tests? Maybe if I have some class that has many different permutations, but if there’s only a couple paths through a class and I’ve covered it with acceptance tests, then I’m just going to skip the unit tests.

We also use stored procedures to do most of our data access. You can’t easily unit test a stored procedure, so we need more acceptance tests and integration tests to take care of that.

We still have about twice as many unit tests as acceptance tests, but that tide is turning. In a couple months, we will probably have twice as many acceptance tests as unit tests.

It honestly took us awhile to convince ourselves that we weren’t doing it wrong based on the conventional wisdom. But when we thought about it it just made sense to do it the way we’re doing it.

The moral of the story is that there are always exceptions to the so-called “best practices”.

A few of us have been talking and have decided to start the Columbus ATDD Developers Group. If you’re in the Central Ohio area and you use tools like Cucumber and SpecFlow, believe that testing is not just for QA people, or if acceptance test driven development sounds interesting to you, then this group may be for you. This is a developer-focused group, so expect to learn things about how to write code using BDD testing tools, design patterns and practices, how acceptance tests mesh with your unit tests, and other developer topics. QA people are always welcome too, especially the technical-minded ones! Absolutely no experience is required, just come ready to learn.

Testing is not just for QA people, and BDD testing tools like Cucumber and SpecFlow have really helped me speak to business people, BAs, and testers with a common language and automate acceptance testing for my features. This hasn’t all been easy, and I’ve had to learn a new set of workflows, tools, and patterns. I found that I’ve asked a lot of questions about agile testing and BDD tools on Twitter and I’ve called people up when I’ve had questions on how to do things, and having those connections have really helped me out as I work through the learning process.

We are going to meet on the 1st Thursday of the month from 11:30-12:30 at various locations around Columbus. We’ll probably move the group around so that the same people don’t get stuck with the drive every month. This is an informal group so we’ll have open discussions as well as presentations and people showing their code. We want to hear everyone’s questions and ideas.

Our first meeting will be Thursday, March 1 from 11:30-12:30 at IGS Energy in Dublin. We will have an open space style discussion about Adopting ATDD in Your Organization. Some of us are far along down this path and some are just starting out, and we can all learn a lot from each other’s experiences. So come with your questions and ideas to share. And because IGS Energy is awesome, they will hook you up with free pizza and pop.

If you want to keep up with the group, we are in all the usual places:

• Blog (we’ll post meeting announcements as well as guest posts about ATDD topics!) – http://columbusatdd.wordpress.com
• Twitter – @ColumbusATDD
• Google group

I probably won’t post meeting announcements on my blog, so go follow the RSS feed on the blog.

Hope to see some of you there!

Part of being a developer is taking requirements that are written by business analysts and understanding the business problem and the requirements enough to develop a working software solution to solve the problem. In most environments, BAs will work with the developers to help them understand the feature. Once the developers are done, the QA team has to try to understand all of the requirements that the BAs and developers already covered extensively.

You can run into multiple problems here. First, many business analysts write requirements in a format that are not detailed enough to outline all of the edge cases. This is not a knock on business analysts, but they often think in terms of use cases and how the business will use the functionality. But this is why we have a team. Business analysts are better at thinking about the needs of the business and how the app will solve business problems. Developers and testers are good at thinking about the details but sometimes don’t always see the big picture.

This is why it’s so important to bring all of the team members together so that we can take advantage of all of our strengths. We do this in a meeting we call the “three amigos”.

How It Works

A three amigos meeting consists of a business analyst, a QA tester, and a developer. If it’s a larger feature that might involve more than one developer or more than one tester, then you might have more people in the meeting. The BA has written up all of the requirements beforehand, and ideally everyone in the meeting will have read through them before the meeting so that people can have a basic understanding of the feature and can come with their questions.

Once we all have a basic understanding of what we need to develop, we read through the requirements together and someone starts writing all of the test scenarios on a whiteboard. We’re not writing out the complete test plans, we’re just covering the scenarios that need to be tested and maybe some of the things that each scenario will check for. The primary goal is here to figure out what needs to be tested and how we’re going to test each scenario (unit tests, acceptance tests, or manual tests).

Outcomes

The primary outcome of the three amigos are acceptance tests written in Given/When/Then format. Actually writing these out can take a little time, so we don’t do that with everyone sitting in a room. Typically a developer or a tester will work on it outside of the meeting, and once they have the scenarios all written out, then we do a quick review with everyone else that was involved in the original three amigos meeting to make sure that we all agree with what was produced.

Benefits

When you get everyone involved up front, you spread the understanding of what’s being developed across multiple team members. On most teams, BAs and developers have a good understanding of what’s being built, but QA people are left in the dark until you’re most of the way through the process. This way, QA people know what’s going on and they can add their valuable input before a line of code is written. As a developer, this will also help you because the QA people helped you agree on the acceptance criteria that you’ll need in order to complete the feature. No more guessing about what QA is going to test or whether you’ve built everything that needs to be built.

Automating acceptance tests becomes much easier when QA people have helped you come up with the tests and have agreed on them. This is also a good chance to talk to the QA team about what you’re going to automate so that they know that they don’t have to spend as much time manually testing scenarios that the developers have fully automated. Remember, we’re all on the same team, and we’re all responsible for quality. It shouldn’t matter who is testing something as long as it gets tested.

In the end, you end up with fewer bugs because developers know what they need to build and they have everything they need to build it with no coding errors. Certainly this works much better if you’re writing automated unit tests and acceptance tests, but even if you aren’t, at least you will know what you need to build and what it needs to be able to do in order to pass all of the QA tests.

Exceptions

As with everything in software development, it helps to use common sense. We typically don’t do three amigos meetings for really simple features. There’s no hard and fast rule about this, so you have to use your head. If it doesn’t make sense to have a meeting with a bunch of people to review something that you can handle with simple hallway conversations, then go with that.

We don’t always do three amigos on bugs either. If it’s a coding error, there isn’t much to discuss, it just doesn’t work correctly. If we missed something in the requirements, it might require a bigger discussion about the new requirement.

I think that it’s dangerous to make blanket policies that say that you must have a meeting or a certain amount of documentation before you start development on something. The goal is to develop working software that meets the needs of the business with a sufficient level of testing and documentation. You have to decide what that is and how you get there.

On my current project, we release every 2 weeks. We do the push to production on Saturday, so we set a deadline of Wednesday night for everything to be developed and tested so that we can have two days for demos and UAT.

I remember a certain Wednesday a couple of months ago where things were chaotic to say the least. We looked at the board on Wednesday in the early afternoon and there were 20 items where testing was not complete. We were running around trying to make sure that everything got tested. The entire development team was helping out with testing. Many people stayed past dinnertime to get everything done.

This past Wednesday was much different. Everyone was very relaxed. There was only one item on the board that was still being tested. We were all working on getting stuff ready for the next iteration. And oh by the way, one of the QA testers was out on vacation and another one had been moved to another project.

I immediately thought back to that chaotic Wednesday a few months ago and thought about everything that has happened since then. We certainly had come a long way to get to the point where things were much more relaxed. So what happened?

The Three Amigos

Before development can start on a feature, we have a “three amigos” meeting where developers, business analysts, and QA people get together and decide on the acceptance criteria for the feature. This helps us all get on the same page and make sure that we know what we’re building. It also gets the QA team involved very early in the process, so when it comes time for them to manually test the feature, they already know it inside out.

Automating acceptance tests

The outcome of the three amigos meeting is acceptance criteria. Developers take these and automate them whenever possible (we use a combination of unit tests and acceptance tests using SpecFlow). The development workflow now looks something like this:

• Work with the QA team to write out the acceptance tests in SpecFlow
• Develop all of the components needed to make the feature work, writing unit tests along the way
• Try and get the acceptance tests to pass, fixing any problems we find along the way

When I’m working on the “try and get the acceptance tests to pass” phase, I’m going to find pretty much all of the coding errors that we made during development. The development ticket is still marked as “In Development” at this point, which is very important. We all take quality seriously, both QA testers and developers. I’m not going to hand it over to be tested by the QA team until I can get all of the acceptance tests to pass.

Almost no bugs

Because we knew what we were building up front and because we automated pretty much all of the testing, the QA team is finding very few bugs in the new features that we’re developing. One of our testers brought this up in our retrospective this past week and mentioned how they got everything tested so much faster because they weren’t finding bugs, writing up bugs, waiting for bugs to be fixed, and retesting bug fixes.

We had looked at the schedule earlier in the week and we had thought that developers might have to help out with testing because one of the testers was on vacation and they had some items to test that we thought would take a long time. In the end, no developers had to help with testing and testing got done ahead of schedule!

Everyone talks about how bugs are a waste of time, how they slow you down, etc., but it was really cool to see it play out. Yeah, getting those acceptance tests to pass takes a little extra time, but now I can hand a completed feature over to QA and have a good chance of not having any bugs. We had two developers working for a week on the feature that we completed, and we did it with no bugs. Not only that, we have automated acceptance tests that will do our regression testing for us.

Recap

A lot of the changes that we’ve made seem to be relatively minor, but they’ve produced huge dividends. Much of it comes down to discipline, not cutting corners, communicating effectively, and taking pride in your work. I’m really excited about what we’re going to be able to do from here and I expect to have even more stories to tell in the near future.

I’m a huge fan of TDD, and one thing that is really frustrating is when I’m working with people who either don’t know how to write unit tests or don’t agree with the idea of writing unit tests. This is especially true in a static language because those people will design the code in a way that prevents me from writing tests.

Why is it that so many developers don’t care about testing? Most developers that I’ve worked with, whether I agree with their ideas or not, take pride in their work and generally care about their job.

I think that this goes back to the traditional divide between development teams and QA teams. On most teams, there is always pressure to get things done faster. In order to get things done faster, you have to either cut something out or get better at what you do. It’s much easier to cut something out, so inevitably the team will do what they can to cut development time. This means cutting out unit testing (or not taking the time to do it in the first place). Once you cut out unit testing, the next thing you throw out is good design principles and just get it done as fast as possible.

We all know that if you don’t write unit tests and you just throw in spaghetti code to get something done that you’re going to have a lot more bugs. It takes time for QA people to find bugs, reproduce bugs, write up bugs, and retest bugs. But why should the development team care? They were just told to go faster. Who cares how long it takes the QA team to test the application? Why does the development team care if it takes an inordinate amount of time to regression test the application?

The QA team knows what is going on, so they don’t trust the developers. They know that the developers are likely to write bugs, so they will need to be more thorough. The problem is that sometimes this means doing an inordinate amount of manual testing (which may or may not be possible).

This is what happens when development and QA are separate teams that don’t work closely together. Each one is only looking out for their own interests, not the interest of the project as a whole. In my opinion, it makes no sense to do it this way, but this how it’s done in many companies.

On my current project, we have broken down the walls. The QA team and the development team report to the same manager. The developers, BAs, and QAs sit together in the same area. Before we work on a feature, we all sit down together and decide what will be tested with unit tests, what will be tested with automated acceptance tests, and what will be manually tested. Because we’re all on the same team, I (as a developer) care about testing just as much as anyone else on the team. There’s no reason for me to not care about testing. Don’t I want the app to work too? If I write crappy code, it’s going to take longer for the team to get things done. If I don’t help automate regression testing, it’s going to take the team longer to manually test everything. I don’t want either of these, so I’m going to help out. The QA team is starting to realize that they can trust our automated tests (which they’re not used to), and we all agree that in the future they will do much less manual testing.

Because we’re on the same team, we’ve enabled developers to care about testing. If we want to get things done faster, I want to make sure that I automate as many tests as possible so that QA doesn’t have to manually test them. I might even pitch in to help with manual testing when that time comes. In the end, we end up with high quality software delivered in less time because we have very few bugs and we will test things in the most efficient way possible.

In most companies, there is a definite divide between the development team and the QA team. They don’t sit together in the same area, they don’t have the same boss, and they often aren’t even working on the same project at the same time. Sometimes the QA team doesn’t get involved until it’s time for the “testing phase.”

To me, this all makes no sense. I’ve been on teams like this, and the same thing usually happens — developers develop something, and when the QA team starts to look at it, they don’t know the first thing about the feature that was built. They try to come up with a test plan, but they don’t come up with all of the edge cases because they don’t know enough about the feature. Other times they come up with something that the developers hadn’t thought of, or they find bugs because the developers didn’t do anything to test their own code (even manually).

Before we go any farther we have to dispel two common misconceptions about the role of a QA team.

Some people think that your QA team is like a college professor giving you an exam. You learn about a feature from the BAs or the users, and then the QA team is there to verify that you understand everything after you’ve written the code. The QA team shouldn’t give you their test plans because then you might just write the code to make their test plans pass (heaven forbid!). That’s like your professor giving you the answers to the test, and that’s cheating. (I’m being sarcastic, of course.)

Other people think of the QA team like a group of external auditors. You don’t know when they’re testing or what they’re testing. They’re just here to catch you screwing up. They have to be extremely thorough and cover all the bases to make sure that nothing gets through, regardless of whether the development team has written any automated tests.

I would much rather work together with QA people. I would rather come up with the test plans together so that we can make sure that I automate most of their tests for them and build the right thing. I would rather have QA people involved up front so that they can help me think about how something should be tested. They also are very good are finding holes in requirements that no one else though of, which is very valuable to have up front before we right any code.

The hard part in all of this is getting people to work together who typically don’t work together. Usually developers and QA have different managers, and developers and QA people might not even be working on the same projects at the same time. You might need to get your management to work together to get people on the same teams working on the same projects at the same time.

We’ve been doing all of this on our current project and we’re really starting to see some exciting things. Much more on this to come!