In the short but rapidly evolving life of software development there has always been a war. In the very early days of software development there was no such thing as testers. Like the tyrannosaurids, programmers ruled the world. Programmers did the testing. If they were very good, they just compiled their programs and didn’t need to test, such was the arrogance. Testing was done in production. Software would be written, often as the mis-named ‘one-off’, and put straight into production, to be tested there by the users. Although it has to be said that there was no on-line audience then, mainly in-house users who could vet missives before they were sent out to customers.
Software errors cost the U.S. economy $60 billion annually in rework, lost productivity and actual damages. We all know software bugs can be annoying, but faulty software can also be expensive, embarrassing, destructive and deadly. In an article available at http://www.devtopics.com/20-famous-software-disasters/ five famous software “disasters” are recounted – stories of disasters affecting projects as diverse as Venus probes and radiation therapy machines. It was only after many and various disasters with the established limited testing approach that it was decided it might be prudent, albeit costly, to test the software before it was deployed into production. What an affront!
Developers resented this slight on their brilliance and thus opened up the schism. Testers were given short shrift. Developers purposely held back the delivery of their masterpiece so that the tester had less time to test. Testing time was always squeezed and never given its due need. Testing was always crammed into a short time, and then when it did go wrong in production, testing was always blamed. ‘Why wasn’t that tested properly?’ was the constant cry.
This schism still exists today. Programmers’ egos have not diminished and they often do not understand why their work needs to be tested.
The software development life cycle (SDLC) has long been based upon what is now called the Waterfall methodology. In simple terms the methodology cascaded through its steps; starting with a concept, then providing requirements, building/developing programs, and then testing and putting into production. In this methodology the developers and testers were still apart. The developers would program and finish their programs before they were handed over to testers (often remotely, in different locations) with very little communication between the two teams. The war continued.
But then along came the Agile Methodology (see Figure 1) and there was a truce at last.
Most organisations undertake a mixture of the Waterfall methodology and Agile. Few have the processes and ability to be pure Agile yet. Pure Agile will prevail, unless a new methodology is introduced first.
The development phase of the project is more often the phase that will be purely Agile. This involves the project being broken down into a number of small development cycles called Sprints. Typically a Sprint will be 3 to 5 weeks in duration. At the beginning of a Sprint, the Scrums meet and decide what can be delivered in a Sprint. In this context, ‘delivered’ means developed and tested. A Scrum is a team charged with the delivery of the Sprint. The Scrum will comprise of developers, testers, a Scrum Master and a Product Owner. Typically Scrums number 6 to 9 members. Often one tester to every two developers. A Product Owner is the business representative who manages the business needs, requirements and imperatives. The Scrum Master is responsible for the Sprint. The Scrum Master communicates the progress of the Scrum to the wider team (Test Managers, Project Managers etc). The Scrum Master is also responsible for the development rate. Making sure that the testing keeps up with the development, and the development keeps up with the testing.
The number of Sprints and Scrums required to deliver the whole project is directly proportional to the size of the project. A big project will have a larger number of Scrums and a large number of Sprints, determined by the business imperatives.
From experience, Scrums work better with the Scrum team all sitting together. Admittedly in the first Sprint, and in the forming of every new Scrum, there are the Forming/Storming/Norming/Performing phases, but after a few iterations of this it becomes second nature.
Now developers and testers sit side by side. The testing role is now appreciated and respected and the ratio of time given to testing has now, from a high-level perspective, risen to 65% of the development time. Different testing-type names have been coined, such as smoke, monkey, stress, functional, technical, regression, UAT etc. All this makes the testing a science unto itself.
The developers, maybe by attrition and constant wearing down, have come to respect the need for testing; in some case the testing element has taken the dominant role. In some organisations the testing team determines the order the development will occur in, and Scrum Masters are testers not development leads.
Now, when the cry ‘Why wasn’t that tested properly?’ goes up, there is no excuse. Testing is the critical step before anything goes into production. Sure, there will still be problems and bugs but they should be minimal compared to the ‘old days’. Testers and developers might not always see eye to eye but they now co-exist.
The Agile methodology, with its iterative approach and its constant self-checking and test, re-test approach should start to reduce the number of defects in the end product that is deployed into production. This in turn should reduce the liability attributable to software production and the business costs of repairing (often serious) long-term damage afflicted on customers or on the business itself.
Simon Worthy is an IT Consultant, currently studying for an LLM in IT at the University of Southampton. Simon is currently working at Centrica (British Gas) and has delivered many innovative computer applications throughout his career. Simon can be contacted at pminit2@aol.com
