How to define your testing scope

Development and quality assurance teams are under strict deadlines to send out deliverables and complete other tasks within a sprint. As these timeframes continue to tighten, it’s important for teams to effectively use agile testing methodologies to keep up with all requirements. Teams must realize that a significant amount of available time will go toward creating features, and that there isn’t going to be infinite space for QA processes.

With limited time, establishing your testing scope will be critical. While you do still need to be ready for any potential changes that may come, it’s also important to have a testing scope strategy in place to ensure that everyone’s on the same page. Here are a few tips on how to define your testing scope:

  1. Understand what features are being tested

There are often situations where teams will go overboard and preemptively create test cases that may not provide any value to the project. Instead, it’s critical that QA professionals stick to what features are being tested. TechTarget contributor Mike Kelly noted that teams should focus on features that are most intensive, frequently used, required to work by law, support business-critical processes, interact with risky aspects of a system and have been asked by stakeholders to be tested. With these qualifications in mind, teams can better determine what features will be tested and can create the test cases necessary to evaluate them. This will help lower extraneous work and help concentrate on the most important elements of the software.

“Deciding what to test really involves two different questions,” Kelly wrote. “The first is a question of scope: ‘Out of everything that I could possibly test, which features are the right ones to test?’ There will always be more to test than you will have time to test. The second is a question of technique and coverage: ‘For each feature I am testing, how do I want to test that feature?’ Different quality criteria will lead to covering different product elements and different testing techniques.”

  1. Know when to change it

Even if you set a testing scope for a particular sprint, this scope may not be as useful down the line or as effective for detecting issues within the code. TechTarget contributor Jaideep Khanduja noted that any changes that happen will impact the whole application and this could mean that part of the testing scope must be shifted. It’s important to take this continuous testing initiative into account when establishing the testing scope, as it will be worth it to fully test the application to minimize risks and ensure that the adjustments didn’t break other features. To learn more about continuous testing and how it works for test teams, you can watch this video series by LogiGear’s Michael Hackett.

Some teams may worry that they simply won’t have time to thoroughly test an app as much as it requires in these fast-paced environments. Automation integration is a significant answer to these challenges as it offers teams a means to create, assign, schedule and monitor test cases across the board. Executing tests without any manual interaction means that QA professionals can focus on other tasks, while ensuring that their full testing scope is being carried out every time the software is evaluated.

  1. Make it clear

Although a testing scope may be hazy at first, it’s up to your team to set down a plan that makes it absolutely clear what you’re going to be doing. For example, it will be necessary to detail what testing processes you’ll be using, such as performance, load and experimental testing. It will also be beneficial to note which of these testing operations will be performed manually or with automation tools as well as how the environment will be set up to support procedures. Including this information within a testing scope will not only provide teams with a better idea of how to carry out these activities, but it will also give stakeholders and customers a clear picture of what they can expect.

The testing scope can be tricky to nail down for any team, especially when working on a project with a wide variety of features and requirements. However, using these elements, QA professionals can be guided on what should be tested, what are the most important items to focus on and how they should carry out activities to rise to the occasion.

1

Defining the testing scope will be essential to keeping teams on track.

sanjay

Author: Sanjay Zalavadia, VP, Client Services, Zephyr

As the VP of Client Service for Zephyr, Sanjay brings over 15 years of leadership experience in IT and Technical Support Services. Throughout his career, Sanjay has successfully established and grown premier IT and Support Services teams across multiple geographies for both large and small companies. Most recently, he was Associate Vice President at Patni Computers (NYSE: PTI) responsible for the Telecoms IT Managed Services Practice where he established IT Operations teams supporting Virgin Mobile, ESPN Mobile, Disney Mobile and Carphone Warehouse. Prior to this Sanjay was responsible for Global Technical Support at Bay Networks, a leading routing and switching vendor, which was acquired by Nortel. Sanjay has also held management positions in Support Service organizations at start-up Silicon Valley Networks, a vendor of Test Management software, and SynOptics.

Facebooktwittergoogle_pluspinterestlinkedinmail

Reasons to Consider Software Tests as Products

4c3fcd213a759803b5a3adf18b9e7992a8fbb3b5e1bc9588b2pimgpsh_fullsize_distr

With DevOps, automated tests have become a crucial necessity. Tests need to be thorough, and their automation should be stable. In fact, tests have to meet quality and robustness criteria that are similar to the application under test, but tests seldom get the attention and investments that the applications get. Where sources and components of applications are considered products that are designed and developed, tests play a mere supporting role. In Scrum projects you will not see tests specified in the backlog. Rather, they are seen as a part of the production for the user stories.

Continue reading “Reasons to Consider Software Tests as Products”

Facebooktwittergoogle_pluspinterestlinkedinmail

Virtualization—A Tester’s Dream?

f0f8ffa8c3ccf2767cc02b53f88bbfbb5dcdf9848d21047c4bpimgpsh_fullsize_distr

Virtualization has been around for a long time. As early as the 1960s, IBM was supporting virtualization on mainframes to ease the cost of migration among multiple generations of their systems. Languages like Pascal, Java, and C# translate into virtual machine languages that are then either interpreted or further compiled (“just in time compilation”) into actual machine code.

Continue reading “Virtualization—A Tester’s Dream?”

Facebooktwittergoogle_pluspinterestlinkedinmail

DEVOPS IS COMING, ARE YOU READY?

devops-is-coming-are-you-ready

Just when you thought you were safe from more process improvement for a while—not so fast. There’s DevOps, Continuous Testing, Continuous Delivery and Continuous Deployment. In this issue, we are focusing on Continuous Testing, the part most concerning Test teams.

Continue reading “DEVOPS IS COMING, ARE YOU READY?”

Facebooktwittergoogle_pluspinterestlinkedinmail