English | EN 
Introduction
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.
