If you’ve been following along on my posts here, you’ll know a few things about my opinions. First, I think that software developers can be excellent testers. Second, I think developers are far more suited to write test automation than anyone else on the team.
However – I’m willing to recognize that a lot of you may not live in the same world of software development as I do. While I strongly believe that developers owning the vast majority of the testing is a more efficient way to deliver customer value, I recognize that for many of you, that’s just not your current reality. So let’s start with what you can do, no matter what your current circumstances are.
The Big Question
A question I’ve heard a hundred times in my years of talking and writing about testing is, “how do I learn test automation?”. According to my brief internet searches, this question remains highly popular today with no sign of fading. To be clear, I don’t think this is the right question to ask. Instead, I’d like to see questions like, “how do I provide more value to my team?”, or even, “how can I future-proof my career? – but I fully believe that the people asking the questions are sincere.
The problem is, that the answers suck. Whether it’s pointers to blogs, articles, or videos, the answers are inevitably to automate some user actions on a website or desktop UI. While those are indeed things that one could automate, they’re most often not a prime example for automation (I wrote about this a bit in Something’s Rotten in Test Automation). It’s no doubt that many people have learned automation this way – but to me, it’s wrong.
My worry is that if you’re trying to figure out which tests to automate or not, your real problem is understanding how to design automated tests. Some tests should be automated. Some tests should not be automated. The challenge of good test design is to determine the difference. There’s no blueprint for this – it highly depends on the context of your application and your customers.
The Collaborative Approach
For testers who want to learn how to use code to help solve their testing problems via automation, I think there’s a better idea for learning. If you want to learn more about automation, I suggest that your first step is to leverage your partnership with the developers you’re working with.
Yep. The same answer I give to teaching developers how to be better testers is the answer I think is right for testers who want to learn test automation. While you may be in a place where the developers you work with do little testing, in my experience, pairing with developers is the best way for each of you to increase your skills and help the organization deliver with better quality.
Let’s walk through how this could work for you. Let’s say you’ve been given a new testing assignment to test a small e-commerce website. There are three items available to purchase, and shipping is free.
A common approach for someone writing web automation would be to list test ideas and then automate them.
- Add an item to the cart
- Remove an item from the cart
- Add multiple items to the cart
- Edit the amount of items in the cart
- Checkout (purchase the items)
You could then automate these one by one, begin running them regularly, and end up with a nice little UI acceptance test suite – and probably learn quite a few things along the way.
Were these the right tests to write? Are there missing tests? Did you over-test anything?
The best way to answer these questions is to collaborate.
Let’s consider this interaction between Tom, a tester, and Diane – the developer of our website.
“Hi Diane. I’m thinking about automating some tests for our website. Do you have time to walk through how we should get started?”
Diane looked up from her monitor and turned around. She and Tom had paired before on creating some integration tests and it was an enjoyable experience for both of them. “Sure, what did you have in mind?”
Tom continued, “When adding items to the cart, a customer may request a negative number of items, zero items, more items than we have in stock, and combinations of items. Since that takes a long time by hand, I thought I’d try to write some web automation for that. I also want to try all of that in all 50 states that we sell to so I can make sure we calculate tax correctly.”
“Well…” Diane replied, “you’re right that those are things we should automate.”
“I hear a ‘but’ coming,” Tom interjected.
“It’s not a but.” Diane removed her glasses and continued talking. “Those are all obvious things we should automate, but they may not be the best place to start. None of the logic for those things is in the web code.”
Tom looked confused. “I don’t know what you mean.”
“The user interface in our web page allows you to make those choices, but a lower layer handles all the logic. I can write some tests that verify all of those things directly against that lower layer. By writing tests at that level, they can run faster, and probably be less flaky.”
Tom looked a little dejected. “So, are you telling me you’re going to automate these things? I was hoping to write some automation myself.”
“No.” Diane smiled. “We should, of course, write tests at the lowest level possible to verify functionality and find issues. That’s what I’m suggesting here. I think we’ll still need a tiny number of UI tests to make sure the end to end workflow is working. If we start with a single end to end test that adds an item to the users cart, then checks out and purchases that item that it would be valuable in making sure our site is always working. I’d enjoy helping you get started with that.”
Tom’s eyes lit up. “That sounds great.”
“Wonderful – why don’t we set up time this afternoon to walk through this together. We should talk about testing ideas together more often.”
The Missing Link
One thing that gets missed in a lot of conversations about building software quality is that good software results from good collaboration. One of my favorite quotes from Jerry Weinberg comes from his Second law of Consulting: “No matter how it looks at first, it’s always a people problem.” I’m convinced that nearly every challenge and difficulty faced by individuals and teams will disappear with better collaboration and shared goals.
When testers ask me about learning automation – or often improving software on their team, the problem isn’t a testing problem. It’s not a quality problem either. It’s a people problem rooted in a lack of communication between team members. I am utterly convinced that if people in test roles collaborate extensively with people in development roles that not only will these questions go away – but that velocity and quality will surge.
If you are a tester and you’ve read this far, I challenge you to find an opportunity to pair or collaborate with developers on your team. You don’t need to be on an all-day video call with them every day, but spend some time together solving problems. If you’re a developer, the same challenge goes to you about testers on your team. Together, you’re going to get so much more done – and the learning you get from each other will make you better when you’re flying solo.
In the end, you both will get better. Your team will get better. Together, you may learn enough that you both can create the best set of automated tests for your product.