For code quality, best practices and tooling come together around testing. There are many approaches to development and testing, but for modern applications and software life cycles, it’s important to have a cadence where development and testing work hand in hand, said Karthik Ravindran, senior director of ALM at Microsoft.
Quality, he said, “is a full life-cycle practice. Every role has a role to play in quality. The QA department can be an enabler of agile, but there need to be quality champions.” He advised that organizations take advantage of the collective muscle of the team to move from quality champions to quality brains and ultimately to quality thought leaders, those who also enable agility.
“We’re strongly of the opinion that quality has always been a top priority of organizations whose businesses depend on software (enterprises, ISVs, service providers),” said Ravindran. “The trend we’ve recognized in such organizations is compromising agility for quality. Today, in an effort to capitalize on the modern business opportunities enabled by software, decision-makers and practitioners are striving hard to strike the tough balance—and this is where the challenge exists—between agility and quality without compromising either.”
Ravindran said Microsoft is seeing businesses and enterprises starting to modernize their software investments and move toward these modern business applications. But in this new world, the end objective is not always known upfront when people start working on these applications. In modern development, he said, “usually there tends to be a build-measure-learn hypothesis where people want to be able to go and do something, kick the tires, test the waters, see how it works, and then decide whether to do more or to do less of a particular investment.
“That’s a pretty different mindset compared to how people tend to approach the classic IT line-of-business type systems, with formal processes of baselining and pre-baselining and really knowing what does ‘done’ mean even before starting the investment.”
Traditional QA does not scale, so it cannot meet the demands imposed by a modern application life cycle based on agile practices and continuous delivery. If anything, it bogs down cycle time and adds costs by not fully engaging all stakeholders throughout development, which can result in a failure to notice that requirements were not met until late in the development phase.
Part of that problem is that while organizations are transitioning their development and project-management teams to agile practices, they’re not doing that as much with testing and IT. “They try to do this and still treat quality as an afterthought, that quality is something which is predominantly the QA function’s accountability,” Ravindran said.
“The QA function kicks into gear after the code is written versus before or after code is being written. The QA function is very specifically focused on the tester, and what the tester does to validate the software, versus the overall quality also includes other aspects like user acceptance testing, system integration testing, stress testing, operations readiness testing. Why we see some organizations fall is where they go agile upstream in things like planning and management, but then they sort of switch off to a waterfall mode when they go downstream into testing. That in turn has a negative side effect on agility as well because what it leads to is late detection of unknowns, late detection of unmet user requirements, late detection of operations readiness, gaps, all of which go back to the phase of planning and development.”
In testing, techniques such as continuous acceptance testing to make sure software meets criteria as it is being developed; continuous validation from other stakeholders; test automation during continuous integration to ensure build quality; and exploratory testing for finding defects can eliminate the post-development logjam and create a culture of building quality into the application throughout its life cycle, Ravindran said.