Solidify Your Shift-Left Commitment With Applause In-Sprint Testing

Dan Cagen Dan Cagen
Reading time: minutes

Rapidly test smaller chunks of code and take pressure off your internal teams

If you’re involved in the software development lifecycle, you’re probably well aware of the importance of shifting your testing to the left by now. But how do you actually test smaller chunks of work rapidly and earlier in the SDLC without wearing out your internal teams?

Your developers and testers are highly skilled and sought after, and their time is probably better spent on tasks more suited to their skill-set rather than repeatedly testing new code.

According to our survey of 1,849 product development and QA professionals conducted earlier this month, 44% of development teams from large companies that test earlier in the SDLC spend at least eight hours per week testing new features. If this seems like a major time commitment, it is — 52% of respondents said that this 8-hour time commitment impacts their developers’ productivity.

This is why we’ve created Applause In-Sprint Testing, built specifically for mature and fast-moving development and deployment teams that frequently release updates. An integrated and streamlined offering that establishes a repeatable process for early feature testing, Applause In-Sprint Testing is a crucial part of Applause’s holistic Product Excellence Platform.

We recognize that testing earlier and in smaller chunks is crucial for you to fail fast and release rapidly and more often. Here's how Applause In-Sprint Testing can become your shift-left partner.

Feature testing mid-sprint

When your developer has completed coding a feature, a shift-left testing approach dictates that feature testing be done immediately (i.e., well before the code is merged into the master branch), increasing your ability to fail fast, identify defects quickly and ultimately lower costs.

With Applause In-Sprint Testing, the developer sends the feature directly to Applause’s SaaS platform with the click of a button. Changing the status of the Jira story will — through bidirectional integrations with your Jira bug tracking system and Applause’s SaaS platform — send it to Applause. This automatically creates a test case designed to validate the core feature functions based on the information included in the Jira user story. The test case can cover a set of defined steps or include time-boxed exploratory testing.

From there, a pre-built team of top-notch testers sourced from Applause’s global community immediately begins test case execution. With the testing team on standby, there is no delay from when your developer changes the ticket status to when the team is activated and testing starts.

The testers, all of whom will have intimate knowledge of your products and unique testing requirements, will pass or fail the test case. If issues arise, they will provide screenshots, screen recordings, logs and other relevant information, making it easy for your developers to reproduce and address the issue(s).

The results are sent directly back to your Jira system with a new status reflecting whether the feature is ready to progress to the next stage or has issues that require further examination.

This whole process — from your developer changing the status to the test case results appearing back in your Jira system — takes just a few hours, ensuring that your developers get immediate test results and don’t suffer from context switching.

Easing your shift-left testing commitment

It might not seem like a big deal to have your developer or QA professional manually test the functionality of a new feature right after it’s coded; after all, shift-left testing creates inherently smaller chunks of work compared to testing a finished build. But in the aggregate, those tests — which must be conducted manually at least once before test automation can be applied — add a significant time commitment for your teams and take them away from strategic tasks and other projects, and is likely not a scalable solution if you’re constantly developing new features and need frequent mid-sprint testing.

When you test features early with solely your internal resources, it places additional burdens on teams that are already stretched thin. Asking an already busy software development team to take on yet more work probably will not go down well, and can even create fear and resentment.

Applause In-Sprint Testing augments internal teams to take this work off their backs while still ensuring you test smaller chunks of code quickly before a feature gets added into the main branch.

From a technical perspective, Applause In-Sprint Testing is a streamlined process built directly into your existing workflows, meaning you never need to leverage other tools or communicate via email or Slack. Since you’ll only need to change the status of the Jira ticket, and then await a status update when the testing is complete, you won’t even feel like you’re working with a third party — which is just how we like it at Applause.

Check out our infographic to see how Applause In-Sprint Testing fits into your workflows.

You might also be interested in: