The very first test automation job I had was for a company that had no QA Engineer before I was hired. I’d never done automation before, but I convinced the company that with my rudimentary knowledge of Java, I’d be able to figure it out. This was long before there were awesome online resources like Test Automation University, so it took me a long time and a lot of trial and error before I had automated tests that would run and pass. My tests were long, flaky, hard to maintain and filled with implicit waits and duplicated code, but they were my tests, and I had really enjoyed solving the problem of test automation on my own.
Then the company hired a new software developer, and our manager thought it would be a great idea for him to learn about our software by looking at my tests. Without consulting me, the new developer completely rewrote my tests. I was really annoyed, until I looked at the tests and saw that he had reorganized them using page object models and methods so that no code was duplicated. It would be so much easier to maintain the tests now! That week I learned that it’s always best to work with others rather than going it alone, because others often have skills or information that we don’t.
Software developers know this already, because they are required to collaborate with others through feature planning and code reviews. But often testers aren’t required to do this. Test automation code is just as important as production code because of the value it provides, and for that reason, we shouldn’t be lone wolves, even if we enjoy it! Here are some lone wolves that you may encounter or recognize in yourself.
The Gollum: In The Lord of the Rings, Gollum loved his ring so much he called it his “precious”. For the test automation Gollum, her automated tests are her “precious”. She’s worked long and hard at those tests and is very proud of them! Unfortunately, because she was the only one who worked on the tests, they make sense only to her. Nobody wants to help maintain the tests because they are so hard to understand. As a result, she is the only one who can fix the tests when they break, and therefore she has become the bottleneck for automated testing on her team.
How to stop being The Gollum: Share your test automation with others and get feedback on how they could be more useful and maintainable. Implement the feedback and repeat.
The Frank Sinatra: Just as the real Frank Sinatra sang about doing it “My Way”, the test automation Frank wants to do it all his way. He is convinced that he alone knows the right way to do test automation. And unsurprisingly, the right way is with his favorite tool! Every other tool falls short in his estimation, so he’s going to stick with his tool even if the rest of the company is using something different. As a result, he can’t collaborate and share ideas with testers on other teams, and his test automation never improves.
How to stop being The Frank Sinatra: Try some new test automation tools! You don’t have to love every single one, just give yourself enough time to really understand their strong points. You may be surprised at how much test tools have improved in recent years!
The Magpie: This species of bird is attracted to shiny objects. The test automation Magpie is attracted to new test automation frameworks! If it’s new, she wants to try it out, and she loves writing test automation from scratch. In her opinion, any problems with her existing automation must be problems with the framework, and the problems become an excuse to scrap the project and start over again with a new framework. This means her team never has a complete test suite that they can run and rely upon. It also means that the team has to keep up with all the framework changes, which will make them reluctant to contribute to the automation.
How to stop being The Magpie: Get input from your team about what framework would be best for your application, then stick with it. When you run into trouble, ask your team for help, or ask other test automation engineers. You don’t have to keep using the framework forever, but use it at least long enough to see it working in CI/CD.
The Hermit: The Hermit simply loves working alone. He’s very busy working on his automation all by himself, so he doesn’t want to take the time to explain what he’s doing to the rest of his team or to any other testers. He hates asking for help and sees it as a sign of weakness; he’d rather figure everything out on his own. As a result, his automation never improves, and no one at the company ever benefits from his expertise.
How to stop being The Hermit: Find a developer or test automation engineer that you admire and trust, and ask them for their opinion on your automation work. Implement some of their suggestions. Volunteer to lead a workshop on something you’re really good at. Try to help one person a week who is stuck on a thorny automation problem.
Software is a collaborative adventure! Building software is complicated. There are many facets of software quality to consider, while at the same time delivering features that will put your company ahead of its competitors. That’s why we don’t have room for lone wolves anymore. Software testers need to work together to contribute to test automation projects that deliver fast, accurate results. And software testers need to work with software developers to make sure that quality goes both ways: we need quality production code and quality test code.
Pingback: Five Blogs – 8 March 2021 – 5blogs
I feel like the Hermit, but only because my team is dwindling. Is there another lone wolf roles for the automation testers who DO have a desire to work with others, but there’s just no one else to work with?
You touched on a great topic with devs pairing up for code review and collaboration. As a tester I’m a huge proponent of knowledge and skill sharing. There’s gotta be room in this list of lone wolves for those of us only limited by our unique employment circumstances? Like one tester only having manual experience and the other having years of advanced testing experience and exposure to other frameworks and platforms.
Thanks for your questions, Queen Tester! (And awesome name, by the way!) You say there’s “no one else to work with” because your team is dwindling, but you are not the only person on your team! I’m guessing there are at least a few developers you work with. Those developers can be an awesome resource for reviewing your test automation code. They can contribute to test automation, suggest ways to organize the automation code, and create tools to make your testing easier.
When you are on a team where there are only two testers and one has a lot of automation experience and the other is a manual tester, there are a couple of different ways you can team up: if both testers are happy with their roles, they can work together to decide what should be tested and how; then the manual tester will do the manual testing while the automation engineer writes the test automation. But if the manual tester wants to develop automation skills, the more experienced tester can help them find tutorials and real-life challenges.
Finally, even if you are literally working all by yourself, you can still share your knowledge with the wider software community and exchange ideas. So there are lots of ways to keep from being a lone wolf!
I’m wondering if there’s additional variations of the lone wolf. Like those who like to write automated tests but not develop the framework, or those that like to work on the framework but not automate the actual tests. Also not sure if it relates to this post, but there may be those with a narrow minded focus on defining UI locators and test scenarios targeting the simple or happy path cases, without thinking of the bigger picture to eventually handle variations & data driven tests, and corner cases where most bugs tend to surface.
Yes, David, those could be variations! Any time a tester doesn’t want to have their tests evaluated, commented on, or changed, it could be because they are a lone wolf. And there are definitely testers out there who just want to run through test plans that someone else makes (or to make happy path automation) without thinking about what to test; but those are more likely to be lazy testers than lone wolves.
Pingback: Software Tester or Lazy Developer? – Think Like a Tester