Stop Losing Money. Invest in Software Testing

I was once asked at a testing summit, “How do you manage a QA team using scrum?” After some consideration, I realized it would make a good article, so here I am. Understand that the idea behind developing software in a scrum environment is for development teams to self-organize.

That implies that the team members should essentially manage themselves and hold each other accountable, correct? That being said, it begs the question, “What do QA managers do with their time?” For me, it’s always been about creating the right culture—respecting those below you just as much as those above you. It is about figuring out how to manage your team without being engaged with them directly. I understand that finding your niche within a scrum environment can be challenging for some. For these reasons, I’ve listed some of the main things I worked on with my teams to create the right culture.

Team support is a must

First and foremost, provide the necessary support and mentoring to your team. You are their voice, and their reflections are reflections of you. Be their representative when the company needs to turn around another major release quickly. It is your responsibility to consider how this will impact your team. Is it necessary for them to create any new environments? Are there any high-priority bugs that must be addressed? Is the automation testing complete? Are other teams required to perform any integration testing? Are there any security flaws that must be addressed? If the team encounters any difficulties, it is your responsibility to express your concerns to them. The team leader assists the team in self-organization and is responsible for removing any roadblocks that impede them, but the QA team can be easily ignored, which is when you as a leader must step up and clear a path for them.

Pave way for clear focus

As a leader, you must assist the QA team in self-organizing testing efforts. Help them remain focused on the tasks at hand and on what they do best: testing the software’s features and functions. This can be as simple as locating a third-party license or attending a meeting on their behalf. Or perhaps the team is working on integration testing and you need to organize a meeting with various co-located teams to explain how certain functionality works. The most important thing here is to be available for your team. When they require your assistance, do your best to maintain them focused on the task at hand, which is testing.

Second, just because you’re a manager doesn’t mean you can’t be hands-on in assisting your team. Lead by example. I’m sure we’ve all heard that saying, but it’s so true. Yes, among other things, a manager’s role is to delegate and ensure that the team is moving in the right direction and adhering to the company’s procedures and policies. However, as previously stated, you want the team to concentrate on testing, so you may need to step in and take on tasks that will free up your team. We recently had to recertify one of our software solutions. Aside from the additional testing required to obtain certification, we also required additional documentation to be written for the certification process. We already had a certification report that QA would generate at the end of a release cycle when the software was distributed to the general public.

Depend upon clear reports

As part of this new certification, we decided to update our existing certification report with the necessary information. Instead of asking my team to add additional information to the report, I decided to go through the entire report and try to condense and merge information that the certification considered necessary. I knew the team would have a significant number of questions and concerns when I did this type of report for the first time, so I went through the report with a fine comb to try to standardize and easily explain to the team what was expected. I was able to communicate what was expected moving forward once I had a tangible report. This simplified the process for everyone involved, and it freed up my team to concentrate on other activities that needed to be accomplished.

Listen to your team members opinion

As a QA manager in an agile environment, you do not have the opportunity to work one-on-one with each team member as they do with their scrum teams. As a result, you must meet with your team as often as necessary. Yes, you will go over the usual high-level areas of what is going on within the team and company to keep the team informed. However, this also allows them to express any potential bottlenecks or issues that may arise during their sprints. You can use this time for team members to demonstrate the tools they are using or to discuss ways to enhance the team’s efficiency. Alternatively, involve the UI/UX developers and discuss any troublesome usability testing that may cause uncertainty between the programmers and Testers.

Take a look into quality assurance

Discuss what Quality assurance measurements the team would like to present during sprint reviews. You can use this time to effectively bridge the gap between the company’s other business units. Keep in mind that the meeting is for you as a manager as well as your team, so you can observe how team members are accomplishing their tasks and how they are operating within the scrum team. As a manager, you must focus on ensuring that each member of the team communicates with one another, especially if you have many cross-functional teams that interact with one another. You must ensure that the left and right hands are testing in sync and that there are no inconsistencies in each team’s testing. Although you should try to keep meetings to a minimal level, meeting with the team as often as necessary is essential to stay in alignment with your team and their tasks, especially since they do not work directly with you regularly.

The way you treat your team members matter

Yet another thing I’ve learned from my experience as both an engineer and a manager is that you can’t always treat every team member the same way. I’m not suggesting that they should treat all aspects of their responsibilities differently. For example, when enforcing company guidelines or policies that should be the same for all employees. If you have to discipline a team member, they should all face the same consequences. What I’m referring to is how you manage each individual. Let me explain where I’m coming from on this.

When I first started as an associate engineer, I was full of enthusiasm and motivation, ready to take on the world and climb the “corporate ladder,” so to speak. I didn’t realize it at the time, but I needed some direction. I needed someone to point me in the right direction. I was like a sponge, soaking up anything and everything. As I progressed and spent my years perfecting my craft and fine-tuning where and when to exert my energy, I realized I no longer required that hands-on mentoring. Whereas I needed a mentor when I first started, I am now the mentor for others as they begin their careers. This didn’t mean I didn’t want to learn new things, because in this industry if you’re not learning new things year in and year out, you’re falling behind the industry standards.

This simply meant that my mental state had shifted, and I no longer required the hands-on management that I had desired when I first began. This is why I believe you cannot treat all engineers the same. Professional developers with more experience should require less attention than junior-level engineers. That is why there are different titles and salary brackets—senior engineers are expected to do more, including managing themselves. Whereas associate engineer is still learning and requires guidance from their manager to point them on the appropriate path, even if they don’t think so at times. I despise the term, but they could benefit from some micromanagement.

As previously stated, this industry is always changing, which is one of the main reasons I chose this career path. There’s always something new to learn. Keeping this in mind, your team must be able to adapt and change following industry standards. As a manager, you must constantly look for ways to educate and improve the skills of your team. This can be accomplished by upgrading some of the techniques they use or simply providing them with mentoring. If your engineers do not enhance their skill set from year to year, your team may begin to fall behind. If the team falls behind, you as a unit will fall behind, and it will be a domino effect. Trying to promote and push your team to educate themselves, learn new tools, and learn new skills is a mindset that must be ingrained. This could be as simple as enrolling them in an online training program. Send a single or a few team members to a tech conference if the budget allows.

I believe it is extremely beneficial because your team sees that you are investing in them, and in my experience, they return to work energized with fresh ideas. Updating the toolkits your team uses is another way to improve their skill set. For example, we previously relied on an antiquated bug-tracking system. I decided to update the bug tracking system to something more modern that integrated with other development tools, so that QA and developers could collaborate with a unified platform, making life easier not only for us but for the entire development group. It took a lot of time to research and migrate the data to the new system, but once completed, it helped my team become more efficient in performing their day-to-day tasks. Always seek ways to improve as a whole, as this industry constantly adapts and changes.

Make yourself available by making a phone call rather than typing in a chat session. Alternatively, during a Zoom meeting, turn on your video so that the team can see you. Little things like this make a difference and add a more personal touch to your team. When it comes to building the right culture within the team and getting everyone on the same page, QA managers have their work cut out for them. They must keep the team on track so that no testing gaps or tasks are forgotten. They must keep the team focused on what they do best: testing software. They must find ways to keep the team inspired and productive in their day-to-day activities. The tasks pile up but don’t lose sight of what you’re trying to accomplish: maintaining the high-quality standards that your company and clients expect.

Promote ways to reduce cost, track changes and improve quality

We need to focus more on reducing the cost of our test scenarios and their layout. As systems evolve, we will be required to employ reliable test scenarios to guarantee their execution. If you make a technical change—a new control, a revised command, a new webpage, new environment variables, etc.—you must include it in your test project. The majority of the funds spent on testing is invested in maintenance and adoption however there are simple improvements that can minimize these efforts.

For example, having the technical objects isolated from the others, and centralized to allow the ability to adjust only one item to sustain all associated tests, would help you save a lot of money. If you have a login window with the controls for the username, password, and login button as a single object, you might call it a module, or you could create a collection of all application controls as a base class and reuse them all the time. This approach is similar to object-oriented programming in that it generates reusable artifacts. You may just pick one site, list all of its controls, map each of them to your test case, and reuse those objects again and again. Technical changes will have less influence on your tests, they will be more reliable, and you’ll be able to maintain all test cases with a single update since you only need to alter just one module holding the modified control.

Currently, most testing is done by writing code and utilizing code-based frameworks, and the majority of the budget is invested in maintaining technical changes that occur with a newer version of the product. When you use object orientation on the technical side, you will save money that can be invested in innovation to help your company expand. Technical challenges are still the most common cause of test failure in the current setup, but what about test data? I’ve witnessed numerous clients utilize the same test data over and over. They establish a new test case simply to run another batch of data. You may alter it to a database and a systematic strategy to segregate data from the test case, and even from the program or code in some cases. The advantages will significantly improve your testing strategy!

Business users can now make changes to the tested data without informing the testers. They might add new data sets or eliminate some that are no longer relevant. SQL queries vary dynamically based on the input data, and even the use of disguised productive data is feasible since it only impacts the data in the database that was fetched by the query. Business users also acquire the awareness of what data is used for which test, and if they are already linked to a test case, they may immediately react to new needs and added functionality. A randomly selected test data strategy, in which the query always returns a random dataset that must fulfill certain established requirements, can be employed. Depending on the data collection, this is closer to a production environment than a testing one.

Are you able to recognize how this will affect your expenses? Since they know the data and can reproduce the error, the business can readily detect problems. Randomized test data improves test coverage and may be derived from productive data that is already there and only has to be anonymized. Risk coverage tends to increase with this masked productive data because you test what users are using. When customers gravitate toward a particular feature, you may already test it in test environments with the appropriate trended data. Furthermore, the process through your application is a cost-effective solution to reduce maintenance. How simple would it be to create a data-driven structure for a test case using the information provided earlier in this section?

Make predetermined test step blocks and reuse them as objects. Create basic conditions that are based on the data you use and as generic as you can. You will now again have a single point of contact if the process changes, and adding new variants to your test case will be simple. All of your test cases will be affected by a single change, and all consumable data will be used for that usage or necessity only.

My team and I revolutionized testing for one global firm by simply grouping the test cases and extending them with a data-driven strategy. Conditions determined how the test cases functioned and served as the foundation for how they acted during execution in the system under test. Consider identifying a component as not existent in your system, and the test case automatically recognizes that it has to check the error message rather than the success, based only on the input data. If you encounter another issue that requires investigation in another system, just retrieve the block and add its data dependent to your structured test case.

Another alternative would be to decompose test cases into little chunks and see their sequence as the actual test case. You must construct a set of test cases that are parts of the overall. Data that is newly produced might be dynamically transmitted through a database and forwarded by a specified status. This strategy may result in several repetitions of several data-generating test cases, but it will boost the reusability of test case blocks to enable a single point of change and decrease duplication throughout your test library.

Spending so much money on creating new test cases is no longer essential. Testers simply assemble their test cases from specified blocks and must guarantee that the data flow is provided. Only completely new features must be produced as a new structural block, which can then be incorporated into your test step library. Whenever an additional test case passes your new feature, the new block is added to your test case, and if it changes, just a single modification in this exact block is necessary.

Aside from the test cases themselves, you may also save a significant amount of money during the design and early configuration phase of your tests. Consider how much faster it will be to have test data prepared in advance, rather than manually or through UI-based test cases. The data may simply be fetched into a database and picked up by test cases, regardless of whether they are tied to a single case or selected based on specific requirements.

If you manage a microservices environment, you may perform API requests automatically, unattended, and in parallel to build up your test environment and be ready for automated test case runs. It’s building non-UI test cases to produce or obtain test data, and depending on your configuration, you may either save it in a repository or use the services directly throughout your test.

Service virtualization may also save you money on hardware or third-party vendors while relocating your testing to the left and enhancing the uptime of your test environment. To avoid downtime, check dependencies early in the testing process and build up alternatives for unstable programs, features, or online services. Standardize tools and procedures to decrease expenses associated with scaling up workers, and use simplified reporting instead of integrating different technologies.

Conclusion

There are various strategies to save expenses while testing, but it will be ideal to plan your strategy rather than having to switch to a more efficient method later. Success should result from clear architecture, deliberate testing, and an object- or model-based methodology.

David Tzemach

The founder and owner of the Agile Quality Made Easy blog (25K followers). A platform that he uses for teaching and coaching others, sharing knowledge with people, and guiding them towards success while giving them the inspiration and tools to discover their own path.

See author's profile