If you are a functional test automation expert then times are good. There’s big bucks to be made in the contracting game, companies are desperate for candidates to ‘automate everything’ and to get to this oddly perceived test automation nirvana that those who are either mis-informed or have hidden agenda’s seem to feel fit to promote.
This has made me think. Primarily about how we have got to this state? Is it because, as the testing community, we have wanted to own test automation? Is it because those outside of the test community see test automation as less important than the production code that it tests? Is it that we just built up an expertise and then protected it just for the money?
Some might say that what has actually happened is that we now have a situation where second rate developers now have a great way to stay in the development game. There is a danger, in the apparent supply-side crisis that we find the industry in, that companies merely employ anyone who says they know something about test automation, without doing the same due diligence that one would do for a development position. This would be a mistake.
In my mind there is a solution to all these problems, and that solution comes from treating test automation just like production code. And that means primarily using developers to write it. Sure, you may choose to have testers involved as well, where they have the skills and expertise, but let’s not try and force skills on people who don’t want them, and let’s not accept second rate people just because they can ‘do some test automation’. One advantage to using developers is that test automation becomes a team thing, and you are less likely to spend time playing catch-up when development slips. One downside; it’s going to look like the team has slowed down. Believe me, it hasn’t. It’s just got more effective, and is playing to the right skill-sets.
Don’t believe me? 🙂 Here’s a couple more examples from Rob Lambert and Amy Phillips which show where continuous or more frequent delivery has been successfully rolled out at New Voice Media and Songkick. The common thread – in both cases the test automation is a development activity.
Nice post Stephen.
I mostly agree with what you have suggested and would like to share my thoughts on the questions you have raised.
Is it because, as the testing community, we have wanted to own test automation?
I have seen that in past. Many test organisation gets attached to their automation code and become ‘owner’ of automated suites. Like you mentioned, teams where I have seen automation adding tremendous value is where automation is owned by team. IME, when automation is owned by either test or dev team – benefits of automation are not fully realised. Whenever it is owned by everyone in the team, it adds value.
Is it because those outside of the test community see test automation as less important than the production code that it tests?
Umm.. Most of the developers I know see test automation as an important and integral part of development. However, they do not necessarily think test automation code should be as good as production code. I have seen many good developers writing bad automation code. In my opinion, problem of automation is different from problem of development in many ways. IME, Testers who can understand these differences, guide devs in automation and ensure that they are not cutting the corner in their automation efforts can get maximum value out of their automation efforts.
Is it that we just built up an expertise and then protected it just for the money?
In my opinion, when we make ourselves dispensable (By automation, training, mentoring) – we move up and face new challenges. When we make ourselves indispensable, we get stuck and lose opportunity to learn and grow. So probably there are people out there who practice Mortgage Driven Development, but I am not sure how much they enjoy whatever they are doing.
And I completely agree that there is no point in using second rate developers or testers without right skills for automation –
Hi Anand,
Thanks for commenting and sharing your thoughts.
Steve
I sort of agree and disagree with you. 🙂 Second rate developers have become a menace and to my surprise they seem to be in abundance. That said, I think developers testing their own code isn’t going to fix the core issue- i.e Buggy Software!The disadvantage with developers writing tests is that they stop thinking out of the box when it comes to testing! A second rate developer can never be a first rate tester – because his/her code would be immaculate to begin with otherwise, right? The mind of a tester on the other hand is free to think of all of these out the box use cases- and how lovely it would be we could automate this mind? 🙂 so all I’m saying is having testers with coding skills so we can tap into their beautiful mind is a big plus! That said, I think developers need to change their perspective on testing and quality in general and really start thinking more like testers do and not just code like it is a process! It is a challenge I face everyday because I don’t have a QA TEAM , so what’s the alternative unit testing & automated testing , you say? We do both so the onus of testing is on the developer and ultimately the customer- it is not an ideal situation, but that hasn’t improved our bug situation – if anything it has made it worse! I would be interested to hear you thoughts… 🙂
Hi Aditi,
Thanks for commenting. I agree with a lot you’ve said. One potential solution, which I’ve used in the past, is to have the testers spec the test scenarios and then dev’s code them. This works well with a BDD tool like Cucumber for example. The downside is that writing test code for tests that someone else spec’d is not interesting work.
My currently solution is to make sure that test automation is not the only testing done before, or immediately after, release. By combining test automation with a good exploratory testing strategy then you can take advantage of testers minds, and developers coding skills.
Steve
One way we’ve got to this state is by referring to ” automated testing”. Testing, a human activity (cf. your earlier post, http://www.developsense.com/blog/2012/09/premises-of-rapid-software-testing-part-1/, http://www.satisfice.com/blog/archives/856) cannot be automated any more that programming or development can be automated.
—Michael B.
I totally agree. The term (automated) checking makes so much more sense. Thanks for the comments.