Testing is viewed as ugly, why? Because it delivers bad ugly news in the form of bugs. Because there is never enough time to fully test so when bugs are found in production then the question is always asked why wasn’t this found during the testing stage? Why didn’t you do your job? Therefore whatever you do or don’t do as a tester it ends in ugliness. Even if perfect quality is delivered then it’s a thankless task because it is “expected” that the system just works as it should .The testing stage is always where the project manager has to present whether its a go or no go to the big bosses. This is the only stage where the bigwigs really take notice of what is going on and it multiplies the pressure and emotions in and around the project.

Testing gets the rough end because the focus is there and not on the loosely defined requirements nor the misinterpreted design solutions nor the rushed software development. It’s focused on tests which were based on requirements which have been changed or removed along the way and means there is always a gap between what was expected and what was delivered. And it is focused on what tests have not been done and why the progress is not faster. This goes against beautiful quality. We all know you cannot rush a good thing.

I have been a professional software tester throughout my 16 year career, and testing has usually been perceived as the nasty bit that no-one wants to do nor is there enough time left in the project to do it.

Firstly let’s break down the software development cycle into 2 very basic and simplistic sides. Business and IT. Business want a sports car. IT want business to specify whether it’s a Ferrari or a Lamborghini. As the project trundles along it actually turns out that business actually want a bus with a caravan hooked on the back and what IT delivered was a rusty old banger with only 3 wheels because the budget was already burnt arguing between whether it should be Ferrari or a Lamborghini, when the top management thought they were getting a Porsche and when what was actually needed was a bicycle.

Somewhere stuck right in the middle of this is the testing. And, because all of this argument, disagreement, disappointment and frustration happens when testing happens it’s testing that bears the brunt of the finger pointing for the delays and misunderstandings. It happens during the testing stage because this is when business get to see the fruits of all the stipulations they made without properly considering the impact. Of course our agile evangelicals will pontificate that this is one of the reasons that waterfall methodology is so flawed, and there is good reason behind this line of thought. I am equally sure that the waterfall luddites will argue that the v model would have identified deficiencies in the requirements at a much earlier stage. I am not saying they are wrong but I will say that if you have the right people with the right motivation and a good understanding of the others and their abilities then they will find a way to collaborate and achieve the end goal regardless of the methodology they are supposed to follow. Most of us though, whether we want to or not are pulled to and fro by Office politics and both methodologies have their benefits and the concepts of both are idealistic. We are humans and we always make mistakes and we always have disagreements and there is always something unforeseen that gets in the way of a perfect agile or waterfall implementation.

Back to ugly old testing. Business and IT. Business users don’t have time to test because they have their day-to-day work to and testing something they look at every day is just plain dull. Developers don’t have time to test their own work because they have deadlines to deliver. These are of course broad generalisations and there are always people from both sides of the spectrum who are conscientious about testing and do a great deal of very good work in this area. Development inevitably gets delayed because there are technical details that no one had previewed when requirements were drawn, or the requirements were over ambitious. This leads to pressure to deliver and less time for developers to check their own work. With deadlines pending and tensions rising it is the testing that gets squeezed. The other side is that testing is unglamorous, programmers do degrees in software development and analysts do degrees in business. Testing has no equivalent, indeed it is a part of both but it is only a minor and never a major at the university of building careers.

Testing may be ugly on the outside but it has a great personality on the inside. As a tester one has to understand both the technical and business sides of the abyss, and therefore one becomes knowledgeable in both, an expert in neither, but a pro when it comes to sniffing out the weak points in the system and knowing when there is a bug or when there is an problem between keyboard and chair. Therefore as a tester one becomes a source of information for IT as to how a less technical mind will use or abuse the system helping them to build something more robust. A tester is a source of information for the business on the process and methods needed to use the system without running afoul. Therefore pretty handy to have around despite the fact that they only provide the service of finding the negatives. Business analysts win plaudits for defining requirements that gain revenue for the company and developers “do the magic”, technical stuff that makes it happen. Testers are the ones in between. Unglamorous and sometimes ugly but essential to any software development. Repetitive? boring? sometimes, but most jobs have their repetitive, boring bits. It’s great when you find a bug and equally great when the thing works. Ugly from the outside but once you get to know testing you see that you will never be the same again without it.

Strategically testing is at its most glamorous prom queen best when automation is well implemented and well invested. This works for both traditional and new methodologies alike. Why? because it never misses any detail. I spent 8 years handling test automation in a waterfall environment but with this automation the team were able to reap the benefits of agile principles. The automation tool used its own environment and all of the test data was manufactured. This meant that any production bug could be replicated in this environment, the development team were able to fix and deploy directly to this environment. Then a retest followed by a “critical path” regression and a full regression. The result? Production bug fixed and deployed either the same or next day… sounds like dev-ops… With a full regression running every night it meant that continuous development could be achieved with an extremely high level of confidence before it reached system testing. A hybrid solution between waterfall and agile. The benefits, good, proper, clear documentation of requirements and deployed solutions delivered on time with very high quality. It takes a lot of investment, time and faith to get to a stage where test automation is fully reliable and relied upon but it is possible for the ugly duckling to become a beautiful swan.