How Does Codeless Testing Drive Squad Velocity?
Have you ever wasted away a weekend due to maintenance issues? Imagine the sprint is just about to end. Devs has done their checks and launches code freeze phase, manual testing initiates, next sprint planning starts. Some test automation is available, but with over a 50% failure rate, it’s ignored. Maintaining the scripts has been a job in itself. Midway through stabilization week, a bug is found. The in-app payment feature we’ve introduced a few sprints ago was touched by someone this sprint. Problem is, that someone is off surfing on their vacation week. You will need to find the root cause, undo the code that’s been written this sprint, and redo it the right way. Here goes your weekend.
Truth be told this whole situation can be avoided. The question is, how?
Delivering high quality in time — the codeless way
Codeless comes to solve one of the main challenges of delivering high quality in time: the need to maintain complex automation scripts and endless object repositories. This could very well be a full-time job, or even a few full-time jobs, who need to invest time in making sure test automation works across all apps you create.
Take an object repository for example. More than a few items will change with every build, which can even be a few times a day. How can you ensure your script interacts with the right objects? One approach is to have the developer tell the tester all object changes in each build. That’s unlikely. Another approach is to scan the object attributes and realign the object repository before each regression test. That’s a heavy manual effort that should happen a few times a day. Last, the tester might run ‘white box’ testing. That means the tester has access to the source code of the app (again, unlikely), and no system level control is needed.
The idea behind codeless testing is that the solution itself creates and maintains the necessary user flows and object attributes without any human intervention. No maintenance is needed over time. TestCraft’s data shows that their AI technology can overcome more than 82% of the changes so the tests won’t break. In case a test does break, the issue will be pointed out and the fix is done by a simple point-and-click.
Figure 1: Smart binding technology can maintain object mapping through changes in the app
Building trust and value to drive adoption
The transition from the current state of manual testing, or flaky test automation, into high coverage of codeless testing, does not happen overnight. It needs to be planned to build and optimize developer trust that the outcome is genuine and worth using.
When building your test strategy, here are some best practices to ensure validity and value:
- Start small, prove value and increment iteratively: define a few tests flows, build them and ensure they are solid through all platforms and many iterations, and only then demonstrate those to developers. When a developer believes a failure is a real failure, the trust will grow.
- Build it in a modular and reusable fashion: building the script in a smart way will minimize your chances for bugs. Further, since you can reuse test steps and test scenarios, if the app changes materially, you will know exactly which area of the script to change and you need to make the change only once.
- Review the reporting: does it deliver a clear error message and the needed data for developers?
Introduction of insightful, stable test automation for developers (without asking them to invest their time in creating it) would create significant collaboration with them.
How do codeless automation testing tools help team velocity
Coming back to our squad that’s delivering the next build. Imagine, on initiation of the sprint, new user flows are being created and maintained throughout the sprint. Those new flows need to be described once, and that can be done by anyone: there is no need for advanced or any coding skills. Imagine leveraging all of your manual testers, perhaps interns, or marketing folks to create those acceptance flows.
Figure 2: Initial visual user flow generation can be done by team members who do not necessarily have coding skills
The real beauty comes when the developer checks in code: Automatically and without any human intervention, the code would be built, uploaded to devices and servers, and those test flows would execute on the target platforms. Notice, no human hand was required to modify the test code to adopt new object identifiers.
The developer can gain insight into defects they introduced 5 minutes earlier. They can go ahead and fix it on the spot, even faster than opening a bug in Jira!
In this fashion, teams can achieve a high-quality build in high confidence throughout the sprint and at the end of it, with no additional effort. And certainly no yelling!
Summary
Team leads are laser-focused on optimizing innovation in their teams. An innovative product allows the business to create differentiation and drive success. What they do not want to do (and neither do developers), is spend time testing, or even worse, developing test cases.
However, if that testing ran in the background per commit, smoke, regression or release test — at no cost, that is an upside and would make developers be motivated to create a better product at the same time.
Originally published at www.testcraft.io on July 9, 2018, by Amir Rozenberg.
