Select Page

Why Brands Should Shift Feedback Left

Test early. Test often. This is the mantra many brands are reciting today as they insert testing earlier into the software development lifecycle (SDLC) – a practice known as shifting feedback left.

Shifting feedback left is a reaction to the problems companies face in more traditional feedback systems. In a traditional feedback system, options are limited. A company can develop partial functionality, limiting the testers on what they can test, in order to complete software development. Another option in a traditional feedback system is to have developers complete iterative milestone builds which then go to General Availability (GA) testing. In these setups, work isn’t tested 100% for months because testers are waiting for development to finish. Once development is completed, testers face an uphill battle and a lot of testing to do. Regression testing often suffers the most as testers turn their attention to the newest software features.

Companies that don’t have a dedicated QA department are especially susceptible to software bugs. These brands are forced to pull people from all parts of their companies to test software. Developers, engineers, marketers, and others are drawn away from their work to focus on projects they’re not necessarily qualified for.

This is a recipe for disaster.

Issues escape the eyes of these ad hoc testers, leaving customers to wonder why they are finding bugs on the first day software is released. Customers may even abandon the product immediately because of a poor software experience. Without the right resources, the necessary time, or the structure in place to really address testing needs, brands are limiting the odds of their software being successful.

Lacking resources and testing challenges exist across all industries and company types, but are most prevalent in emerging companies. Startups don’t always have the money to spend on a dedicated QA hire. They also don’t always have the need. With testers waiting for development to finish before they can get to work, a dedicated QA professional at an emerging company tests once every nine weeks or so, and then waits for the next release to come around. This isn’t an efficient use of time or money.

The answer for companies looking to accelerate efficiency and time to market is to take a more agile approach. Introducing testing earlier into the SDLC is a way to increase agility. The sooner testing is introduced, the sooner development teams can receive feedback. There are a few key things companies need to do before they can commit to shifting feedback left.

First, companies need a game plan. They need to run sprint cycles with enough quality software to test every two to three weeks. There needs to be a substantial amount of software within the sprint cycle to actually make it worthwhile to test.

Next (and most important), brands have to invest in dedicated testers – not just rely on other job functions. A company can’t constantly pull away team members from the essential tasks of their day-to-day jobs to focus on testing software. That will quickly spiral out of control and make the company less efficient, while not actually catching all of the software issues.

Cost savings and efficiency are at the top of every company’s wish list. Augmenting regression testing and feature testing with crowdtesting services like Applause can help. We’re an extension of clients’ teams, ready to test at a moment’s notice to enable clients to test early and test often.

Dean Vittum
Dean Vittum
Director of QA
Published On: September 22, 2017
Reading Time: 3 min

What is the Software Testing Life Cycle? STLC Phases Explained

Just as the SDLC is a sequential development process, the software testing life cycle includes distinct phases

Why Velocity Needs Vision in AI-Driven Quality

Learn why Applause CEO Aatish Salvi says the key is to merge AI testing with human validation to avoid mediocrity.

What Is a Hotfix? Software Patches Explained

Use hotfixes in moderation only

Learn These Key Functional Testing Types and Programs

Requirements for a multi-faceted approach to software quality

Training Data vs. Validation Data vs. Test Data for ML Algorithms

Learn the difference between these ML datasets

Key Considerations for Using LLM-as-Judge

Discover how to reduce risk when using models to evaluate AI systems and how to effectively use LLM-as-Judge.
No results found.