Back in the 90’s I was a developer. I was not the fastest but I knew the systems well and was the best at finding solutions to problems which people with extensive development knowledge were unable to.
The IT department comprised 5 developers, a couple of Operations guys, someone who did telephony and a recent invention called a PC. We had no helpdesk, business analysts, architects, designers and no Testers yet we supported a 300 strong organisation.
“How?” Well….someone in the business sent a memo (like e-mail but on paper, sent in the internal post and delivered by the post boy) to the IT Manager asking for work to be done. The memo was then sent to a developer. The developer called the business person and arranged to go and see them. We talked about what they wanted, made some notes then went off and started developing the solution. We might go back occasionally and ask if we were headed in the right direction, then ultimately the business person would be happy and we would put the change live. Some 20 years later this is now deemed as “Agile”.
“But surely as a developer you made mistakes? What happened then?” Well… they knew exactly who had written the code or program. So they picked up the phone and called the developer. If the code was bad and there were lots of problems (design features we used to call them) you would end up with an irate business person on the phone screaming at you. More often you would get the odd call explaining something was not working. So you would look at the users screen, see what was going wrong and then fix it. That involved taking the code, modifying it and putting the altered code live again. Some 20 years later this is now deemed as “DevOps”.
As a tester I recognise the weaknesses of these old methods and also understand why it was not the best way to work. I also recognise some of the strengths of those days and the resultant speed.
As IT is exponentially increasing in complexity the desire to link our technology seamlessly together is expected as standard. “So why are these old methods being revitalised and given new names?” It is all down to speed and in fairness this is predominantly driven by an increasingly demanding business.
But this is a new and improved DevOps – the new advocates of DevOps are not recommending the removal of testing, just that it works more closely with development. Those that are removing the testing process are ultimately getting it wrong.
In one IT department I recently visited it was noticeable that the Technical Debt being introduced into Production was far higher in the areas that were following these new practices. The reality is the requirement for Test is still high under these methods. Test must still keep developers on track and challenge requirements.
The reason that more serious faults are allowed into production is two-fold. Firstly, some people use these “new” methods as a means of removing process and due diligence, focusing on speed only. Secondly, because in the 1990’s DevOps model the developer who gets it wrong thinks they can put it right in live. These are the people that will bring damage to the methods and ultimately cause business people to lose faith and trust in them.
So finally I would say that this is new. There are similarities with some old methods, but they have evolved and improved and testing is a huge part of these when implemented correctly.
Grant Obermaier – Former CEO Qualitest UK
