3 Common QA Challenges

In software testing, there are many QA challenges. With so many different types of software applications out there, there are numerous issues to be overcome by every QA (Quality Assurance) team. Let’s talk about a few of the common situations faced by just about every software tester, and take a look at some solutions that can help improve the quality of your product.

Challenge #1: Keeping up with Requirements

Requirements can change quite rapidly for a lot of software development teams. Testers must be prepared to adapt to those changes and know what to expect when a build becomes ready for testing. Keeping up to speed requires having a plan for updating test cases and testing the right scenarios.

Should you update the test cases immediately after receiving the updated requirements? Which test cases will need to be updated? Do you need to update for regression tests? What is the process for notifying the QA team of requirement changes?  – All these questions can be answered by defining a process for updating documentation.

Ideally, the development team should have a plan in place for evaluating the updates and taking action. Sometimes requirements change at the 11th hour, and testing must be executed quickly to meet a deliverable. In these cases, QA must be flexible yet steadfast in the test documentation. Assigning scheduled time for regular test updates is the key to staying on top in this area. This scheduled time could be based on Sprint work within an Agile environment where each user story is considered for a test update. Another method could be to update tests for each release.

The frequency and cadence of the test updates could vary depending on the product and the development life cycle. Once a plan is in place for scheduled test case updates and maintenance, it is essential to stick with it because obsolete test cases become a significant hindrance. They result in slower test execution, cause bugs to be missed entirely and can ultimately be the reason software fails to meet the latest expectations.

Challenge #2: Balancing Sprint Work with Releases

Testing software in an Agile development framework brings several challenges to the QA side of things and the role of QA in an agile team may differ when compared with other project management methodologies. One of the benefits of testing in Agile is the chance to look at changes early and often, which means the software should be ready for the QA team to test more quickly after the requirements are created or updated. This quick turnaround gives the QA team a chance to catch issues early and provide the team with feedback straight away. The challenge can be keeping up with sprint work while accommodating regression testing for a release.

The work done within a sprint is typically a different set of tasks than those required to regression test and certify a release. QA must, at times, devote resources to releasing testing and sacrifice time from sprint work. Sprint work is the development and testing that occurs (usually in a development environment) within a given time frame. In agile a sprint can last anywhere from 1 to 3 weeks. If some of the sprint work is being done for a release down the road and QA is testing for an immediate release, then the attention given to the sprint may lessen.

The key finding a balance lies in process and planning. A proper backlog of testing tasks should be maintained, so as not to lose track of time missed while testing a particular change or set of changes. The QA team should communicate the workload that is required and point out any areas where there are gaps in testing. Likewise, the software team should be ready to adjust schedules and resources to account for these issues.

Often, QA will need to put in extra hours to accommodate regular sprint work AND a release. In the end, proper scheduling and communication should alleviate the need for testing overtime or leaving gaps in testing.

Challenge #3: Deciding Where to Test

Deciding where to test might not seem like a common challenge, but think about the previous issue we addressed – balancing release testing and sprint (development) testing. Release testing is generally performed in an environment separate from sprint work. So, the “where” in that case, is the build and the environment.

Often, there are multiple testing environments such as development, QA, staging, and production. The production environment is generally reserved for the production users, but it must be available for testing as well. The staging environment is typically setup to be the most similar to production, so testing here is reserved for making that final verification before going live. The dev and QA environments are setup differently but are both primarily used for testing.

The “where” includes the environment, the build (the software built with particular changes) and the client (such as the device, the OS of the device, the version of the browser, etc.) There can be more variables when you have multiple “environments” that an app or website hits to retrieve data to display to the end user. So, a mobile app, for example, could hit a development server for one functional area and a production server for another. The setup of the environment is the “where” in many cases.

The keys to this challenge are an evaluation of priorities, assessment of risk and an understanding of the environments. Ideally, QA can follow the changes through the development cycle and test them at every point along the way. In the real world, there are days where a decision must be made to test the upcoming release candidate build instead of the build in development. A plan should be formulated with the development team to understand the risks and priorities. The environment setup is crucial when you are testing a client. If the environment isn’t setup for the function under test, you will end up missing bugs, reporting invalid bugs or be unable to test in that environment.

Conclusion

There’s a common theme when it comes to finding solutions for these challenges, and it’s process planning and communication. Make plans for handling documentation and make sure they are organized and kept up to date. Communicate with the developers, the project team and the release engineers. These are the kind of challenges that QA faces on a regular basis. Get used to solving these, then get ready for the next challenge.