Testing Clichés Part II – Testing should be separate from development Rikard Edgren
This is an idea you see and hear now and then. It comes in different shapes, ranging from testers needing to have an independent manager, to testers being best if physically separated from developers, or even outsourced, or crowdsourced.
Cem Kaner writes in The Ongoing Revolution in Software Testing that this notion primarily is a “fear of bias”, and he is right, as always.
The rationale for independent testing boils downs to testing not being influenced by the development. Of course the influence can sometimes be negative, but the positive influence is more common, and more important.
There are three important reasons why I wouldn’t want to work separated from development:
* More and better information (both ways)
* More ownership and motivation
* Working together with different knowledge and focus gives a holistic view, and a better end result.
But since this separation can take so many forms, there is a need for some clarifications.
* If the testing team belong to a separate group hierarchically, but in all positive ways can influence and be influenced by other groups, I see no problem with it.
* If outsourcing includes developers, testers, documenters, and maybe even product management, I see no problem.
* it is OK if parts of the test effort are performed elsewhere, in order to get different views and approaches; Beta testing is an excellent example.
* if the ambition isn’t higher than doing exactly what is specified in detailed requirements, separation might even make that easier.
* Regardless of setup, if there is a mentality of minding your own business only, I don’t think it is a good setup.
I’m not sure if it is the physical or the mental separation that undermines the ability to get involved in each other’s work, which I see as a good thing, not because of lack of trust, but because we wanna make sure that the end result is a great product.
This is a subject that has come up in the team that I work in several times (and will be back for sure).
We (as testers) feel strongly that knowing ‘everything’ will lower our level of objectiveness in our testwork. This would be the case when we would be sitting in the same room as the developers.
So we favour the situation as we have now where all testers from similar projects are sitting close to each other (same room) and the developers are nearby to obtain all information needed. Still working together with them and exchanging knowledge but some seperation as well.
Maybe the type and or size of project makes a difference in whether or not testers should sit with developers…….
Good points, all.
In the right situation, all sorts of degrees of separation between Testing and Development can work.
And in the wrong situation, all sorts of degrees of separation between Testing and Development can fail.
Experimenting with different models, understanding the potential pitfalls of each, and being honest about the outcomes, seems to have been the best approach for me.
If this was the case, wouldn’t we see a higher percentage of defects found during unit/component testing? That is developer testing. System testing is intended to be segregated. I’m not saying developers don’t make good testers, quite the opposite. Some of my best testers were solid developers. However, when the two are too closely coupled, I’ve seen complacency take over and when you know each other a little too well, documentation starts to slack because testers ‘read between the lines’.
Open communication between the two is great and to be encouraged, but I still believe it’s better to have a healthy level of separation.
As I see it, this is not a matter of what is most effective from a test perspective. I think other aspects, such as what approach is most effective in providing the fastest turn-around from fault found to problem fixed, are more interesting here. However, in the end it comes down to what you write – achieving better end results togheter.
Saam, very good point! It’s “the whole” that matters, and I have never heard someone say “developers should be separated from testing”
Chad, more defects are found during system testing because defects can not be seen (as easily) when looking at component level.
And the intention of system testing is to find out how the system works, the separation is just a means that some people came up with because they had seen, or were afraid of biased testers that don’t truly want to find errors.
But you are right that you can become too involved with the features, but I see that as a risk to mitigate by being aware of it.
But the details might not be so important, the open communication is what is needed.
Joe, I agree, and the honest experimenting might be the best, maybe by switching between tight and loose integration every second year.
Emile, I also sit in a room with testers and it works really good.
As long as testers and developers are within a minute away, you have a chance of effective communication.