Testing and QA Managers Must Adapt to Automated Processes to Stay Relevant
Testing and QA Managers Must Adapt to Automated Processes to Stay Relevant
Without effective Agile processes and a collaborative, adaptive culture, companies can’t compete well in today’s complex app economy.
Join the DZone community and get the full member experience.Join For Free
Planning to extract out a few microservices from your monolith? Read this free guide to learn the best practice before you get started.
The global economy has reached another tipping point. Hiring is on the rise, companies are growing again -- yet uncertainty prevails due to the threat of market disruption (think Uber and its many variations) and the ongoing threat of geopolitical chaos (think China, Syria and more). Bringing this back down to earth, software organizations need to be especially smart with time and resources while still driving rapid innovation. Without effective Agile processes and a collaborative, adaptive culture, companies can’t compete well in today’s complex app economy. For the enterprise, the challenge is particularly acute. It used to be that small companies wanted to look bigger than they were. But now, the mandate is for big companies to act smaller so they can be nimble and responsive. This means adopting the most effective and flexible processes for development, QA, and testing. Here’s a look at the three core stages for moving to Agile maturity in testing.
1. Build the Foundation for Agile Testing
This starts with building a standardized workflow and set up processes to follow for testing. This involves concepts like understanding when you are ready to test, sharing with team members that a test is completed, showing results and the pertinent data in reports such as a defect summary. Many organizations still don’t have QA requirements mapped out and status standards in place. This is similar to when a company is building out its sales team and processes. You wouldn’t start automating emails and calls until you have defined a sales opportunity, the specific roles on the sales team and how to track progress through the pipeline. A company that’s doing a lot of manual testing but moving toward automated testing may choose to skip standardization and start using a system to track everything. But the management framework is the first step to undertake, no matter where you’re at in the lifecycle of automation. Even with automated testing, teams can always be more efficient. Such management systems track progress in detail from the sprint plan to setting requirements and assigning tasks to the test case to execution and then defect management. Management tools should also be able to customize a process for the needs of your team, as they are set to evolve as your team adapts.
2. Automate and Optimize
Once the management and process framework is in place, it’s time to look at what manual efforts should be replaced with automation, or potentially removed altogether. This allows an organization to add new types of tests, such as load testing and exploratory testing to the existing test bed. Before automating anything, teams should perform an analysis of what that automated process will save your business. Tools, talent and maintenance of automated tests entail costs, of course, so think twice before automating testing for an application that’s not frequently updated or isn’t high priority to the business. Select manual tests for automation based on business priority and customer relevance and determine the overall importance of 100 percent accuracy.
For instance, let’s say a manual test is 95 percent accurate as well as being extremely efficient. That’s great, but what if the test relates to a critical piece of the application such as the purchase checkout process? There’s probably a solid ROI case for making that test 100 percent accurate, through automation. On the flipside, manual testers can add depth to automated testing. Let’s say you have a critical revenue-generating application on your website, such as a loan calculation tool for a bank. Driving 100 percent accuracy might mean putting more bodies on the app for performance testing. The goal during this second stage of optimization is often to reach roughly 80 percent of code coverage through unit test automation, if there is a clear ROI to automating that 80 percent. Keep in mind that this coverage will ideally lead to the more mature concept of test-driven development (TDD), whereby testing is built first into the development process. So the ROI is not just around time saved, but also the new abilities your team will acquire by automating more of their testing. An important goal in stage two is understanding how to do automation well, writing the tests quickly, and assigning roles on your team.
3. Drive Continuous Integration and Extreme Efficiency
At this point, your team has transitioned to employing a mix of manual and automated testing with a leaning toward heavier automation. Now, it’s time to focus on delivering extreme efficiency to every step, and that starts with developing a higher level of collaboration between developers and testers. TDD and behavioral driven development (BDD) are the emerging methodologies to drive this integration and collaboration. TDD and BDD both involve writing the test case prior to the code being developed. The first test will clearly fail because the code is yet to be written, but as the developer writes the code, the tests should increasingly pass and after they do, the developer has the opportunity to refine the code just enough to make it elegant for the user. This is a great way to avoid scope creep and to be more streamlined during development and testing.
BDD applies a plain language, business-oriented approach to testing. A BDD test might read something like this: “Given I am using Internet Explorer 10 on a PC in the U.S., when I click login button to my administrator account, then I should see my current account details.” BDD testing is important because it assures real-world relevance to code passing, with the user top of mind, whereas TDD would focus mostly on a technical unit test that is usually unreadable by a business user.
A critical focus during this stage is speed. It’s not enough that a test is automated - it must be able to run quickly and reliably as well. A test that takes 24 hours to run should be modified, perhaps re-factored into smaller tests and distributed across different servers, so that the overall build process can run in under an hour. With continuous integration (CI) and continuous delivery (CD), the ability to ensure that automated tests are written and applied before code is completed means that new features cost less to maintain and can theoretically be released to the market within hours of them being completed.
Market pressures today are demanding that organizations large and small be nimble and agile to keep up with competition and customer demands. Teams should constantly strive to improve their processes whenever possible and introduce new initiatives that will advance their ability to get value to the market. However, teams need to have the perspective that this is not an overnight transformation, and that there are several key steps that must happen (in order) to become fully realized as a best in class development and testing organization.
Opinions expressed by DZone contributors are their own.