What is the difference between browser and protocol automation? Guest flooder Leandro Melendez, aka Señor Performo, discusses the advantages and disadvantages of each one, especially with regard to load testing.
Nicole: Hi everyone, Nicole van der Hoeven here again back with another Ask a Flooder, and this week I've invited a guest flooder to come and answer a performance-related question. Please welcome our amigo Leandro, or you might know him as Señor Performo. ¡Bienvenido, Leandro!
Leandro: Hello, Nicole, and hello, Flood amigos! First of all, thank you for inviting me here and letting me share some knowledge and silliness on your video series. As you know, I like to clarify basic topics on which I see confusion here and there, trying to help all of you amigos to understand with those simple examples. And for the ones that know the concept very well, maybe they can use the examples to explain those topics to their management and friends.
So, the topic today is the difference between protocol-based automations and browser-based automations. In other words, Browser vs. Protocol! Those two automations are very different types, especially in the world of performance and load testing. Remember, performance and load testing are not the same thing; they are different. Beware!
Now, let's move on to definitions. In official terms, browser-based testing is an automation that instantiates an actual browser, and actually clicks, types, and scrolls on the application's UI. In other words, browser automation almost physically does those clicks, typing, and scrolling. Actually, some automations even physically do those actions. Most of these actions generate messages that are sent to the central sever, making it work to send a response or the reaction back to the user.
But on the other hand, protocol automation doesn't deal with those buttons, input fields, or scrolls. Protcol automation focuses on the messages that the buttons generate and send to the server. They work by caching those messages, analyzing them, and forging new ones that look so similar to the server that it should not be able to tell the difference.
By now, you may be asking yourselves why there are two different types of automations, and what are the differences. Well, there are more types, but for now, I will just talk about those two, which are the most common ones. To make it easier to understand, I will give you an example or an analogy that I hope will help you better to explain each in detail.
Imagine a fast food restaurant - any of them: the clown's gold arches burgers, the colonel's chicken, the board game pizza, or any of those restaurants that take your order at the cashier and deliver your order afterwards. You probably don't know this, but the way that these restaurants work is with many cashiers using POS, which means Points of Sales. Those POS send those orders through a wire (or wireless) to a printer back in the kitchen, where the server or the cook gets a ticket, takes the order, and prepares your food. Once he is done preparing it, he sends it back to the cashier, who hands it back to you.
In this example, the browser is the POS that the cashier is using, and the protocol equals to the actual messages being sent to the printer, wired or wireless. When you are automating on the browser level, you are more or less creating a programmable robot that clicks on the POS instead of the cashier. As I mentioned, there are even some real software automations that physically click on the POS. Now, on the protocol side, the focus is only on creating the messages send to the kitchen's printer-- not caring about the POS; just sending those messages that the printer will understand and take as real. Well, now that we have the description clear, let's see the differences and reasons for each one of those automations to exist.
The protocol automation, or, in other words, the forging of those messages sent to the printer, tends to be a little bit complicated and difficult. This is because the printer is picking up on specifically those messages. For this, we will require someone skilled to be able to forge those messages. But the advantage here is that once you find a way to forge those messages, it is extremely cheap and easy to generate lots of messages super fast, specifically for load testing. With protocol automations, the mechanisms that can send those messages are cheap, fast, and quite effective.
Now for browser automations, they tend to be easier to automate as they focus on clicking on the POS: simple instructions such as clicking a button or typing a number 4 here or there. But the disadvantage here is that the execution of the automation is a little bit slow and it requires one POS per simulation. That means that if you need 100 orders, you will need 100 POS. Kind of expensive. It consumes lots of space, resources, and its speed is not as fast, because it depends on the POS' speed.
Because of this, the general recommendation is to use protocol automation, or in other words, to be forging and sending messages to the printer, which is fast, cheap, light, and so on. Also, as I mentioned to you, you will need someone really good at forging those messages, or, in other words, scripting. Lastly, these protocol automations tend to be a little bit unstable because they tend to break at the smallest change. As mentioned, the printer is a little bit picky.
Now, back to the browser-based ones. They are not so recommended for load testing. This is because gathering so many POS tends to be expensive and hard to orchestrate at large numbers. But also, they can be really easy to automate. You do not need so much specialization to program that robot or automation. And they tend to be more resilient to changes. One last detail: browser-based automations can be needed when the wire on the printer is shielded and encrypted, or just too complicated to access, analyze, forge, or just insert the messages.
Those are the descriptions - there you have it, my Flood amigos. Those are, in general, the differences and characteristics of each one. I hope that with this example, those will become crystal clear, and that with them, you'll have better weapons to explain them to everybody. As I said, for now, that's all from me. Thank you so much for watching, and, Nicole, thank you for inviting me to share all this knowledge. I look forward to more opportunities to help.
Adios amigos, and for now, Señor Performo out!
Nicole: Muchas gracias, Leandro. I'm so grateful that you could come and share your performance testing expertise with the Flood community. I'm sure we'll see you again, but until next time, happy flooding!