So now that we have built our automation framework, and got our smoke tests running as part of the build, we now need to make sure new BATs are being created for new backlogs.
This is definitely one of the more challenging tasks you will face, and perhaps the most critical.
All of your efforts will be in vain if you can’t get to the point of creating new BATs for new backlogs that are finished, because if you don’t you’ll still be doing manual testing, and you’ll be playing catch-up all the time.
Start off small
The goal here is to eventually get to the point where every single backlog requires BATs to be written and passing in order for that backlog to be called “done.”
If you try to drop this lofty goal onto a team in one iteration, you are likely to get beaten and slapped with much vigor.
Instead, start with a simple goal of requiring that at least one backlog have BATs for all of the functionality of that backlog. Start with this small goal, but enforce it with rigor.
By starting out small like this, you will get the team accustomed to the idea of building automated tests at the same time as building the functionality and you will give them a chance to have a small success without sacrificing much velocity.
The goal at this point should be to get people excited about writing BATs along with the backlog.
It’s actually quite fun
I have found that developers tend to really enjoy writing automated tests. Make sure you let everyone who wants to share in the fun, not just QA and not just developers.
It is really very exciting to see the “magic” of an automated test clicking through buttons on your web page and doing all kinds of things that seemed so tedious before.
I have found that this is so much fun, that you might have the problem of developers not wanting to work on the real backlog, but rather to write the automated tests for it.
This is good, you really want to foster this attitude, it will greatly help when you finally…
Drop the bomb!
What bomb? The bomb that says on it:
All backlogs will require BATs as acceptance criteria. It’s not done unless it has automated tests that prove its functionality.
You should be getting to this point within 3 to 4 iterations on average. Don’t go too fast to get here, but don’t go too slowly either.
I know this seems like an impossible task, but it really isn’t. I’ve been here before and had much success with it on several different teams. The key is making sure everyone is comfortable with writing automated tests and understands the value.
Whatever you do though, once you draw this line in the sand, Do not back down! I mean it.
You might start getting death threats. People might directly laugh in your face all the while spitting skittle colored loogies in your coffee, daring you to “taste the rainbow,” but you have to hold your ground.
It will be worth it in the long run, because you will have built an awesome safety net for proving the functionality of your software over time.
It’s not all rainbows and butterflies
You are going to sometimes run into scenarios where automation will be too high of a price for a particular backlog.
This will especially happen in cases where you have some kind of process that spans multiple domains or software systems.
When you run into those situations, give it a solid effort to at least automate as much as possible, but don’t die on the hill and kill the whole automation project. We have to be pragmatic or risk having our credibility called into question.
Don’t expect everyone to embrace writing BATs overnight, or to even be good at it. When you first introduce this to the team, you are going to have a learning curve and your automation framework is still going to have some pretty big holes in it.
But, that is OK. Over time you will build out that framework and produce some fierce battled scarred veterans able to automate web pages while scowling at you from afar, just don't lose hope and keep beating that drum!