Why shouldn't Developers do testing?
This is a discussion I have quite frequently with my boss when we are having problems with resourcing in the test space and his answer is ‘let the developers do some testing - just one morning a week’. My answer of course is always in the negative. But is that the right answer? Is it in fact the right question?
When I first started as a programmer we did everything, but then one day I woke up and found that as a BA I was doing a lot of the testing for other people and next thing I was working as a Test Analyst. The world seemed to be saying, we need a different person to test code from the person who wrote it. But why? Is it because somebody decided we need to create more jobs or was it because each of us has our own ways of looking at the things and with the introduction of the tester we were going to get better quality code. Does this answer the question?
It still doesn’t really but what that tells me is that change is inevitable, however it may not always be for the best. We must find the path that will best suit our environment and the people we choose to employ in it. There are a lot of ‘new’ professed Testing and QA methodologies and process and just recently there has been a lot of talk about Shift Left Testing and people keep mentioning it to me saying this is what we should be doing. But does that mean let the developers do more of the testing or is it that we want to do the testing earlier and more effectively in the SDLC. Aren’t we doing that already?
With the advent of change, in particular in the way we work, that is now happening faster and faster those of us working in the test arena are keeping up with these changes, however our core task hasn’t changed nor ever will change. We are here as part of any type of team working in any type of way and our task is to support, challenge and ensure that right from the beginning that requirements, specifications and code do not go out the door without being ‘Tested’ (of course that raises another question - What does Tested mean? - topic for another time I think).
I know I haven’t actually answered the question I asked, however I believe we all need to start thinking about the fact that we all have a huge part to play when changes happen. Traditional thinking and ways of working are changing, however don’t discount what still works and don’t ignore the new when it will enhance the path we are on.
We need to challenge and accept traditional thinking as well as the new.
Scott Lord
Many reasons. First: Developers should not do testing because we love hand-offs. Waterfall taught us the value of them. Second: because we don't value personal responsibility. Lets make it somebody else's problem to find errors and still somebody else's problems to fix them. Third, we don't trust developers (the lazy no-gooders that they are). We insist on separation of duties which improves the number of hand-offs in the system and also enhances functional specialisation. Fourth, we don't like it when the person who found the issue can also fix the issue. No good for defect reporting. Defect reporting makes some activities look super useful and productive. Fifth, we certainly don't want developers to gain any kind of systems knowledge. Lets keep them in the dark on this and ensure that only the testing team knows how to configure environments. From a management point of view when one team is responsible for finding issues and 'ensuring quality' in another team's work it enhances the good-natured co-operation of the leadership team. After all, everyone likes to blame the development team, thank the quality team and berate the delivery leads for not being able to estimate dates and cost. Great fun. Out of characte
If the developers aren't already doing some testing (unit, low-level integration at least) I'd be concerned, but I assume you're referring to higher-level testing? Getting them to do higher level-testing tends to see mixed results in my experience. I reckon developer brains and tester brains aren't wired the same - finding a good tester that's also a good developer (and vice versa) is extremely rare, so yes, you could throw some warm dev bodies at the testing effort, but your mileage will vary massively, and you might end up just wasting time working with poor results. I'll ask the classic consulting question at this point - what problem are you trying to solve by making developers test? Is it that there aren't enough testing resource? Is it because the developers don't appreciate the ins and outs of the system they are working on? It is because too many bugs are being found? Is it something else? For each of those, there's definitely better solutions than getting the developers to test, but sometimes we are constrained by circumstances. Personally I'd rather have my developers spend their time improving the quality of the code they're delivering to the testing team in the first place, as this helps to reduce overall effort spent and allows focus on polish.