How Smarter Test Automation Could Provide REAL DevOps



This holistic blog is expected to be my 1st in a series of trending practicing of new Natural Language Processing and ‘no-but-allowing-code’ technology enablers in so called “3rd Test Automation Era” tooling, throughout 2022. Here, I could have been referring to contents from the globally acknowledged survey reports on testing or a well-written book on quality for DevOps teams. But I’m not doing so as I’ve got much more to share, the practice-oriented evangelism herein should match it quite well. Let’s take a look at some of the current biggest challenges not limited to testing but in entire SDLCs (Software Development Life Cycles) – I’ll get back soon below with suggestions on how the challenges could be solved.

The new era of ‘No-but-allowing-Code’ Test Automation Tooling

If not yet automating TA (Test Automation) itself, what if UI TA efforts could be in-sprint scoped and initiated eventually mock-up-only based, maybe even provide multiple building bricks of TA-executable test cases, become self-healing on object-captures or recognizing text/fields/images code-object-independent like a human being, and be independent of scarce Developer resourcing?

Then that could enable a wider pool of Automation Testers like me to provide in-sprint CT (Continuous Testing) as it’s intended to be – i.e. as an essential means to get software quality instantly improved. We could do TA not just more effectively but also let the tooling do it a lot more efficiently. This is by some called practicing the 3rd TA era – personally I look very much forward to doing that, while believing it’s the near future, since some TA tool vendors already provide the new technology enablers for it! Watch out for more details on that later below.

SDLC Market Pains

While knowing about the importance of ensuring agreed quality in software-deliverables, testing is perceived by many as a delaying bottleneck to SDLC-cadency – also due to the facts that CT isn’t practiced as required, and it often consumes scarce code-skilled resourcing. Even within TA much tooling doesn’t seem to provide the means to keep up with the desired speed, and in-sprint testing seems TA-impossible and delaying in manual form.

SDLC Market Requirements

In CI/CD-pipelines, there are increasing demands for faster and shorter software delivery cycles. Although many businesses claim they’ve achieved the DevOps state, it’s just not the real one wanted by most – as CD desired delivery cadence/frequency suffers under CT “delays”. Required to obtain that real DevOps state is either doing or at least preparing in-sprint TA/CT. At the same time Developers prefer and are more keen to use their creativity on coding software solutions – i.e. not so much in testing them.

Limitation Providers on how TA is Dominantly done Today

TA tooling, processes, governance, and organization provides the limitations on how TA is mostly seen done today. That is, both in terms of technology and needed manpower. Some TA tooling is as close to the code of an API or SUT (System Under Test) as having to address it directly for TA-purposes, while much TA tooling in use only deals with (capture/replay) 1 SUT UI object at a time.

Unless proactive steps are taken to make the act of TA available for not only scarce code-skilled Developers and Technical Testers but also for ‘no-code’ but technically minded Test and Business Analysts, TA itself will never undergo its own revolution – i.e. a currently realizable revolution in competitively fulfilling all the above mentioned SDLC market requirements.

Widen the pool of team Roles Enabled to Doing TA

As just indicated, doing TA should never be dependent on any scarce resource – i.e. don’t forget fierce inclusion of Test and Business Analysts! Let me just depict 4 main roles doing TA – in a slightly “square” way 😉

Unless you’re an SDET (Software Development Engineer in Testing), as a code-skilled Developer you quite likely don’t fancy testing, while you would “no-fuzz” prefer to code and glue together any TA if you had to – i.e. doing nothing more in that test regard than you’re told to. As a technically minded Test Analyst or an SDET you would likely scope what to TA incl. business process user actions and how to build scenarios/cases as well as setup a TA-framework of structured folders/elements and perhaps even some recyclable Test Data Management. As a Business Analyst you would probably scope business priorities for TA incl. user process/workflow actions and look for any smart quick’n’easy approach. In case you work in any other role than either the code-skilled SDET or Developer, you would likely be dependent on utilizing a ‘no-but-allowing-code’ TA-tool.

What Makes Todays ‘No-but-allowing-Code’ TA Tooling so Smart?

Some commercial TA tools now provide the technology enablers on how TA could be done much broader available, smarter, faster, and test covering as desired. That is, even despite or because of being ‘no-but-allowing-code’ approached due to a keyword visual language. Mentioned here are 3 main enablers as well as a short elaboration on AI/ML (Machine Learning) and intelligence providers.

First to come in handy is multi-capturing of all UI-controls incl. UI-snapshot-logging in 1 initial big scan of any source- and device-agnostic SUT/App. Secondly and even more value-adding comes Model Based Test Automation (MBTA) providing a solid and diagram depicting foundation for auto-determining test coverage/scope, as well as – on the basis of “just that”, the multi-captures, and automated rules dependent activity path-building – doing auto-design/-creation of instantly executable MBTA cases as desired, and in addition do the same for CI/CD changes/increments. Those 2 enablers go hand in hand as re-scanning will expose changes, narrowing a related new MBTA test gap by sufficiently scoping and covering that test-delta – and in such context one could argue getting a means of self-healing earlier captured objects/elements. The 3rd impressive enabler regards source-agnostic UI text/field/image recognition like a human being but faster – i.e. even based on hand-written mock-ups with no code behind them yet, for scoping and preparing soon TA builds.

Conditional to a matter of definition, currently ML/AI can only drive TA in case the tool integrates business process analysis, change impact analysis, or/and it has captured object/element self-healing enablers. Implied getting holistically approached, TA really could provide intelligence not only within Testing but also Change, Process, RPA, and Business Intelligence.

Conclusive Summary

The challenges of SDLC-cadency ambitions can be solved much of the way through improved ‘no-but-allowing-code’ UI TA tooling, any-scale multi-providing technology enablers, and a widened team role inclusion in doing UI TA. In fact, such in-sprint TA could enable real CT and an opportunity of obtaining that real DevOps state. In addition, a few commercial tools provide automation of fully overviewed DevOps processing with such even self-healing TA tooling integrated.

Ultimately, TA should automate itself one day in future – but for now modern TA concepts and technology enablers need grasping and implementation. Just as consulting partners are increasingly relied on by companies to guide them in their DevOps practices, my guess is in near future they would too in their TA journey.

Jesper Bo Christensen


Jesper started his career in Testing in 1998 on nationally and globally enterprise scaled software and began working on Test Automation in 2008. He has experience across a wide range of business verticals such as Telco, Public Sector, DWH/BI Delivery, Financial Services, Retail, Utilities, Mobility, Life Sciences, and Medical Devices. Jesper’s attention to detail on business and automation processes is a continued focus into which he brings his passion for innovation within Test Automation technology enablers. He applies this to Cognitive QA and has developed our business friendly and linguistic sustainable test design model and framework of cross-functional dialogue enabling folder- and object-structures. As an ‘Agile Test Automation Architect’ role at customers he builds and leverages on relationships with other clients as well as partnering tool vendors. This collaboration inspires Jesper to boldly propose innovative features getting developed and applied. A diligent and analytical approach enables Jesper to provide our customers with a tools agnostic assessed and hands-on practical overview of how to realize the value adding enablers of test tools, in order to help them monitor and report on the quality of enterprise software integrated business processes and functionality. Aligned with future predictions of Sogeti’s most recent “World Quality Report”, Jesper is at the forefront of how Test Automation tooling develops and integrates eliminating test debt. Complementing the approach outlined in Sogeti’s “Quality for DevOps teams” book, he’s also convinced that real DevOps requires real Continuous Testing which calls for ‘no-but-allowing-code’ tooling which utilize AI-empowering Model Based Testing (MBT) provisioned coverage and tests as well as Machine Learning, self-healing, Natural Language Processing (NLP), human-eye object recognition. With this approach Jesper is ready to practice the 3rd Test Automation era in which ultimately Test Automation itself is to be automated.

More on Jesper Bo Christensen.

Related Posts

Your email address will not be published.