With so many testing requirements, how can we win in the Agile environment?
When compared to what we see today in the industry, the use of Extreme Programming (XP) by Agile teams was very common in the late 1990s and early 2000s. The team's main focus back then was on determining what customers wanted and then fulfilling that demand through direct communication and true collaboration. We and our teammates tended to be generalizing generalists, with the goal of delivering a product, even if we occasionally neglected specific areas of the product such as reliability, accessibility, performance, and security at our own risk.
Agile teams cannot afford to overlook critical testing aspects that may have an impact on the product's quality. Agile teams realized that they needed to be vigilant about all aspects of product quality, even if business stakeholders failed to mention them in the product requirements. This is especially important these days, given the new testing challenges posed by the various technologies, platforms, and devices that have emerged in the last decade or so. Agile teams must adapt and become familiar with new testing types to overcome these challenges, making the testing process even more complex than before.
Take, for example, the security aspects, which are now more important than ever. Because external forces demand more test coverage, organizations must now ensure that their products meet security and industry standards. Organizations must ensure they have the tools and expertise to handle security threats to software systems, and they must strive to find better ways to test security.
The average Agile team lacks the expertise, tools, capacity, or infrastructure to support all of the types of testing that are requested or that they wish they could perform. Let's say the team needs to support X users accessing a service at the same time, or they need to perform scale testing. Even if they are eager to succeed and meet those demands, they may not have the infrastructure to drop stable code for performance testing. They may also require support tools in order to simulate loads and track performance counters. And this is just one problem; if they need to test an android app, for example, they'll need tens or even hundreds of devices to ensure it meets the minimum requirements.
Consider the numerous types of testing available to Agile teams when it comes to evaluating their products. When you think about it, most Agile teams will run into one or more issues when they begin running their tests. This could be due to a lack of experience, skills, or even time to do everything, and it can be overwhelming for most Agile teams.
One of the issues I've noticed is the misalignment of so many different types of testing that differ from one organization to the next, and even between teams within the same organization. When new people join the company and talk about system tests, everyone assumes they're talking about the same thing, even if system testing means something different to them.
One of the strategies I employ to address this issue is to ensure that the organization has a single repository containing a list of test types that is as simple as possible. This repository is included in any training I provide to my teams, especially new hires. It also aids in the formation of a shared understanding within the organization.
Basic guidelines for making such a list can be found below:
Only include test types that are critical; leave out anything that isn't.
Reduce the number of items on the list to the absolute minimum.
Make sure to include a description and explanation of "when" and "how" to use each test type.
Update the list based on employee feedback; this is critical because they are the ones who are actually doing the work.
Ascertain that all employees have access to the item repository.
Here's an example of a GUI testing from my collection:
Description:
The graphical user interface (GUI) is the primary platform for manipulating software. Due to its importance to the end-user, it must be carefully tested to ensure that the user can easily interact with it, perform highly complex operations as efficiently as possible and ensure that it is clear enough for them not to ask technical questions.
Guidelines:
Ensure that the application logic makes sense from a customer's point of view.
Simplify the use of complex functionalities.
If the user needs to learn the software’s graphical interface from a thousand user guide pages, then this GUI is not a usable interface.
Tests must represent customer expectations.
The GUI must have the right look and feel.
The user interface should do what it is supposed to do and nothing else.
Use positive and negative tests to ensure that objects can handle different inputs.
And here is another one for Regression testing:
Regression tests are tests that are run on a daily basis to ensure that any changes to the code do not have an unexpected impact on existing functionality. Automated checks, in my opinion, are and should be the best approach for dealing with these types of tests because they provide the most immediate feedback. This is especially true in today's market, which is based on frequent releases (I used to work for a company that released at least five releases per day), cloud infrastructure, and increased customer demands.
For more information on regression testing, click here.