No Code, No Test?

If the testing activity can be integrated into the coding activity, who tests if there is no code involved? Does there have to be code in order for there to be a test activity – and when does the scale tip for testing to happen?

There is a new type of business applications emerging – the “Low Code / No Code” products. The WordPress platform like this one I’m writing from now could be one example. AirTable could be another example of a higher order solution, that enables some user to quickly and without code organize and automate information. What we see in the testing tools space with Cypress and Mabl, is similarly a trend, where the test cases and scripts are directly linked to the end-2-end business purpose, not the underlying technologies. Low Code tools has emerged as yet another type of “customization” and “configuration” business solution.

Evolution line and groups of products (Wardley Maps X-axis)

The trend is clear and has been on the horizon for a while.

Low-Code/No-Code will disrupt this entire pattern, as enterprises realize they can be even more successful with their digital transformations if they do away with hand-coding altogether, adopting Low-Code/No-Code across their organizations instead. “No-Code is here, and it doesn’t care about making your IT organization more efficient,” explains E. Scott Menter, Chief Strategy Officer at BP Logix. “Its only purpose is to turn your business into a digitally integrated, audit-defying, silo-resistant object of their customers’ desire.”

The Low-Code/No-Code Movement: More Disruptive Than You Realize

If a consultant can automate her unique process into a tool in hours, she can solve customer’s problem faster and show the value of her efforts. If a small business owner can build an app for his needs, he can increase business efficiency with automation and save valuable time to expand his business.

No-code Revolution. Why Now?
Wardley Mapping y-axis: User proximity / Code needed

To me there is a direct correlation between amounts of code required and business needs and end user visibility. The less “scripting” a business end user needs to do and “scripting languages” to understand the better. Airtable, as mentioned above, wins over spreadsheets in the end.

Similarly the faster cycles and feedback of Low Code tools is more attractive to the business than having “code high” teams develop applications. The “slow and high” code projects are never realized.

Wardley map: Low code evolves and outmaneuvers “high code”

One way to see this trends, is that while “Robot Framework” and other web-based open source “RPA like” frameworks exist, the emerging approach for testing standard software solutions trends towards Low Code:

Perhaps RPA tools and similar Low-Code tools can be compared to the macros of If This Then That, where you can automate tedious repetitive tasks – also among your business tools. But even with low-code tools the complexity of the scripts can make it a mess, and the visual scripts needing coding practices.

Similarly, the need for explicit testing of the business functionality emerges at some point in the evolution of the “low code” solutions. Every solution moves from Experiment to emerging practice and end as a standard/best-practice. The explicit testing need emerges along the way but becomes less visible on the left-side products/commodities.

Yet to me – testing happens everywhere. Testing is key to the experiments of the pioneer, testing is key for the settler bundling solutions and testing is key for the town planner to secure stable operations.

Simple illustration of the Pioneers, Settlers & Town Planners Model.

Be aware that while testing is happening, it is not necessary by the tester. Don’t hawk the testing activity, let the experts play their part , have testers for the remaining exploration and have tools for the rest. The trend of less testers and more testing is still active and testing is shifting to the future even faster these days. A test happens every time a person doing something thinks and ask questions like: let me try this, could you test this, what happens if?

There doesn’t have to be code for testing to happen.

When to use RPA in testing

This post is my current take on using Robot Process Automation (RPA) tools for automation in testing. RPA tools comes in different shapes, some are better at some things than others. Similarly it has to do with the tool stack of the system under test.

First some definitions/terms.

RPA/RDA definiton: I use the original Horses for Sources definitions: “increase productivity, support human operators in completing tasks and activities” (RDA) and “increase process efficiency, reduce manual labor by automating transaction intensive activities” (RPA). In more practical terms RDA is across the desktop while RPA is more about background processinga poor man integration between systems.

The class of RPA tools: To me there are at least 4 groups of tools that all claim the RPA label: Test automation (LeapWork, Tricentis), Business Process Optimization (UiPath, BluePrism, Kofax kapow/RPA, Automation Anywhere…), Web only (Testim.io, Cypress.io) and Coding frameworks (Robot Framework, RoboCloud, AppliTools).

System under Test: There is more to a system under test than a web page with backends or an app for a smart phone. Explore the notion of System under Test. You might not have access to the source code – as the test pyramid assumes.

The enterprise challenge: Large businesses and organizations unfortunately struggle, as their IT stack is much more that web only. They want the benefits of continuous testing to their whole technology stack. Existing automation best practices doesn’t seem to address testing on top of IT systems that are older than SAFe, agile and Test-Driven Development.

Automation in Testing: See the AiT definition and namespace: “using automation to support his testing outside of automated checks“. Use tools and automation to handle all the tedious tasks of your active testing activity. Use automated checks to cover the binary requirement confirmations.

When to use RPA tools

Putting RPA tools in play in test automation do enable digital transformation and acceleration of the test activities. There are many parameters to evaluate when to use RPA tools in a testing context:

Simple flow chat for deciding to use RPA tools

Hence, the sweet spot for using RPA tools is a as an execution muscle for mainframe solutions, commercial standard applications and legacy systems with inactive or unavailable codebases. The test management system is still key in providing an overview over all testing activities across CI/CD pipelines, RPA and tests based on human evaluation.

If your system under test is web only, you can follow the modern testing principles and build in Observability in (https://charity.wtf/) and a lot of the things in the code. Plenty of best practices around ci/cd for web systems. Obviously it depends on how well the knowledge about the system is codified – but you can work on that within your org/team too. It’s more tricky of the source code of your web SUT is not available to you and render new locators every time you deploy or refresh. … for that consider to move up the stack and use Cypress or Testim.

Remember – there are no silver bullets.

Shot, Neglect or Train?

How you treat the bringer of (bad) news tells me a lot about the organisation and potential for business growth. Go Read Accelerate – that book is full of insights. One of the models, is the organisational types from Westrum:

[ Screen capture from the Kindle issue of Accelerate ]

Andy Kelk has a to-the-point description about Westrum on his blog:

To test your organisation, you can run a very simple survey asking the group to rate how well they identify with 6 statements:

https://www.andykelk.net/devops/using-the-westrum-typology-to-measure-culture
  • On my team, information is actively sought.
  • On my team, failures are learning opportunities, and messengers of them are not punished.
  • On my team, responsibilities are shared.
  • On my team, cross-functional collaboration is encouraged and rewarded.
  • On my team, failure causes enquiry.
  • On my team, new ideas are welcomed.

The respondents rate each statement from a 1 (strongly disagree) to a 7 (strongly agree). By collecting aggregating the results, you can see where your organisation may be falling short and put actions in place to address those areas. These questions come from peer-reviewed research by Nicole Forsgren.

https://www.andykelk.net/devops/using-the-westrum-typology-to-measure-culture

So when a passionate person comes to you with (bad) news, what do you and your organisation do? Do you reflect, ignore or hide the request? Do you say that it’s not a good idea to bridge the organisation? Do you raise an Non-conformity and set in motion events to bring “justice”? Do you experiment to implement the novel ideas and actively seek information?

FAIL = First Attempt In Learning.

Go read Accelerate!

ACCELERATE – The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

by NICOLE FORSGREN, JEZ HUMBLE, GENE KIM

The authors have “multiple examples of applying these practices within mainframe environments, traditional packaged software application delivery teams, and product teams“. It’s not just for business-to-consumer web-based organizations.

The book is a tour the force into software delivery performance – the research and statistics shows a clear correlation from DevOps and Lean principles to high achieving organisations. Every arrow on the below model is backed with research. Read the arrow clearly as “drives”, “improves” and “lead to”. E.g. Continuous Delivery leads to Less Burn out.

Saved you a click: https://itrevolution.com/book/accelerate/

A last thing to highlight: High performing organisations have lower manual work percentages in areas like: configuration management, testing, deployments and in the (ITIL) change approval process.

So – if you want to increase the boxes on the right, go do the stuff on the left.

Read the book and act on it.

Characteristics Change

Susanne Kaiser @suksr did a talk at DDD Europe 2020 on the topic of: “Preparing for a future Microservices journey using DDD & Wardley Maps“. The below slide (from SlideShare) is a superb illustration of the Wardley map evolution scale. I just want so save it here – to savoir it.

PS: Even Wardley Maps moves on this scale…

Wardley Maps - Characteristics change
Wardley Maps – Characteristics change by @suksr

See also: To Transform Testing, Innovation in Testing, Broaden the scope of the SUT, todays innovation becomes tomorrows commodity.

To Transform Testing

There is no doubt that our long lived testing narrative is under pressure. To continue to bring business value, both the IT field and testing is transforming to be about proactive business enabling.

The IT domain is currently buzzing with the word “IT transformation” – the idea that IT services should be more about “inspire, challenge and transform the digital businesses“. That it should be less about delivering IT products and artifacts and more about enabling digital business outcomes. Even for testing – it should be less about a product/service, and more about business necessity. As Anders writes:

Stop focusing on the things that bug people, and dare to do both IT and testing smarter and more business focused from the start. Build Quality in – smarter from start. That goes for IT services as a whole, and definitely also for the testing activities.

What can you do to transform your testing? I have three areas:

Discuss Business Strategy

Learn Wardley mapping – and use it like Chris McDermott to create context specific maturity models with Wardley Maps informed by Cynefin. Use the mapping to Broaden the scope of the system under test.

Align with the Business Strategy

Leading Quality [Cummings-John, Peer 2019] has a whole chapter on “Align your team to your company growth metric“. Consider if the company you work for is driven by Attention, Transaction or Productivity metrics, and arrange your test activities accordingly.

Dare to Deliver in New Ways

We are usually talk so much about optimizing the (IT and testing) delivery, that we forget other ways to be innovative and provide business enabling. One way could be to dare use new technology like RPA or a HoloLens to support tedious tasks in testing – to use an existing product to something new. Another approach to actually test “all the things” that matter or to apply testing to IT outside the realm of application delivery.

To Transform Testing I will discuss, align and dare so that test solutions can be proactive business enablers – (not only achieve shippable quality).

Mapping Mondays – Pioneers, Settlers, Town Planners

How Automation Affects the Business

As of writing I am managing the testing of a large enterprise IT program, where we are implementing a new commercial enterprise solution (COTS).

Over the last many months there have been requirement workshops upon requirement workshop to write down what the new system should be able to do for the various business units. We have had many representatives from the business units as part of the workshops and now have about 1000 specific business requirements that needs to be tested.

Some requirements are closed questions, others are more open-ended or similarly require some thinking. Currently the ratio is that 70% is done by test automation and 30% is for a few of the subject matter experts to test. Management was happy with this, as this made the project faster, the solution more robust and the project less reliant on taking the business people away from their “real work”.

So far so good

The other day I reached out by mail to more of the business people involved in the workshops to let them know that testing had started, and that they would be able to access the solution under test when it had been “hardened”. But so far, only a few “track leads” would be involved.

The feedback surprised me, as my message was both good and bad. Good in the sense that they would not be involved so much, but also bad that they would not be involved so much. One wrote back to me:

  • There is still a risk that the solution will not be as the workshops intended, as the requirements and solution might not capture precisely, what was agreed during the workshops
  • Having been part of the workshop, we are held responsible by our coworkers as to how well the new system supports the business
  • Why don’t the project want our involvement on this?

... but that was “just feelings”, he wrote in the end. And indeed it is – No matter how it looks at first, it’s always a people problem and even if we have a successful test automation effort – we can still fail to appreciate the experts knowledge and by that fail to solve the business problems.

More about “Leading when the experts test” at ConTest NYC 2019.

I was out hiking in April. But city management had locked the toilet up - out in the woods. As an END user my problem was then solved by doing it in the woods. And all fancy sheds where for naught.
I was out hiking in April. But city management had locked the toilet up – out in the woods. As an END user my problem was then solved by doing it in the woods. And all fancy sheds where for naught.