The recent web rantings over the “developer/tester” combined role have given me many laughs. The concept is typical of tight-assed project budgetting – and absolutely nothing to do with efficiency. And although it is likely a tester would be prepared to learn development, I seriously doubt whether many developers would be prepared to learn to test. As so many seem to struggle with keeping up basic unit testing.
But there is a combination that is very worthwhile, the business analyst/developer. This is a lot more logical combination, as an anlalyst maintains a high-level view of requirements, and therefore more conscious of those when coding. Role combining is generally not recommended, but as the business analysts seemed to be omitted these days, or subsumed in other roles, it seems a good time to redefine their place in Agile world (there’s room for everyone!).
My venture back into corporations has re-introduced to these generally canny and thorough individuals. Marry business analysis with coding skills, and you have an effective all-in-one BDD (Behavior-driven Development) resource. I am not suggesting existing business analysts make the switch, but we do need a new breed of developer whose skills extend beyond following unit-test level of thinking. Part of the problem when you code, is that your mind is in a different place – a place full of variables, clauses, conditions, mathematics. And because a developer is not so focussed on requirements (only resulting component tasks), their view and implementation can be skewed. If you take any small part of a requirement, it can be taken out of context. You could argue that is down to the quality of requirements, but that’s an easy cop-out. If the developer kept the overall requirement in mind, whilst coding the smaller tasks, then the context would remain correct.
These recent calls for combos, especially the developer/tester combination is more of a call for better technical skills for project members. And that is no bad idea – testers in the “olden days” were not expected to have those kind of skills, and were actively discouraged for involving themselves in technical decisions or development meetings. You could argue that 15-20 years ago, coding was not as accessible as it is now – there are now many helpful programming IDE’s and a good selection of test automation tools geared for any level of technical expertise. 15-20 years ago, automated testing was in the realms of heavyweight applications such as Mercury Interactive (swallowed up subsequently by HP) and Segue. Encouraging testers to be more technical and to have development skills is sensible, given the evolution of development. But it’s important not to confuse the issue by trying to shoehorn one role into another. In fact, along the the “testing is dead” mantra, I wish everyone would just shut up with their negative catchphrases, and take more positive approach. I will tell you what is dead – “devil’s advocate” phrases, purely said in interest of self-promotion.
Related posts:
