In a recent contract engagement a happy accident happened to me. As a test lead in a Big Data shop, I was tasked with transforming the practises of the data engineering team to a more classical AGILE approach, using the sort of techniques (TDD/BDD, paired programming and so on) that have been common to application teams now for many years.
It is fair to say that the data world lags here a bit: perhaps it was inevitable that in the early stages of the Gartner hype cycle it would commit all the mistakes of the DotCom boomtown years all over again, but anyway it certainly seems to have done so when it comes to the testing the quality of its product.
Anyway, the team was expanding and the QA function was at last being taken seriously, so I was tasked with finding big data testers to work under me. We interviewed and interviewed, but no one really seemed to fit the bill.
Luckily for me, data engineering was also expanding but there was a short hiatus between new projects coming on stream, and one hapless individual joined the team just when there was no work for him to do. It was decided that in the interim he should help me write integration tests across the data pipeline.
I doubt he was very happy about it, but he showed great character and knuckled down to his task. Having already created the automation framework, I taught him how to write integration tests.
As anyone who has been involved in AGILE transformation will tell you, teaching most developers to adopt test driven practises is hard. Obviously when it comes to modern automated testing the coding perspective is water off a duck's back to them, but developing the tester's mentality very rarely comes naturally. Development is a creative exercise whereas testing is a sceptical, defensive one. Having closely observed the sociology of AGILE teams over the years I have found that developers and testers tend to have very different underlying personality types.
Anyway, back to our little experiment. It ended well: after a couple of months the data engineer was writing very comprehensive tests of data transformations across the data pipeline. Naturally he wanted to go back to engineering work, but he was now a test driven developer through and through. As a QA, I was sorry to lose him, but I also knew that he was one developer whose work I wouldn't have to worry about.
It struck me then, why wasn't this happy accident standard practise? Why not hire developers and make them work as testers for the first 1-2 months of their engagement?
To me, it would seem to have the following huge advantages:
- It makes them better developers.
- It will help bring developers to a uniform standard of TDD maturity within the team. When they come on board developers naturally have variable levels of AGILE maturity and even the best are usually not as AGILE as they like to think they are when it comes to writing tests.
- It gets them into an AGILE way of working right off the bat. Transforming people's ways of working is much harder once people have gotten into a routine and personal relationships have been formed.
- It helps form relationships. Pairing with a fellow developer but in a testing role will quickly create strong bonds and prepares them for pair programming or paired working ways of working later when they revert to being developers.
- It spreads KT. To test something well requires at least and probably considerably much better understanding of the product you are developing than development does. Knowledge Transfer is an exceptionally patchy undertaking in even the best AGILE shops. You soon find out whether you really understand something when you have to test it!
- It weeds out your prima donnas. As a rule, development teams need solid team players rather than egotistical superstars. If someone has an attitude over being made to write tests for the first couple of couple of months as part of their onboarding then they are probably not who you really want on board. Better find out sooner rather than later once they have passed their probation!
- It helps developer to tester ratios. Classically, AGILE teams work on a ratio of developer to tester ratio of around 3:1, although this is changing as developers become more TDD oriented. The testing function is very often under resourced and over worked (but as a tester I would say that, of course).
Hopefully one day I will be given the opportunity to repeat my experiment. Perhaps I was just lucky the first time, but I think as a QA product quality would be much better if more hapless developers found themselves hired, inadvertently or otherwise, into testing roles.