We all know that industry is moving towards low-code/no-code development model which will drastically reduce the amount of time required to create an application and releasing software will be very fast. However, end-user will be not only satisfied with releasing the product quickly but also with ensuring a quality product. So, comprehensive testing is very crucial in low-code/no-code development. I have already talked about this on a LinkedIn post earlier in 2018.
Being a performance tester, I always think from performance perspective. Application performance is always very crucial for business success. Conducting thorough and different types performance testing is absolutely required for ensuring best end-user experience in terms of speed, scalability, stability, availability, resilience etc. However, traditionally conducting all these requires a certain amount of time. As a result of that leveraging the low-code/no-code model for accelerating the release cycle will be little delayed.
In this blog article, I will talk about browser driven performance testing can assist in accelerating release cycle by conducting performance testing faster and ensuring end-user experiences in low-code/no-code development model.
Browser-driven Performance Testing:
Traditionally performance testing is protocol based. As more and more organizations started using low-code/no-code development, they need a solution where performance testing can be done quickly and maintained easily. In addition, it is essential to measure browser rendering time as modern low-code/no-code model creates heavy rich internet applications- web and mobile.
Browser-driven performance testing is a good alternative as it assists both in:
- Ensuring the goal of accelerated release cycle of low-code/no-code model.
- Knowing the actual end-user experience in browser.
Browser-driven Performance Testing vs Traditional Protocol-driven Performance Testing:
Protocol driven performance testing is built on server-side communication whereas browser driven performance testing is on the client-side communication. Browser rendering time is not included in Protocol based performance testing, but it is included in Browser based performance testing.
In protocol-based performance testing, test script creation requires substantial amount of time (most of the time is spent on correlation i.e. handling dynamically generated server-side values) and good application knowledge as well as technical knowledge. On the other hand, browser performance test scripts are easy to create. Even maintaining browser performance test scripts are quite easy compared to protocol based due to having less complexity.
As browser level performance test scripts can be created easily, takes less time to create and easy maintenance, it perfectly matches with the accelerated delivery concepts of low-code/no-code development models.
Example: industry standard commercial tool LoadRunner browser level solution-TruClient protocol and open source tool JMeter browser level solution- Selenium WebDriver sampler.
Browser-driven Performance Testing- Accurate End-user Experience:
Browser rendering time for HTML or JavaScript are not added in protocol-based performance. Rather, protocol-based performance testing is more focused on server and network level performance. So, protocol driven performance testing don’t provide precise end-user experience.
Whereas browser performance testing using real browser and include rendering page loading time like HTML, JavaScript, CSS timing in performance test results. This rendering time may impact end-user experience. Overall, browser performance testing provides accurate end-user experience over protocol driven performance testing.
Browser-driven Performance Testing- Less scripting effort with more resource:
Browser based performance testing is hugely resource intensive. Each browser instance requires its CPU and memory resources. Consequences of that enormous amount of resources will be required for performance testing. So, more powerful load generator machines or a greater number of load generator machines will be required than traditional protocol performance testing for same number of stipulated user performance test execution. This directly increases the overall performance testing cost.
Yes, application owners know that browser performance testing leads to more infrastructure cost than traditional protocol driven performance testing. However, browser driven performance testing efforts (both creation and maintenance) and time duration are always less than protocol performance testing. This is mainly because of easy and fast performance scripting in browser level performance testing.
Overall objective of low-code/no-code development is accelerated release cycle with ensuring end-user experience. Both can be achieved easily with browser-based performance testing with some additional amount of infrastructure cost. With the advancement of Cloud, infrastructure is now easily available.
Conclusion
In a nutshell, browser driven performance testing can assist in accelerating release cycle by conducting quick performance testing and ensuring end-user experience in low-code/no-code development model.
Check out all the software testing webinars and eBooks here on EuroSTARHuddle.com
