What It Means to QA Your App Today

Past application testing centered around making sure code was right, and that all features and functions were being executed properly. However, in today’s Agile development, organizations might be just as inclined to assess quality in terms of active user participation and fast turnaround, instead of just verifying that all features and functions are working correctly.

Just what are the objectives of “quality” in today’s application development, and does this change IT’s approach to quality assurance?

The Impact of Agile

Since the Manifesto for Agile Software Development was originated in 2001, companies and industries have moved to Agile development because of its promise to speed an application's time to market. At the start of 2023, 71% of organizations were using or implementing Agile, and they reported an Agile application success rate of 64%. Compare that with a 49% success rate from traditional waterfall applications. Success was defined as time to market (71% of respondents) and ability to adjust to changing priorities (63%). Quality was listed as a key success factor by only 49% of respondents.  

If you’re a QA manager, or an IT director or CIO who has overall responsibility for QA, what this tells you is that app quality is still important, but maybe less so, if it obstructs time to market or the ability to rapidly adjust applications to changing business conditions. In this environment, it is difficult for QA to repeatedly “fail” an application for minor bugs when it is possible that these bugs can be endured if people can at least start using the app.

This is a QA sea change that is forcing QA professionals to regroup.

Quality Assurance with Agile

The most common type of Agile methodology is Scrum. Scrum depends upon an interdisciplinary group of users, developers, QA, etc., who collectively work and collaborate on the development of an Agile app. Project deliverables and testing are developed incrementally in the form of Scrum sprints, which are time-defined events designed to deliver just a portion or an increment of a project or app. The purpose of each sprint is to incrementally build out or improve an app so it can be delivered faster rather than at the end of many months of numerous bundled enhancements that delay its arrival.

Time to market is the advantage here, but you potentially sacrifice obtaining the full application that you ultimately want. So there is give and take.

For QA, the development and testing of Agile applications is iterative, as it is in artificial intelligence and analytics. The view of an app is that it is never really ever “done.” It is evolutionary and will change with the business.

QA Best Practices

Know your users. There are several Agile development methodologies, and they can define how QA works with Agile, but the most important thing you can do is to gain a solid understanding of how your users, developers, and fellow collaborators like to work.

Some companies have “hands off” users who don’t want to be constantly burdened with testing apps, while other companies have enthusiastic users who are always there when you need them.

Depending on the types of users and developers you have, you can create Agile sprints that are short and therefore frequently tested; or of longer duration to where they require testing (and participation) less often. In this way, you can calibrate the number of times that Agile apps are tested to the profiles of the users and development groups you are working with.

The QA application testing cycle also needs to change. In waterfall application  development, QA is  a one-time final checkout before an app goes  live. With Agile, QA testing is continuous, from the time an app is conceived and designed, through app development and deployment. Users, developers, and QA work synchronously -- with the understanding that the app (and the need for re-testing) could become a daily exercise.

In Agile, as with waterfall development, both white and black box testing must be done. Back box testing is app testing done from the user’s perspective. In other words, does the app’s graphical user interface (GUI) and navigation work right? Are you getting all of the information that you wanted from the app?

White box testing goes deeper. It is the realm of the developers (and also QA’s). For instance, it looks at whether the app passing is all of the necessary data and parameters to other systems and apps in the IT infrastructure? It examines whether end-to-end security is in place?

One of Agile’s vulnerabilities is that users may tend to sign off -- and pressure for app deployment -- if the app on its face simply looks right. But this doesn’t mean than the app is fully integrated with other IT systems.

Insisting on full integration testing of Agile apps is something that QA should do.

Automate regression testing. Just because you’re using Agile it doesn’t mean that you skip regression testing, which ensures that the new app created can run in your production environment without diminishing its performance or bringing other systems down. The good news is that there is QA automation software that can perform regression testing and reduce regression testing timeframes. This keeps Agile  test cycles compact, and that makes users happy.

What to Read Next:

Chase CIO Gill Haus Discusses Recruitment, Agile, and Automation

How DevOps Teams Can Help Create Top Agile Teams

DevOps or DevOops?