QAOps solves the most common disputes that persist between the testing team and Quality Assurance teams. Problems where testers “expect” the issue to have been solved by the QA team and vice versa are completely eliminated through the QAOps practice. QAOps brings in cooperation among the different departments of the organization. QAOps makes use of the following high-level testing practices to put the concept of QAOps into action –
1. Automated Testing
This is one of the main pillars of the QAOps framework. Automation testing means performing tests with the help of technology and tools, and very minimal human effort. QA engineers must study the product in detail and understand the specifications before building the automation framework. Depending on the product and the actual stage of development, QA engineers can decide which tests can be automated successfully to help save time and test the functionalities in a more effective way.
The most obvious types of testing to automate are going to be your regression test cases. They consume the quality time of the testers which can be effectively used to build automation test cases. Similarly, frequently used functionality in the product should also be automated. Why? As your product grows in functionality and features, you don’t want your most-used functions to fail and create a bad experience for the users!
Let us consider a user story to understand this better. Andrew, a web tester who is primarily tasked to ensure browser compatibility of the web-application. Andrew being in the testing domain realizes how time-consuming manual cross browser testing can turn out to be. Testing a web-application or a webpage over hundreds of browsers + OS combinations one by one can consume a significant amount of his time and his bandwidth in a release window.
Not to mention, testing the same dozens or hundreds of browsers + OS combinations is bound to get monotonous and dull for Andrew after a while. Andrew also realizes that if he devotes all of his time in performing manual browser compatibility testing over the same test script and combinations, every week, then finding unique test cases would be a little too much to expect. So what can Andrew do?
This is exactly where automated cross browser testing can come to his aid. With open-source frameworks like Selenium, automation testing can become a lifeline for Andrew to complete his test cycles on-schedule. However, Andrew would still need to figure out which test cases to automate as he cannot automate everything.
Automation testing from scratch will require a thorough phase of planning and documentation. However, once that phase gets over and Andrew has got the right test suites at his disposal, along with the right automated cross browser testing tool then the road ahead is going to be very pleasant.
2. Parallel Testing
As part of the QAOps framework, testing should run quickly (in parallel with the delivery pipeline). Slowing down the testing efforts will directly affect the delivery process. Running automated tests will definitely speed up the testing process, but not when they are being executed run in a serial manner. To overcome this issue, it’s important for testing engineers to run multiple tests at once (together) rather than running them one after the other.
Let’s continue with the story of Andrew that we considered in the example of automated cross browser testing.
Realizing the perks of automation testing over manual cross browser testing, Andrew came up with multiple automation test scripts to cover different modules of his web application. However, there came another issue that he wasn’t ready for! Andrew used Selenium WebDriver to automate his test scenarios for browser compatibility. Selenium WebDriver would only execute one test at a time and will queue the others. As a consequence, Andrew noticed that the test cycles are still going to get delayed due to serial execution of test scripts.
Now, he implemented his test suite over a Selenium Grid to leverage parallel testing with Selenium. Using Selenium Grid capabilities Andrew was able to run multiple test cases, simultaneously. This reduced his overall test execution by multiple folds allowing him to complete his test requirements on time.
Parallel testing requires larger hardware and infrastructure with more CPUs to run the tests simultaneously. But, the benefits of getting results quickly without disturbing the delivery pipeline is definitely worth the investment in a few CPUs when compared to revenue losses due to delayed product delivery. In modern-day technology, businesses can take advantage of cloud-based cross browser testing tools such as LambdaTest which provides a scalable infrastructure to perform parallel testing.
3. Test Scalability
Once you go-live with your web-application, you collect feedback from your customers, work on suggestions, consider incorporating new features in your upcoming sprints. After every release cycle, your web-application continues to scale, and with it scales the testing requirements! As for every new migration that is committed from CI/CD pipeline, the ripple effect of new code changes over an already running code has to be calculated and validated. So when it comes to infrastructure investment, you need to keep the Scalability testing in your checklist.
That is not all that Scalability is about! Scalability testing also helps to determine the application performance at various conditions by modifying the testing loads. The results of the test show the application’s response to differential loads. The testing routine should be scalable with the CI/CD pipeline. At times, the CI/CD pipeline scales up and down depending on the project requirements. During these times, the testing should also be in sync with the CI/CD pipeline. Scalability testing helps QA engineers to reveal the performance-related challenges of web applications.
As a standard QAOps practice, QA teams must have the scalable infrastructure to perform testing and increase the speed of tests when needed.
Let us wander upon what Andrew did to overcome the issues around scalability?
As Andrew’s web application added more and more features to itself. The cross browser testing checklist also expanded for him as there were now few features which were configured using CSS Subgrid or other newly introduced CSS properties which were not widely accepted by the majority of browsers.
As a workaround, developers had set fallbacks for these problems and Andrew’s responsibility was to make sure that these new applied workarounds are working well with the existing application.
He had to consider scaling up his Selenium Grid to test on more legacy and latest browsers, browser versions, operating systems for both Windows and macOS, also for Android and iOS. Turns out if he keeps on adding these devices to his in-house Selenium Grid infrastructure, he may end up having a huge bill on his manager’s desk. Working in a small scale enterprise he cannot go for cloud-based device labs or infrastructure providers such as RackSpace, or AWS device farm. So what can he do?
He looked out for more options and landed on LambdaTest, which offered him an online Selenium Grid that can scale as per his requirements. He was able to eliminate the hassle of maintaining his in-house infrastructure now, as LambdaTest provided him with machines hosted on-cloud, ready to fire up with a click of his mouse. The best part about LambdaTest Selenium Grid was that not only was it offering the legacy browser versions, it was also updated with the latest browser versions. This saved him time, effort, and the headache that comes with maintaining a Selenium Grid of his own.