Transcripted Summary
First, I wanted to start by talking about the motivations behind why you would care about something like codeless test automation. And from my perspective, with my experience in doing test automation, I've seen a lot of people effectively reinvent the wheel, building their own coded framework solution or even a record and playback solution that effectively tries to solve all the same problems that teams face when doing test automation.
And I think that it's a problem that everybody faces when working in software development, and it's a real problem and it's something that I think right now the industry is poised to actually solve in an effective way.
So, it's something we're paying attention to. And I think that there's a lot of stigma attached to something like codeless test automation. A lot of the stories that people have about tools like this, I think are based on old stories, and they haven't acknowledged yet that the tooling has gotten quite impressive and solves the challenges that you face in the daily trenches of test automation in a real impressive way.
I think instead, a better way to reframe the thinking around codeless is to think about other facets within software development, other technologies.
If we look at something like database technologies, where you have NoSQL. NoSQL doesn't mean “no SQL”. It actually means “not only SQL”. So, it's something like SQL plus something that could be better than SQL or amendments to it.
And if you look at something like serverless technology, it doesn't mean “no servers”. It means that the complexities of the technology are abstracted away, leaving you with the important and relevant tasks that you can focus on.
And so, I posit that the same thing can be applied to how you think about codeless test automation.
Another way to think about this is to look at a blog post, [The Rise of "No Code."](https://medium.com/@rrhoover/the-rise-of-no-code-e733d7c0944d, from the creator of Product Hunt, Ryan Hoover. Here's an excerpt:
"Predictably many criticize and judge those that use “no-code” tools. While they come with tradeoffs, it's inevitable that more products will be built — or at least MVP’d — without writing code, including by programmers that can code."
And so, I posit that the same thinking can be applied to test automation, that even people who are proficient in code, will also use codeless test automation tools because they have gotten to a point where it's easy to get up and working with reliable test automation without having to write code. And so,the tradeoffs are actually negligible. And so, for even people who are experienced in programming, they might lean on tools like codeless test automation.
And so that leaves you with the question of — what goes into a good codeless test automation tool?
Angie Jones put together this terrific write up, effectively giving you a rubric of the 10 features that every codeless test automation tool should offer. I'm going to step through each of these just real briefly. So the top 10 list.
1. Smart element locators
This is number one I think arguably because this is where historically recording playback tools have all fallen down. So, the ability to record or capture a flow through app of a user, and be able to identify, in some intelligent way, locators so the tests aren't brittle. Some tools do this through potentially some sort of statistical analysis. Some do it through potentially AI. Others might just do it by grabbing a bunch of locators and using all of them. What we don't want is to have just one locator and that's it. The test will be very brittle and likely break.
2. Conditional waiting
Any tool worth its weight has the ability to be flexible in terms of how it synchronizes itself with the application that's being tested.
3. Control structures
Things like control flow, the ability to conditionalize your tests or introduce looping if you need to. Basically, the ability to add more sophistication to your test code.
4. Easy assertions
The ability to add powerful assertions quickly. Not just simple assertions that rely on text on the page or an element’s specific attribute.
5. Modification without redo
The ability to modify a test without having to recapture the whole thing. A lot of times people think about tests with record and playback or codeless as throwaway tests. If they break, you just go through and rebuild them from scratch. But having a powerful IDE, giving you the ability to modify tests and enhance them without having to recreate them from scratch is a hugely important feature.
6. Reusable steps
The ability to reuse or abstract steps from a test is also helpful, otherwise it becomes a maintenance nightmare. And that's why things in code like page objects exist. Having some kind of abstraction (e.g., reusable steps) really helps make things more maintainable over time.
7. Cross-browser support
The ability to run everything cross-browser. This is one I think that a lot of tools don't get right. They offer the ability to capture and replay only in one browser. And I think that there are, thankfully, at least one tool, if not some tools, that offer cross browser support. But this I think is it's such a killer feature that it can't be overlooked.
8. Reporting
The ability to have good reliable reporting. So, when there is a test failure, you can look at the results and start to understand pretty quickly what went wrong.
9. Ability to insert code
The ability to insert code as if it's an escape hatch, basically. Most tools look to something like JavaScript, so that when you reach the seams of the tool, you have the ability to do something more sophisticated that works outside of the boundaries of what the tool offers.
10. Continuous integration
And the last one ties this all together so it can actually fit into a development workflow with continuous integration.
I'm going to step through, in this course, a free and open source record and playback tool called Selenium IDE.
It's part of the Selenium project. I'm not sure how familiar you are with it, but at one point the IDE was very popular and also, I think largely gave a bad rep to Selenium because historically record and playback tools were challenging to work with. Eventually Selenium IDE died. It reached end of life support when Mozilla moved Firefox to a different platform for its browser extensions.
And so, it's been rebooted last year. The folks at Applitools started investing a lot of effort into resuscitating it. And now there are two full time developers working on improving and making Selenium IDE something that's truly a powerful record and playback IDE. I'm one of those developers. I'm a full-time maintainer on Selenium IDE, and I think that there is a lot of really powerful features that are available within it that I want to show you.
So, as we step through this course, I'll show you all there is that you can do within the IDE, and how you can use it to level up your test automation practice regardless of where you are in your maturity level with test automation.
