In the world of software development, change is something you have to expect occasionally. It’s inevitable. But adapting to some of those changes isn’t easy. Testers who recently became part of a new environment can relate to this. Normally, they will be asked to start by cleaning up the big mess, stabilize the team, and devise the workflow from scratch without giving them proper context.
An experienced tester can find patterns among all that mess, and figure out an optimal solution that will help them reorganize the testing team without much confusion.
Here is a 4 step technique that testers can follow when they enter a new, messy testing environment to get things in order.
1. Preparing an Inventory of Test Devices
This is probably the best way to start. As a new member of the team, you will be presented with a bunch of testing devices. Why not start by preparing an inventory of all the test devices your team is going to use?
While categorizing and registering the devices in the inventory, make sure to consider a few factors like the operating system used by the devices, the types of devices, and how the devices can be managed. This will make it easier for you to categorize the devices, and make the whole document available to the team for reference.
2. Creating Repository for All the Scattered Resources
Scattered resources is often a common problem in many testing teams. There would be no order. These resources may include usernames and passwords that give testers the access to whatever they require for their job, procedures to get access to those resources, information about the tools and systems used for testing, and other reference materials.
A common repository for the testing team can bring order to this chaos. The repository can be accessed and edited appropriately by everyone in the testing team. It can be kept in a common drive, say Dropbox or Google Drive. Giving access to the entire team can also help you ensure that you didn’t miss anything that should have been in the repository. This can also help new members to catch up quickly, without having to personally interview other members.
3. Testing Charters and Time-boxed Testing
There are times when the tester has to establish a testing process and start testing right after. Many testers would take a different approach, by creating a new process from scratch. This might either work or make things more complicated.
The optimal approach is to go through the existing process to get an idea of the existing resources, and then modify the process. Modifying the existing plan can be challenging as there would most likely be repetitive or outdated scripts. Nevertheless, using the existing plan as reference can make things a lot easier for the tester, and ensure a smooth transition to a new, more efficient testing process.
From what you can gather from the existing process, you will be able to create an exploratory testing charter. Your coworkers can add their test ideas to the charter. The charter should basically make the objective of each test session clear to the team. After creating the charter, the team can start performing time-boxed test sessions. Each session and their results should be observed, documented, and kept in a central repository accessible to the entire team.
4. Creating a bug template
A bug template is something that can be of great help when everyone other than testers including the developers, analysts, and stakeholders report bugs in various ways. Some of these reports might just have the user’s observation, while others might be descriptive. If there is a bug template for the team to follow, it could be easier for both the developers and testers to locate the bugs and fix them.
The template should have fields that describes the bug, describes how the bug was found, where the bug was found, the device and OS that’d been used when the bug was found, screenshots and other information that could shed more light on the bug.
The bug reports can then be easily understood by the testing team who will also be able to reproduce the bugs easily.
Conclusion
These are techniques that are meant to bring order to the testing environment by modifying processes and revising testing plans. However, it’s vitally important to figure out at what point the disorder began. Changing the processes alone won’t cover every context related to software applications testing. There should be focus on the people involved as well. Ultimately, it’s a team effort, and the steps mentioned above only serves to provide an easier way to manage the chaos in a software testing environment while making things less challenging for the testing team.