< Back to Blog

The “Speed to Market vs. Quality” Conundrum

By Jim Chickadel, SVP/Practice Lead, Director of Quality Assurance ~

The “speed to market” mantra that drives business today puts immense pressure on organizations to develop and deploy solutions faster with Quality that customers expect.  Not unlike other nebulous concepts like “operational risk” or “cyber security risk”, Quality Assurance is often not given the import it deserves till something goes wrong.  Only when news reports surface about a bank’s mission critical application failing or when a security breach at a major retailer occurs does Quality receive it’s just due, but by then it’s too late.

Over the last several years IT organizations have adopted the Agile development methodology or variations thereof to speed up the development process.  However, most organizations don’t know how to test in Agile or they continue to test using traditional methods.  This effectively negates the advantages of an Agile development process.

Rather than rethinking how to test in an Agile development environment, a lot of organizations cut corners from a testing perspective in order to meet deadlines.  This is an inherently flawed approach that organizations, particularly in highly regulated industries like Financial Services and Healthcare, can ill afford to take.

The Agile development manifesto and its myriad interpretations have also created a potential challenge for organizations, particularly software development companies.  The Agile manifesto states that it values “people and interactions over process and tools”; and “working software over comprehensive documentation”.  Often this is interpreted to mean loose requirements and little to no documentation of the solution.  Such an approach not only undermines the ability of the organization to test the software comprehensively but also negatively impacts downstream activities like implementation and maintenance.  It also results in an unsustainable reliance on developers to intervene and support every phase of the software development lifecycle.

How to Resolve the Conundrum:  

The approach to resolving the conundrum entails changes in THREE core areas ~

1.  Organization & Culture – Just because an organization wants to move to an Agile methodology may not mean it knows how to achieve this.  Selection of applications and projects should be well thought out and measured for their likelihood for success.  Building momentum one success after another is key.

Agile is more “art” than “science” and it can be molded or customized to reflect the culture of your organization.  Use this as an advantage to make it work for you and not a hindrance to assume that one size fits all.

However, no matter your culture, fundamentally you will need to establish a team made up of software designers, programmers and testers.  While each of these groups have distinctive specialties and tasks, they also need to clearly understand the other’s role; and if required, to contribute by complementing or supplementing a role if necessary for the good of the team.  For most testers this will represent a different way of working, perhaps requiring new skills.  In this setting, the tester is no longer the gate keeper or an independent validator of the functionality, they are an integral part of the software development process.

Two key changes to organization and culture are critical to the success of Agile –

  1. Creating integrated teams, fostering and encouraging daily engagement and partnership between development and QA professionals.
  2. Implementing the tools and practices to transform the group into a learning group. Leveraging learning from prior experiences is critical to making the process more valuable and improving outcomes.

2.  Process & Protocols – Historically testers have relied heavily on requirements that were authored, vetted and approved normally over a long period of time and prior to starting the development of test cases. One drawback to this practice is that often requirements become stale, change and possibly were incorrect or incomplete from the very beginning.

The Agile process handles this by having frequent sprints over short durations so that changes to business requirements or priorities can be addressed and corrected quickly.  This however does not eliminate the need for good requirements or documentation.  There has to be a proper balance in creating just the right amount of documentation in the form of succinct but well defined User Stories along with corresponding Acceptance Criteria.  The Acceptance Criteria is the basis by which testers will build their Test Cases, both from an automated and manual perspective.

The Agile process ensures that testers are engaged in the early stages of software development affording them the opportunity to add value in meaningful ways –

    1. Assisting with the creation of User Stories and ensuring that appropriate Acceptance Criteria exists so that test cases can be developed to adequately test the software.
    2. They provide critical feedback to the team as to the stability, reliability and of course quality of the product being developed.
    3. Although they are considered an integral part of the Development Team, they must also bring a perspective and advocacy for the end user or Product Owner to ensure the software delivered is – “fit for use”.
Speed to Market vs. Quality

3.  Automation & Tools – Test automation is critical to the success of software development agility. This is especially true in the case of larger and more complex applications.  It would be somewhat unrealistic to assume that even a reasonable number of manual testers have enough velocity to conduct functional and regression testing on mission critical systems supporting sprints of short durations.  This is where test automation can provide the speed and repeatability necessary to enable Agile to truly deliver quality along with an acceptable ROI for your automation investment.  However, achieving an acceptable ROI can be challenging.

  • Traditional test automation has usually required a significant investment in testing software, training and on-going maintenance expenses.  You could pursue a slightly less expensive “open source” tools option but these too require highly technical testing resources and doesn’t relieve the burden of on-going maintenance.

Choosing a Test Automation strategy is critical and could spell the success or failure of your Agile undertaking.  Before picking an approach it would be worth the effort to explore alternative solutions like “Model Based and script-less” test automation.  These types of solutions have been gaining popularity because less expensive manual testing resources can quickly become automation specialists and the effort to maintain automation assets can be significantly reduced.

In Conclusion…

What moving to Agile Does Not Mean for QA –

  • Little or no feature and test documentation.
  • Sprint feature specific testing only with less emphasis on System Integration testing.
  • Ad-hoc testing with “best possible” coverage.
  • Being just an extension of development team.
  • Losing the user perspective of the product.
  • Freedom from ownership of Quality of the product.
  • Any test automation solution will work.

What moving to Agile Does Mean for QA –

  • Participate in ownership of product quality.
  • Ensure appropriate amount of feature and test documentation.
  • A team of equals. Quality is the team’s responsibility.
  • Leverage informed Users or Product representatives to help guide all phases of quality.
  • QA team must be more adaptive rather than prescriptive.

To learn more about our QA Practice Director, Jim Chickadel… click here