So, I believe I have played a role in all areas of the software delivery process during my career. I started out as a config management person, then a developer, I accidently became a manual tester for one project, moved to developer in test, back to development, test management, programme test management and finally head of testing. I Remember one job supporting a global test team at a major stockbroker executing load tests on the command line using LoadRunner in 2001 once code was committed into Visual Source Safe (do in brackets why this job memory is relevant i.e. now THAT WAS A DULL JOB.)
Eventually, around February 2002 I started my own business specialising in Test Automaton, Performance Engineering and Technical Disciplines in Software Delivery. Modern software delivery/automation has been part of my life ever since, and I’ve been driven by helping clients get the most out of their software.
This was one of the reasons I started Infuse, I believe passionately that the automation of software delivery was not only modern, but the only way to deliver. With the time being saved I saw endless opportunities to innovate more, make more money, do more interesting things and generally be more creative.
Sadly, between 2002-2012 the industry really didn’t want to know, most firms were more interested in bums on seats charging models and process factories. Automation was solely for regression testing, and only after major system integrators had rinsed the client’s programme transformation budget with lifecycle deficiencies. These so called ‘granddaddies’ of testing, testing board, and even testers themselves didn’t really understand or trust test automation technology to deliver testing, or arguably technology. Testers were brilliant at what they did though, and that was to find faults in software. The lack of technical disciplines however is one of the reasons why there was/still is friction between testers and developers to this day.
The worst blockers for innovation, faster delivery and automation of the lifecycle were most of the large system integrators sponsored by programme executives that now claim to be innovating delivery. For me, it is nonsense. The blockers have switched from don’t believe the hype to be the ‘circulators’ of hype, due to customers finally catching on to the fleecing they have received over the last few decades.
I started Infuse because we always believed in the hype, we don’t know slow-go manual testing. There are big boring system integrators with low tech testers that do that to scales way better than us. But if you want 30 people to do the job of 100 people at high quality, then we can help you. If you want the job of 100 hundred people done at the cost of 30 people, at the speed of Mumbai traffic peak hour then really, we are not that company. You already probably have them doing your build.
So, now your big system integrator executive from multi-billion, 8000 tester service comes knocking about how they have 2000 performance/automation/DevOps people, and their keyword, page object model framework and pipeline development is amazing, or the career manual tester/manual test manager/manual programme test manager you have had suddenly becomes an automation implementation wizard guiding you on this very important strategy talking about the merits of CSV and columns vs Rows on Excel.
Please don’t believe the hype, this is an engineering discipline which requires business sponsorship, and you really need to consider FULLY all the inputs into do this and you do need to be an expert in this discipline.
Here are 7 key takeaways to consider when looking at your test automation needs today:
- ROI. what really is ROI? Are you just comparing saving in testing labour costs? Not only is that rather simplistic, but probably means you are lacking a proper justification for faster, better and smarter delivery. If our ROI is only being decided on test labour costs saved, then you may struggle to deliver this, as currently test automation people do cost more especially, if you go down the Open Source route. If you use a largely script-less or component-based tool however, then this gives you an opportunity to mitigate these costs on a large scale. What is the benefit? Is it defects saved in production? Are we looking to benefit the business shareholders? This goes on the previous point. The main thing is automation of testing is an opportunity to improve overall delivery. If you want to speed up a bit of your testing that is fine but use this as an opportunity to improve delivery in all aspects of your software deployment. Think big picture here.
- Define the pain point you are trying to address honestly? Why is your testing taking too long? Do you have other lifecycle issues? Is this an opportunity for process improvement? think of all the factors and then decide how to address it? Testing taking too long doesn’t mean test automation will fix it!
- Do not automate testing to make a deadline, it will fail. I recall a sales meeting with a retail customer who wanted test automation to speed up a late release due to code quality issues and later delivery and poor environment control. I told them he had spent his contingency and to focus on a risk-based approach manually. I recall our test technology partner was not happy, but I can’t advocate a customer spending on an untrue objective
- Frameworks and tools: Tools should be the last decision, define the pain point, the issue you are trying to address, address the lifecycle process issues affecting the delivery, the skills deficit in the people and then look at the automation. You will be disappointed if you jump to tools first. As for framework, address the need, the data, errors, delivery cycle, skills and then look at the framework. Some tools are also frameworks, see useMango.co.uk
- Open Source/Enterprise tooling – I’ll be honest, this is not a relevant discussion. In the modern delivery world, Open Source works and it’s brilliant but it has its flaws too and you must fix them yourself. If you are not a mature technical team then you will struggle to deliver value. If you really need to own the IP, scripts, and be your own master then do it. Most people are choosing Open Source tools though to increase the value of their consultant contract days and inflate their hourly rates for their next role and really are not in the interest of the business making the most out of their software. There I said it, you can slaughter me, but this is true in a lot of cases I see!
- Frameworks Part 2: There are load of Open Source frameworks out there and some are good, and some are bad. Simply put, consider what you need. At Infuse we thought about the non-technical tester that wasn’t an expert coder and build useMango. If you don’t want a simple framework for non-technical testers that is fine but then don’t get the non-techie to do it.
- Training and Professional Services: I personally can be trained by Andre Agassi/Boris Becker and Ivan Lendl, I’ll still be rubbish at tennis, and even though I’d make a better cricket player for the village pub if I was coached by Sachin Tendulkar, I’d still probably be surpassed by the bar owners 13-year old child. It’s important for business to consider what they want and to use the right people, tools and framework. On top of this choose the right partner, we at Infuse are experts in this area.
So, there you have it, simply put, don’t believe the hype, check the credibility of who is doing this and don’t use it as a simple experience to inflate your value in your next job, because if you are doing it right, you will get that anyway.