How your Processes Change with Quality Engineering in App Development

As Waterfall continues its slow phase-out, the role of QA has to adapt.   Despite the progress of Agile and DevOps methodologies in software development, there is plenty of evidence that Continuous Quality, Agile Testing, Continuous QA, or as we prefer, the larger-in-scope Quality Engineering, is where many organizations are falling down.

Quality Engineering is a vital piece of the puzzle, which supports both Agile and DevOps.   Let’s take a look at how your mobile app testing processes will change with Quality Engineering.

Testing approach and environment determined at start

The biggest change with QE is when you test.   We know with Waterfall that testing is done at the end of the software development lifecycle.   And many readers will appreciate that with Agile, CI/CD and DevOps, testing is done throughout the process.

That means that testing shifts left, meaning it is done earlier in the development cycle.    Before the very first sprint, there needs to be a collaborative effort between developers and testers (and operations in a DevOps scenario) to agree the test approach and environment.

As a side-note, this may or may not require a formal testing plan.   Some Agile aficionados are less keen on Waterfall-style test plans as it can feel distinctly un-Agile.   Nonetheless, whether you call this a plan or not, there is planning involved at this stage, which will set the parameters for the whole development lifecycle.

Integrated Test Automation throughout

Given the speed of iteration and integration involved in Agile and DevOps, QE needs to put as much focus on Test Automation as possible.

The benefits of Test Automation have been covered at length elsewhere, but in summary it minimizes both the time and costs involved in the software development lifecycle.   It will also increase code accuracy by minimizing human error.

At a minimum, look to automate your code review, unit testing and integration testing.   This will increase the testing speed significantly and allow testers to focus on more creative and human testing.

We have seen that many organizations can comfortably automate as much as 80% of their testing.   Interestingly, many smaller and newer organizations that don’t have a Waterfall legacy to navigate can and do automate more than that.   In a subsequent post, we will cover the human impact of Test Automation and explain what it means for job roles.

Testing early and often

As soon as the feature requirements or stories are decided, the job of testing begins.   With Agile and DevOps, the aim is to reduce code additions to their smallest units possible.   And that means unit testing.   In an Agile scenario, it is the developers themselves that are often responsible for running the unit tests.

Although to many developers this may feel like an annoyance — and they may wonder why they need to test everything so much, the reasoning behind it is sensible.   Finding the small errors now is far more efficient and cost-effective than to have to do code forensics later down the line.   Or worse, deal with the business implications of a faulty app in the wild.

Integration testing is also fundamental here and should ideally be automated, to increase the speed and accuracy of testing.   It is recommended that a Continuous Integration (CI) system be in place to manage this process.

There is no doubt that Quality Engineering will change your testing processes fundamentally — and for the better.   But we don’t underestimate the pain of change in terms of organizational structure, technology and culture.   Find out how we can ease your transition to Quality Engineering by contacting us here.