My system 1 thinking says “no”. I’ve often heard separation of duties makes testers valuable.
Let’s explore this.
A programmer and a tester are both working on a feature requiring a complex data pull. The tester knows SQL and the business data better than the programmer.
If Testers Write Source Code:
The tester writes the query and hands it to the programmer. Two weeks later, as part of the “testing phase”, the tester tests the query (they wrote themselves) and finds 0 bugs. Is anything dysfunctional about that?
If Testers do NOT Write Source Code:
The programmer struggles but manages to cobble some SQL together. In parallel, the tester writes their own SQL and puts it in an automated check. During the “testing phase”, the tester compares the results of their SQL with that of the programmer’s and finds 10 bugs. Is anything dysfunctional about that?
RSS
Easy to answer if you drop the 'tester' and 'developer ' labels...
I've written production code, and even fixed problems from my own bug reports, particularly earlier in my career. With a b2b web-based app in the late '90s, I even added in a new feature I thought was missing. The dev manager agreed, but couldn't spare programmer time, so told me that if I thought it was such a great idea, to code it myself. It ended up improving the product usability hugely.
I've always seen my testing work as helping to create, so as long as I can get someone else to help test stuff I coded, I don't really care about who does what, as long as we do it well.
I think both ways are feasible, however I find dysfunctions in both ways.
First scenario: It is not reliable that there are 0 bugs found by the tester, it means that if the tester writes code, he is not the ideally indicated to test it.
Second scenario: Testing it is only working around automated testing which means that the added quality of the final result would be the same such as he had written the code.
I think there is not one only answer to this question and it totally depends on the scenario you are asking, in this particular scenario i would choose to write the code, and later try to test it as if some one else had written it because i find natural the idea of focusing and thinking in less scenarios while you are coding than while you are testing.
My thinking tells me that "Tester" and "Programmer" should cooperate and create good SQL first, to not waste time during "testing phase". Reduce time for roundtrip, make it correct from the beginning.
Why not make "programmer" test the query? We are the one team, eventually.
Phil, I think you meant "...drop the 'tester' and 'programmer' labels..." (I think testers and programmers are both "developers" working on a development team).
Anyway, let's see what happens:
Two developers are both working on a feature requiring a complex data pull. DeveloperA knows SQL and the business data better than DeveloperB.
Scenario 1:
DeveloperA writes the query and hands it to DeveloperB. Two weeks later, as part of the “testing phase”, DeveloperA tests the query (they wrote themselves) and finds 0 bugs. Is anything dysfunctional about that?
Scenario 2:
DeveloperB struggles but manages to cobble some SQL together. In parallel, DeveloperA writes their own SQL and puts it in an automated check. During the “testing phase”, DeveloperA compares the results of their SQL with that of DeveloperB and finds 10 bugs. Is anything dysfunctional about that?
...Both are still dysfunctional to me.
Jonathan, thanks for the post. I agree that it's okay for testers to write source code. I see some non-congruence between my blog post title and my two scenarios. I was more interested in exploring the dysfunctions.
So, in your tester-writes-source-code experience, who tested your source code?
Did someone estimate for your tester to perform this work?
Is performing this task preventing your tester from executing their current assignments?
Does your tester have access to your development environment?
If your developer doesn't have the ability to perform his/her tasks, is having your tester perform their job masking poor performance?
Is an auditor going to ask why someone with a tester role has access to non-test environments or is testing their own code?
I've had success in the past using parallel development as a valid testing model. I don't see how this is any different. It's not a new concept.
Eric - the developer tested my code, as did a subject matter expert (or we'd say product owner now) from the business. I did my best, but I could only do so much since a lot of my energy had been expended in design and coding.
We were all called "developers" even though I did mostly testing work. I see the dysfunction you are pointing out, but in my opinion it is easily solved with some skilled people who are open minded about trying their best to create something great for their user community.
I agree with Miguel, there is something dysfunctional in both scenarios.
In Scenario 1, the tester has become the programmer and thus should not test his/her own code.
In Scenario 2, time is wasted by letting the programmer write the query, knowing he/she will struggle doing so. Due to the struggling, it is reasonable to expect the query will result in bugs that could have otherwise been avoided had the tester wrote the query. The time spent on resolving these avoidable bugs could have been spent trying to find the bugs neither the programmer or tester expected to find.
Ron, nicely said. Those are essentially the dysfunctions I saw too.
Unknown, I like your advice. And it shares something similar to what others have said:
- don't hold back talent for later
- don't test your own stuff
I'm still struggling with "don't test your own stuff". In this case, I'm not sure one can perform a valuable test without having the stronger skills in the first place.
Not to be overly pedantic, but I think the 'don't test your own code' rhetoric is sorta bullshit. I suspect it promotes laziness and encourages people to chuck stuff over the wall upon finishing the code.
Don't be the *only* one to test your own code - sure. Having someone else examine your work is a great way to help you with your own blind spots, weaknesses and biases. Don't *test* your own stuff? Yeah not drinking that kool ade.
Of course you could get even more pedantic if you wanted to talk definitions of debugging vs testing vs tdd vs checking and so forth, but I'm not going to open that bag of worms :)
I strongly agree with other comments, especially:
Unknown: Cooperate efficiently as a team, no "role" and no "phase".
Ben: "Don't be the *only* one to test your own code".
Although I read somewhere something like: "You can only properly test your code after a week without touching it and 2 ounces of liquors", which I experienced and it's true!
Programming and Testing are two different fields and that's why these are divided into two seperate parts. Tester can write source code too but not necessarily it is required that he have to write the code.
360logica
So I have issues with the scenario you've outlined... it doesn't make sense in any place I've worked.
Tester writing source code... that's vague. I write code all the time, for test harnesses. I'm either writing in Groovy or Ruby. Are you referring to code going to production?
Developer cobbling some SQL together... that very statement shows a resentment to the skill level of a dev. If a dev can't write sql... what's he doing there?
The real answer is, no matter who's doing the code, it should be code reviewed. This will catch most of the issues from this example.
As for who's testing it? I guess that's open for debate. If I wrote some test code going to prod, I wouldn't test it. Another tester would, to keep me honest.
your scenario sounds like a weird place to work, where there's only one tester and a dev who can't write sql.
Brian, thanks for the comments!
To clarify, when I spoke of source code, I meant 'product source code' not test source code.
You're right, "Developer cobbling some SQL together" does make it sound like the developer is unskilled. That is not what I meant to say.
I think if we have the best SQL syntax writer in the world, they still may be inferior to someone with rudimentary SQL skills who is an expert in the business domain.
Thus, writing good product source code is not as simple as just being a skilled programmer. A tester with excellent business knowledge and adequate coding knowledge may emerge as superior in certain places.
I believe Testers can write source code if it is really required by the team, but the testing should be done by someone else.
Also in the age of Agile Projects, we encourage people to take up different roles in the project, so eventually testers are also writing code these days.
Regards
Rajaraman R
Test Data Management Blog