Bloggo back to the blog
Why every system test department should have a test developer (… or two)-->
Some of the best testers out there that I know, for example Michael Bolton (@michaelbolton), is not developers.
That being said we really need divergent testing departments so we get different types of thinking when doing software testing.
What is a test developer?
In fact I classify myself as a one and there are occasions when I encounter people who do not know exactly what a test developer is.
When I present myself as that I mean that I´m a developer who absolutely loves software testing. In other words, it´s someone who is really good at developing software, knows all the secrets of the trade (writing maintainable code, test driven development, adhering to the Software Craftmanship manifesto etc.), but on who also loves to use it for testing purposes.
One problem for system test departments is that they typically are composed of only testers and as any good test manager knows you want to keep your department mixed in terms of age, background, skills etc.
Favors which the developer in turn has to weigh against their everyday work and project assignments.
Recruit your own
The solution to this problem is recruiting your own staff with development skills.
If you have the option to recruit for a new position or fill an existing position within your system tests department then you can actually go for the option of recruiting a test developer the next time.
Preferably you would actually like to have two test developers at least and I´ll cover a bit later on why.
What are the benefits?
But there is also the benefit of being able to automate some testing so that your test engineers can focus on “higher value testing”.
What I mean by that is that your test engineers shouldn’t´t waste their time running the same manual scripted regression tests over and over again every time a new release is done.
What they should be focusing on is the speciality of their trade, like exploratory testing, risk analysis, things that only a human brain can do good.
There is, as most of you know, a huge difference between verifying and actual testing.
Also liberating the testers to enable them to communicate with the end-users in agile testing spirit is also something we want to strive towards.
Lisa Crispin (@lisacrispin) and Janet Gregory (@janetgregoryca) points out in their book “Agile testing” that a new role for the tester in an agile organisation is to actually be the bridge between developers and the customers.
But they can only do this if they are liberated from repetitious tasks that bring no or very little new information.
So apart from understanding more of what value the customers are expecting we also get the benefit of having a link between the testers and the developers, in other words we have someone who can talk the talk of both sides.
Also when we want to do some of the non-functional testing activities like performance, reliability and stability testing, then automation is most of the times required in order to do it well, and some times there is the need to custom build the tools we use and integrate it with our product.
Other benefits we might reap from this is having someone on the team who can help with debugging and reproducing complicated bugs that might be very hard to reproduce and report and dig out that extra data from the system that will help the developers in their work.
All in all helping your test department run even a bit more smoothly and efficiently.
Are there no drawbacks to this?
The first one and perhaps the most obvious is that we will loose “manual test time”.
The test developers won´t be able to do as much and good testing as a dedicated test engineer can.
Another reason for letting them test is to avoid a problem I will describe shortly, and that is creating a isolated team within the team, in other words we want the test developers working and communicating closely with the testers.
Another thing to keep in mind is that developers in general are creative people, and you want to use that quality and let them come up with new solutions and tools for the test department.
On the other hand as any software manager knows this can easily get out of hand and engineers have a tendency to work on interesting problems that might not be the most needed right now.
Pay close attention to this and give them the freedom to work as they see fit but also create clear and concise goals for them so that both you and they know the right things is being delivered.
But never tell them how they should deliver it, just what and when you want it.
Encourage them to follow agile principles like for example scrum and XP.
Another danger I mentioned briefly earlier is that if you have several test developers, then one immediate thought is to create a separate team for them.
There is a high risk of introducing a isolated team within your department.
If you are not careful you might end up with a test developer team that sees itself as separate entity apart from the test department, and also a department that looks sceptically at the test developers since “they don´t know how to test properly anyway”.
Now splitting the test developers and placing them within the test teams might solve that problem, but you probably will miss out on nice effects when developers get together, work together and spread ideas together.
So one way around this is to have a dedicated amount of time at regular intervals when the test developers have to go out and work as a team member in you test teams.
This will of course make people get to know each other, increase the communication and most importantly your test developers will feel the every day pain of you testers and what they really need.
“A good developer is a lazy developer.”
I also mentioned it is a good idea to employ two test developers and the reason for this is that a person needs to have a peer to bounce ideas with, be inspired by, or simply just knowing someone else is looking at your code.
If you don´t then the chances are that after a while that person won´t be challenged enough and will start to loose his or her edge.
Where are they then?
Where do I find these test developers to recruit?
To be honest I have never, with the few exceptions of people like Markus Gärtner (@mgaertne) and Julian Harty (@julianharty), ran into that many test developers.
There are testers out there who do scripting in languages like perl, python etc. But what I´m talking about is developers who have a real passion for testing.
Also there is a significant risk of recruiting a developer who´s long-term goal is to do “real” development and only see your department as a way into the development organisation.
If you manage to find a test developer then that’s a good start, odds are though that you might have to take another approach and end up with a test developer in the end.
As I mentioned we want the development skills in the person so your options are to either take a tester internally that really wants to pick up development skills and grow from there, or go the other way around and find a developer that you can get interested in software testing.
If it´s a tester make sure you really invest the time so that he or she picks up sound development skills from other developers, send the tester to a development course, but more importantly make sure they hang out with other developers and that they have interesting projects to work on, send them on “internship” to other development teams for a while, take in other developers from the organization to do code reviews etc.
If you have a developer that you want to learn testing, make sure that person really gets what testing is, why we need the human brain and critical thinking in software testing.
Send the developer to test conferences, make them do testing with the test teams and help them find interesting resources online like blogs, twitter, testing dojos etc.
Mae them respect the trade of software testing.
Kristoffer Nordström is a test developer who has been working in the mobile and telecommunications industry since 2005.His background covers development of test automation frameworks, automated GUI testing, non-functional testing, and he has also worked as a scrum master and developer.Kristoffer works for the swedish company Softhouse Consulting, a company which specializes in agile development and methodologies.