Testing teams can often be unhappy with their existing framework due to daily instabilities in execution, resulting in tests hanging or producing false-positive outcomes, leading to significant manual effort post-execution. In 2018, for example, the Workload Automation test team began to prepare for its 9.5 release the following year. This major release brought about a complete redesign of the primary user interfaces. And, such radical change meant that none of the existing test automation assets was usable and that the effort to re-engineer them was significant. The team evaluated updates to their existing Selenium Robot framework, while also looking at Katalon and HCL OneTest, primarily focusing on effort, ease of use and maintainability as the success criteria. Katalon was carefully considered due to its strong out of the box capabilities. However, the team noticed several problems when creating scripts while finding the maintenance effort to be high. Support provided by the community and even third-party vendors, was not enough to satisfy the business-critical requirement for the automation. Hence, HCL OneTest was selected for a pilot program due to its offering of a codeless solution with the added benefits of simple script maintenance and the ability to leverage API and database actions in test scripts. At the conclusion of the pilot program, there were several key findings, including, intelligent object recognition during playback made scripts resilient to changes and easy to maintain. Additionally, the Workload Test Automation team saw a 35% increase in coverage with new tests, and the ability to bridge front and back end components of the application. Download the Workload Automation case study to see all the key findings and benefits.

You may have seen the term “continuous testing” and thought it was just the DevOps flavor of the month. Some might even think it isn’t part of DevOps or isn’t for cloud or hybrid cloud applications. Well, think again. As it turns out, there are a few more fallacies around the idea of continuous testing floating around the application development community. Here are a few to ponder: Continuous testing is only about executing test scripts Limiting the term “testing” to only the execution of test scripts is a misnomer. As my co-author, Allan Wagner and I point out, testing and checking application functionality are not equal. There’s a long list of testing items to check off one’s list, the least of which is collaborating. Continuous testing is merely a buzzword  Guess what? It’s a core part of that essential DevOps practice, continuous delivery. And, with customers demanding higher quality software faster, it isn’t going anywhere soon. In short, invest in continuous testing. Only agile teams do continuous testing This is false. Some or all parts of continuous testing are critical for any type of team as well as all players. This includes test automation, production-like test environments and realistic test data. A related myth—only testers contribute to testing—is also not true at all. The idea of continuous testing includes all team members. The book describes the roles everybody has to play. For example, did you know that designers can improve testing? They can work with testers to help them understand where the fragile parts of the application are. Automating tests means we need fewer tests No, the machines are not taking over. Automating tests does not mean cutting back on testing jobs. To the contrary, automation is reducing testers’ needs to act like cyborgs and spend more time doing what...

With General Data Protection Regulation (GDPR) and other privacy regulations in effect, replicating existing data from production systems and using it in test environments has become much riskier (especially where personal data is concerned).