After being in the software industry for more than 9 years now I've pretty much done a little bit of everything. I was an intern that did testing in order to learn how to code, I was a software developer in a small firm and I did everything from the ground up, including database development, and now I am a QA engineer at Betfair. In my current role I am involved in functional testing with an emphasis on automation, continuous delivery and performance testing.
When I started thinking about studying software development I never imagined what my path would be. But all the things that I've done have helped me become good at what I do now.
The questions from the title might seem familiar to most of you and some of you might even have strong opinions about what the answers to those questions are. There have been numerous occasions in recent years when there have been discussions about whose responsibility is to test and whose is to code and what a developer has to do and what a tester has to do. While doing research for this article I've seen every opinion out there, and, while I agree with some, this article represents my view on this very complex developer-tester relationship, from the perspective of having filled both shoes.
Long gone are the days when a developer blindly pushed code to the source control without caring what happens after. Or at least they should be. The code we write needs to compile, build, be deployed and somewhat function before being tested. And how can a developer be certain that his code does all of the above without testing it? No matter if we talk about functional testing on your machine, or writing unit tests, some testing effort needs to be put in it by a developer. Understanding and seeing how the code behaves after you have written it, or how it integrates into the bigger picture makes for a better developer. Whenever you are in doubt if you should be testing, ask yourself this "Am I comfortable in deploying the software in production without it being tested by the QA and take full responsibility for any defects?"
Developers are not supposed to be able to test in the same way testers do. However, this doesn't mean they aren't able to help in testing, and in some specific areas they will do it even better than testers.
If you are asking yourself how much testing developers should do, well, the answer to this somewhat depends on the context. From my experience, the following list is what a developer should do in terms of testing before handing a piece of code off to the QA
Also, as I am sure most of you know, the earlier a bug or issue is discovered, the cheaper it is to fix and ultimately, the better the end product is.
I think everyone in the software industry has heard about the word "automation" at least one time. And at least some of the people that are reading this article have or are doing automation. Also, there might be some of you who have not ever attempted to write automated tests or do not want to. It's perfectly fine not to want to code, but you should at least learn how to code.
We are no different than developers when it comes to writing code. Or at least we shouldn't be.
I like to think of automation testing as developing, just with a different set of requirements. If the developer's requirement is to write code to implement a certain functionality, a tester's requirement is to write code to test the code that implements a certain functionality. Sometimes, the first part is harder, other times the last one is. In an ideal world, for every developer working on a project/code with a focus on functionality there is an opposite developer (automation tester) that focuses on breaking the code (thus making it better).
In my experience, knowing how to code makes you a better tester. First of all, it adds value to the overall product by being able to run the same tests over and over again after the first automation effort is done. Secondly, it gives you a better understanding on how the implementation works and you can find new ways to break it. Last but not least, it frees you to do more exploratory testing instead of spending time redoing the same scenarios over and over again
Skilled testing and learning code do not exclude each other. By learning how to code, you gain a deeper knowledge of architecture, limitations and strengths a programming language has and implementation choices developers make. All these things can affect the testing effort.
Obviously, given my experience, it might be easier said than done but I am a firm believer that automation and testers who code are the future of this industry. And without going even further, here are a few things that should be automated by the testers
This might not seem much, but once you get it started the rest will fall into place.
So, does it seem that the roles are merging? Yes and No. In my opinion, the role of a developer and the one of a tester are still separate roles and each have their own area of expertise. But with the expansion of cross functional teams and the need for faster iterations we all have to learn from each other in order to have the best product. We should always have the bigger picture in mind, the product, the customers and when all else fails, don't forget to talk to each other.
by Peter Lawrey
by Răzvan Costa
