/***** Tabs anchor links for by roles page *****/
Abstraction in testing can streamline the authoring process, but is it really a benefit? Or can it do more harm than good?
There has been pushback against the increased level of abstraction in test automation. By restricting how much you can look behind the curtain, testing can actually get more frustrating, and the more abstraction, generally the more "codeless" an automation tool gets. This may come as a shock as a codeless test automation tool, but we're actually in favor of reduced abstraction in test automation!
Let's start with the most important part: what exactly is abstraction? Abstraction happens when basic, implementation details are gathered while more specific information is left out. For example, if you want a nice, sweet cup of coffee, you go to Starbucks and buy one. All you have to focus on is ordering your iced grande gingerbread latte (tis the season) and bam, you have coffee. The process that the barista goes through of pressing the coffee grounds into the portafilter, starting the machine, steaming the milk, adding the syrup, getting the ice, etc isn't important to you. Well, it might be if you're a coffee fanatic, but ultimately it doesn't affect the way you order your coffee.
Ok, so what does that look like in testing? Well, instead of ordering a coffee, you're ordering automated testing, and just like with Starbucks, you don't have to worry about the background process. With an automation framework like Selenium (not the IDE, where you do get a greater level of abstraction), you get to use your programming language knowledge to code your test steps and go through the implementation process (making the coffee) yourself. Now if you abstract that process, you put all that code behind a user interface and make it "codeless."
Abstraction in automated testing usually looks like recorders where you manually step through a test through the application and then the recorder replays the test exactly, or rather, tries to. The trouble with this is that it's brittle, and anything like a button that changed color can break the test instantly. The other method is the use of Natural Language Programming (NLP). By using plain English to author test steps, you gain the benefits of speed and accessibility in the test authoring process while still retaining the flexibility and control of scripted approaches.
So why hide the coffee brewing process behind the counter? Also known as, why hide the coding process behind a user-friendly UI? Well, theoretically, this makes it easier to write automated test steps. But there are concerns that hiding the implementation waters down the results, kind of like instant coffee. You can order your iced gingerbread latte that normally comes with three pumps of syrup, but maybe you don't like it very sweet, so you order it once with one pump. But then that's not quite sweet enough, so the next time you order it with two pumps. Eventually, you get the right balance, but it takes a while. Not to mention the perfect amount of ice, milk, hey, maybe you like a very particular amount of whipped cream, too.
Ready to see what our (non)abstraction looks like? Well, you can sign up for our free, two-week trial to give it a try for yourself! Enjoy our easy-to-use interface and authoring in plain English while having the chance to make tweaks with code.