Skip to content
  • Services
    Our Approach
    Personalized, in-depth technical guidance on a global scale that helps organizations achieve their digital transformation goals.
    Learn more
    • Our Approach
    • Development
    • Design
    • Digital Experience Platform
    • Data & Analytics
    • Cloud & DevOps
    • Support
  • Work
    Our Work
    Through our expertise in strategy, design, and engineering, we help clients deliver digital transformation at scale.
    Learn more
    • Our Work
    • Healthcare
    • Finance
    • Manufacturing
    • Agriculture
    • Education
  • About
    About us
    For over 20 years, we’ve partnered with companies of all sizes and industries to solve their most complex business problems.
    Learn more
    • About us
    • Leadership
    • Locations
    • Events
    • News
  • Careers
    Join our Team
    Take your career to the next level. We offer exciting opportunities across every stage of the software development life cycle.
    Learn more
    • Join our Team
    • Open Positions
    • Application Process
    • Benefits
    • Learning & Development
  • Insights
    Our Insights
    Read our latest blogs, watch our recent videos, and browse our library of e-books — all full of insights from our experts.
    Learn more
    • Our Insights
    • Blog
    • Videos
    • Downloads
  • Contact
Menu

Avoiding Exploding Defects with Agile Testing Methodology

Why turning your back on Agile testing methodology is one of the biggest mistakes you can make when maintaining quality for your solution.

Craig Knighton

Chief Operating Officer

Imagine this scenario. It’s two weeks until the scheduled release of your solution. For the first time, software testers are allowed to examine the code — putting a magnifying glass to three months of hard work by your development team. They find 10 major bugs threatening the viability of the release. Then they begin testing the interactions of those defective features.

Top QA Strategies

Analyzing the current state of software testing and how teams must adapt.

A Case of Exploding Defects

The issues multiply by five. As new code is released to fix the bugs, problems with interactions continue until eventually you have 150 bugs driving the go/no-go decision one week from launch. And — every day the business is asking you whether the release is threatened.

That’s a cruel punishment we wouldn’t inflict on our worst enemy. It’s unruly, stressful — testing the bond of any tight-knit project team. The good news? It’s avoidable.

But the reality is even today too many businesses find themselves mired in the case of exploding defects. The reason harkens back to the very history of software development and testing.

“Don’t Go Chasing Waterfalls”

Back in the early days of software development, the Waterfall software development methodology was as catching as TLC’s 1994 hit song. Requirements were captured at once, designed and built. In a process as new as building software, enterprise stakeholders wanted all details to be documented and configured before construction began.

Waterfall software methodology

In this era before Agile testing methodology, project owners and product teams operated under the assumption that software testing was only necessary after development was completed. Testers’ role? To validate that the features functioned as outlined in the original requirements document. Anything different was by definition a defect.

Software is a rapidly evolving marketplace of ideas. The problem with testing in Waterfall development? It didn’t leave room to adapt.

Even if the project requirements changed throughout the course of development, testers were kept in the dark. They were still comparing against the detailed requirements list. Any nuances or adjustments decided by the team during development but not documented, lay outside the testers’ purview.

Let’s be honest. Throughout the development lifecycle, product owners don’t hold fast to the first documented conception of their product. Needs change. And so do expectations. Software testers brought in at the tail end of a project were kept in the dark, left to compare the feature list planned for development and the features represented in the finished app or platform wondering, “Is this a defect or an intentional change?” The time it took them to chase down the answers they needed ate up time and budget.

Industrial Roots of Software Development

The decision to involve testers at the end of the development lifecycle evolved from the process used to manufacture physical goods. In manufacturing, electrical or mechanical engineers would design the process to a build widget — take a smoke detector for example.

Once the smoke detector was built, it was checked for quality. Testers weren’t involved along the way. There was no need. Their only purpose was validating the functionality of the device — not informing the build.

There’s a huge difference between building a smoke detector and building an app. Software isn’t built using plastic and metal. It’s structured with ideas. As fast as an opinion changes, so too can the output of software development. Along the way there are opportunities for logical oversights and a need for validation throughout the process.

Software can also be released far more frequently than changing the manufacturing line of smoke detector production. Applying the same constraints used in the physical world no longer made sense. Only this industrial process needed more than a revolution to improve inefficiencies in software testing.

In the ’90s, the sequence of quality assessment changed. Statistical Process Control (SPC) came into vogue. Following SPC, meant verifying the process was in control and capable
at all times i.e. measure during the process rather than at the end. This mentality, while identical to the new approach to Agile software testing, preceded it by nearly a decade.

Along Came Agile Testing Methodology

But rather than continuing to develop, pass code over the metaphorical “wall” to testers and wait for a defect report to be sent back as if by carrier pigeon, Agile methodology helped reimagine this antiquated development methodology.

Agile testing methodology allocates testers at the beginning of the project as members of the core project team. That way, changing ideas can be tracked and features tested as they roll off the “assembly line.” In Agile, testing occurs during each two-week sprint rather than posthumously, after development is completed.

How to Build a QA Test Strategy

Analyzing the current state of software testing and how teams must adapt.

The Agile testing methodology process acknowledges that the needs of the enterprise are constantly shifting during the ideation and build process. Pushing the pause button on business is a happy, albeit unrealistic, hope during software development. The reality is: Business development and learnings don’t stop when software development starts. Minds change. Requirements are adapted.

Product teams and testers needed a new way to serve to the needs of businesses. Agile values shipping code over the extensive documentation that defined the old process. By documenting less, developers can do more.

Agile testing methodology comparison

Diffusing a Runaway Defect Reaction

As illustrated in our exploding defects example, the ROI of testing throughout the process changes dramatically in Agile development. New features are implemented in every sprint. A very important part of ensuring software quality throughout the process is the re-testing of existing functional and nonfunctional areas of a system after new implementations, enhancements, patches or configuration changes. The purpose? To validate these changes have not introduced new defects. Those familiar with software development know this as regression testing. As if you need any other reasons to move testing further forward in the Agile lifecycle. Here are six.

1. A red rope mentality. Moving software testing forward in the process gives quality testers a “red rope to pull” in challenging the development team should they identify logical oversights occurring during the build.

2. Leverage experience. Passive validation on the back-end of the project doesn’t leverage the vast experience and intuition of testers.

3. Aerial perspective. The difficulty validating software exponentially increases if they aren’t able to track and understand the changes to initial requirements being made along the way.

4. Testers as users. Your testers are capable of more than just rote checks. They are the first users of your solution. Incorporating this experiential feedback at the beginning of the lifecycle allows functionality to be adjusted along the way (if it lands in scope).

5. Two words: Accumulated bugs. Therein lies an increased risk for defects if testers aren’t working in concert with developers and checking interactions with existing functionality as new features are developed.

6. High-level documentation. If software testers are involved throughout the development cycle, test cases can be documented at a high level. The alternative? Developers documenting in detail the needs for QAs operating with no relative context.

Tags
  • Agile Software Process
  • Quality Assurance
  • Development
  • Staff Augmentation
Share
  • Share on Facebook
  • Share on LinkedIn
  • Share on Twitter
Share
  • Share on Facebook
  • Share on LinkedIn
  • Share on Twitter
Sign up for our monthly newsletter.
Sign up for our monthly newsletter.

Read what's next.

Blog

Embrace Psychological Safety in the Workplace

Blog

7 Quick Process Improvement Ideas to Scale Teams

  • Twitter
  • LinkedIn
  • Instagram
  • Facebook
United States
MentorMate1350 Lagoon Ave, Suite 800
Minneapolis
, MN 55408

+1 612 823 4000
Bulgaria
67 Prof. Tsvetan Lazarov Blvd.
Sofia 1592, Bulgaria,
+359 2 862 2632
Sweden
Drottninggatan 29
411 14 Göteborg

+46 3 199 0180
Paraguay
Carlos M. Gimenez 4855
Asunción, Paraguay

+595 21 327 9463

Copyright © 2023 MentorMate, Inc.

  • Cookies
  • Privacy
  • Terms
  • Continuity Policy
This site is registered on wpml.org as a development site.