The Changing Role of Software Testing in an Agile Environment

Brad Boemmel, Director of Quality Assurance, Morningstar, Inc. [NASDAQ: MORN]

Brad Boemmel, Director of Quality Assurance, Morningstar, Inc. [NASDAQ: MORN]

The agile software development lifecycle was designed primarily by and for developers; it was not created to optimize quality assurance (QA). Software testing remains an integral piece of the overall development life cycle and the last 15 years have been spent finding ways to incorporate it based on this new shift to agile in the industry. While the proliferation of automated testing techniques has helped this transition, shifting roles are a key reason high-performing teams have succeeded. A typical agile squad may be constructed with three to five developers, a product owner, a scrum master, and a single QA engineer. There has been a shift away from pools of quality analysts—and for good reason. A major tenant of the agile software methodology is cross-functionality of roles across the team. Singular roles such as automated tester or manual testing analyst are going against the grain of the team. Developing in an agile mindset provides increasingly responsive feedback and having a separate automation team creates a mini-waterfall team within the delivery squad. Instead, there is a need for the full-stack QA engineer, an individual with a technical language set along with subject matter expertise, who can be the champion for quality across the entire squad. Everyone Tests As the team makeup matures to more cross-functional roles, everyone becomes a tester. The testing focus for each individual is more directed to his or her core skillset. A developer takes over the task of functional testing along with simple requirement verification. The best time to accomplish this is at the point closest to the requirements. Unit testing with methodologies such as Test-Driven Development or Behavior-Driven Development can ensure that it is completed within the sprint. The product owner can bookend the testing effort with some final usability testing needed to sign off on any new changes. The role of the QA engineer shifts into more value-added testing. With the basics of functional testing verified earlier, QA is free to focus on testing that is further away from the single module being developed.

The agile development lifecycle has tremendous benefits to code delivery

The primary concern of the QA engineer becomes negative, edge case, integration, and exploratory testing. Non-functional testing such as performance, security, and load testing do not disappear in the new paradigm. In a waterfall world, these functions could be batched up during the eight-week testing cycle and handed over to a separate team. The full stack QA engineer inherits this role and works with the team to accomplish this same task within the sprint window. The Technical Role of QA The additional work load magnifies the need for the QA engineer to have a technical or coding background. This merges with the requirement to become more crossfunctional. A technical resource can talk the same language as the development team. A clear flow of testing from the unit to service, to integration, and finally to the usability layer is needed to remove duplication of efforts. Finding a functional bug in the integration or usability layer is a costly tax on the team as it occurs farther away from when the code was written. Debugging this issue can require more time and resources. In addition to testing tasks, the QA resource can be responsible for some traditional development tasks, such as the creation of test harnesses. The increase in individual responsibilities coupled with the decrease in the testing timeline creates a need for ways to reduce what is being tested. One method is to incorporate Risk-Based Testing. The ability to prioritize test cases based on impact and probability of failure can give a transparent view of what is tested,and more importantly, what is not being tested. This works within the team construct and allows the entire team to provide risk feedback rather than keeping that task completely within the quality team. The Voice of QA Along with a change in role and activities, there is also a change in mindset. The QA engineer needs to have a vision within the squad. The small size of the squad amplifies the voice of each individual member. If the champion of quality is silent, it becomes very noticeable. This is a collaborative environment, and non-participants can become overpowered. It becomes the role of the QA manager to help facilitate this voice. Gone are the volumes of bug burn down charts and weekly status updates. In the world of weekly sprints, a report of the defects from two weeks ago has little to no value. If there is no action that the team can take based on a metric, it is not only useless but counterproductive. Empowerment of the QA team to bring up concerns and drive the continuous improvement of the entire squad is more important than driving a task-based culture. The agile development life cycle has tremendous benefits to code delivery. It provides more input for development and quicker turnaround for the business. It may have started as a trend in the industry, but it is not going away. The quality assurance world will be required to adapt by ceding absolute authority of testing because the controlled testing cycle no longer exists. Quality assurance professionals will take control of their destiny and establish an agile culture of quality by shifting to a more technical focus, demonstrating an ownership mentality and strong voice within their organization, and driving a system of quality throughout their cross-functional teams.