This week when discussing with a prospect the challenges they were facing with the productivity of their developers, they said,
“I’m finding my developers are spending most of their time writing code to create automated tests for ServiceNow, because they are the only ones with the scripting skills to do it. This is fine for developer unit testing, but is a very risky approach for functional or UAT testing, as it amounts to the developer ‘marking their own homework’, breaking rule #1 of software quality assurance (QA) best practices for test independence.
…however, there is another, far more important reason why this is a bad idea, that completely dwarfs that.”
The prospect recognised that ServiceNow developers are the highest cost and scarcest resource in the ServiceNow dev team. This is especially true on platforms like ServiceNow, where rapid growth, has meant developer costs have sky rocketed and the high quality skilled and certified resources that really know what they are doing, are rarer than hen’s teeth. They went on to say,
“It is critical that my highest cost resources are spending as much of their time doing the thing that only they can do, which is developing and configuring new business features and workflows on the Now platform, not building automated tests, right?”
New business features increase the ROI of the ServiceNow platform by, for instance, gaining competitive advantage, reducing costs through automation or contributing to a digital transformation programme. So any activity that means the developer is not creating new business features, comes at an extremely high price. However, the cost or risks of this approach is often not visible to the budget owner or senior stakeholders, because the domain experts often hold most of the platform knowledge and therefore guide decisions on the approaches used. Abraham Maslow once said, ‘if the only tool you have is a hammer, you treat everything as if it were a nail.’ In other words, if the only way you think test automation can be done is by scripting, scripting is all you do.
Ideally, automated tests need to be able to be put together by non-technical testers by an independent QA team. After having outlined AutotestPro’s method of creating tests without the need for coding or scripting skills (or even knowledge of the ServiceNow platform for that matter), the prospect went on to say,
Yes, absolutely. With AutotestPro, the QA team ‘mark the developer’s homework’, completely independently of both the developers and the platform being tested, ensuring ISTQB recommended best practice for test independence is followed (ISTQB 5.1.1).
Furthermore, the industry standard for developer productivity is a shockingly low 30%. This equates to only a day and a half a week of new business feature configuring or coding! The remaining three and a half days are non-productive and equate to 70% of the developer cost being wasted.
But perhaps this low productivity figure is not so surprising when you realise that with most test automation tools, developers are the only ones who have the required skills to build and maintain the automated tests alongside their platform configuration changes; effectively building ‘code to test code’. How do you test the code that was built to test the code? You end up disappearing down a never ending spiral of creating more code to test code. Before you know it, test automation becomes the project! This is so wrong.
Critical to success with ServiceNow, is getting the most value from high cost and scarce ServiceNow developer resources, especially important in the current economic climate. 30% productivity simply isn’t good enough and is going to denude the ROI from your investment in ServiceNow, potentially leading to customer failure, rather than customer success.
AutotestPro with its zero-code and whole life-cycle automation platform, alongside our partner KA2, increased ServiceNow developer productivity by 38% in just 10 months at an international investment bank.