Test Automation as we know it today, is completely obsolete
(and no, I’m not trying to sell anything)
This could easily be a short book if I explain in detail why the way we do automation today for testing is obsolete, so I will keep this as short as possible, and if anyone wants additional information, or would like to try this at their company, please send me a message.
Also, before you read this, think about our history as a species. We have a tendency to be skeptical and critical of new things, or things we may not understand, or have some other reason to be opposed against an idea. Being skeptical is important and highly valuable, but please don’t be so stuck on the way you like to do things that it blinds your ability to evolve in thinking and process, because with the ever increasing speed of technology, the most important skill of all is being able to analyze new ways of doing things, and determining if they apply to your situation and to what extent in a positive view or a negative.
Long ago, I remember test automation when it was first being introduced as part of our development lifecycles, which at the time were waterfall. We had Mercury’s WinRunner and XRunner, Silk Test, Rational Robot and others… For WinRunner, there was a toggle box at the top right of the editing window that changed you from analog and digital recording, where analog was nothing more than a mouse move and clicking event capturing system, dependent on X and Y locations for the items we needed to interact with, such as textboxes, dropdowns, radio buttons, and so on…
That was a revolution, and data driven tests with means to handle constantly churning user interfaces were new features soon to be added. Now, decades later, many of these tools are still around, and have evolved considerably. In addition, we have the mega popular Selenium, with its support across multiple languages, cross browser support, mobile app support with Appium, build friendly assert engines and so much more. And it’s free (as far as upfront money, but you need good developers that will follow the necessary design patterns for ease of maintenance, organization, scalability, as if they do not, the test may become more of a hassle to keep them than it would to throw them all out and rewrite them)
Now, we are already inside of the next revolution, one that is so different and so much more powerful than anything we’ve ever had access to before, being, Artificial Intelligence. Artificial Intelligence (or ‘AI’) is an umbrella term that includes a variety of technologies and ideas, some of the more popular being…
· Computer Vision, Machine Learning, Reinforcement Learning, Neural Networks, and many more.
The component we care about here is ‘Reinforcement Learning’, and uses a set of rules and algorithms called ‘Q-Learning’. Q-Learning, at its most basic form, can accurately be described as this…
1. Define your Objective. (What you are trying to answer or solve)
2. Define a set of actions that are capable of being executed on the computer and have a measurable state. (How you are trying to solve the Objective)
3. Assign Rewards based on the measurable state assertions.
If we break this down a little further, in the context of software testing, the relationships between Q-Learning through Reinforcement Learning, which is a component of Artificial Intelligence, look like this…
*** I am using Selenium here as the tool of choice. If you do not know what Selenium is, or do not know what the ‘Page Object’ design pattern is, please look it up on google, and make sure you understand the following terms…
· Page Object Class with ‘Action Methods’ and ‘Locators’
· Test Class and how to perform an Assert.
*** If you do not know what a ‘Test Case’ is, please look that up as well. Make sure you understand what ‘Test Steps’ and ‘Validation Steps’ are before continuing on.
Q-Learning uses the following variables…
1. S = State (Our Measurable State of the Previous Actions)
2. A = Action to perform next
3. R = Assign reward allocation for the action about to run next
4. S_ = Get the State of the Action we just ran at Step 2
This is referred to as ‘SARS’ often, and you can do this same thing across multiple machines or processes by adding the following variables, making the new required set of variable values this… SARS_A_ instead of SARS_, where the extra S_ and A_ are coming in from a different machines Q-Learning data.
Now, we must understand how to hook the Q-Learning into Selenium, which is quite logical.
In Selenium, our Test Case title = Q-Learning ‘Objective’
In Selenium, our Page Object Classes ‘Action Methods’ = Q-Learning ‘Actions’
In Selenium, our Assertions = Q-Learning ‘Measurable States’
In Selenium, our Assertions also assign possible Q-Learning ‘Rewards’
With a system created as explained above, (and I have done this now over 20 times, and I was highly skeptical until I witnessed it actually working, and double, triple, quadruple., etc… checked the results) you get a system that will try all possible combinations, keep track of all of them, keep the results for each try, and at the end, can export the manual test cases and all of their results and valid tests data discovered all into a test case repository as long as the database on the backend of your repository can be accessed directly.
So, it appears that the next generation of QA will have us, the testers, spending most of our time defining actions, data for the actions, and objectives, and then the Artificial Intelligence will take care of creating the manual test cases, generating all of the automated test scripts, executing them, tracking results in real time and historically.
Now, in this new state of empowerment, with outrageously thorough test coverage and incredibly detailed test cases in our repository, traditional QA in general as we know it, can move forward and take automation in general into its rightful place as both a quality gate and a revenue producing profit center through productivity gains as our ability to automate evolves into powerful new features and tools for the end users of our applications we test. We go from being a necessary expense, to a quality machine with revenue generation skills by feature additions and enhancements we create.
I don’t expect you to believe this, but I do give my advice in researching and learning more, and if you want to try this, but need help, reach out to me and I’ll see what I can do.
When test automation engineers can act as a thorough and deep quality gate and generate revenue by using the same techniques to add features into our applications and services we used to only test, it will create a demand for test automation engineers at a level never experienced in our industries. What we do is a natural evolution of Artificial Intelligence, as AI works by simulating actions something would take, and then asserting and assigning reward. We are experts in simulating people taking actions in an app or service, or API call or unit level, etc… Therefore, the combination of these skills and approach are amazing, and it’s not a matter of if, because it works today, it’s a matter of when.
Remember, to have what we’ve never had, we must do what we’ve never done.
Everything is considered impossible until we do it, then it’s considered logical and reasonable. So… are we going to wait around until the other technology disciplines see the potential and make this widespread, or are we going to rise up with these advances and change the shape of quality in the world, and change what it means to be a test automation engineer.
We are unique in what we do if you take time to recognize the differences. Being a developer is not a promotion over a test automation engineer. As test automation engineers, we use tools and code to create software for testing software. We spend our time getting better at creating software that acts more and more like people do in regard to using the products we test. On the other side, software developers create software for people to use to do things. Those are not the same, yet I have never heard that point made outside of hearing myself make it in almost 30 years of testing. If you are reading this, and you are a test engineer, don’t be bashful, take pride in understanding what you do is unique, valuable and powerful!
This has been Trevor Chandler, a technology expert with over 150 automation projects completed across 56 different companies, a handful of world’s first achievements in technology, and a collection of new inventions and laws of computer science.
Thank you for reading this…
Trevor E. Chandler
