Steps to build a mobile test process from ground up - Bringing stability to chaos
We all know that change is not always easy—particularly when you're in a new environment. Sometimes, when you're joining a new company or team, you get asked to clean up the mess in a project and build a workflow from scratch, without any context of the expectations. Over the years, I have been in this situation many times, and I started finding patterns.
When I say “patterns,” I mean I saw things I could do immediately to get started building a process and organizing the team with the least amount of confusion. My expertise is in mobile software, so some steps may be more relevant to mobile teams, but most of it can be applied to other project teams as well. Based on my experiences, there are four steps that help bring order to team chaos.
Step 1: Take Inventory of Available Test Devices
As a new member of the team, we need to start somewhere. One of the first things you could do is make an inventory of the devices you have for testing.As you gather these test devices, keep a few things in mind:
What different devices do you have for testing?
What OS versions do the devices use?
How can we best manage these devices?
Asking these questions helps you get a handle on the test devices. Based on the answers, create a list with names of all the devices, their UUID numbers, OS versions, and other vital information.Through this data you can discover whether you have a sufficient number of devices for testing. You also have now created a reference document for anyone to see the different devices available to the team.
Step 2: Create a Wiki to Have a Central Repository for Testing Resources
Another common problem in many teams is that resources are scattered all over the place. These resources can include usernames and passwords to access necessary websites, system accesses testers would need while doing their testing, procedures to follow in order to request access to test resources, information about systems used by the team, and any other documentation that could help team members do their jobs better.It’s a good idea to create a team wiki, or any other shared document the team can all access and edit, such as in SharePoint, Dropbox, or Google Drive. It should include all the resources related to testing, delivered in links, tables, attachments, and plain text. Get it reviewed by the team to ensure all the information has been documented.Another advantage of doing this is that new hires and new members to the team will be able to quickly look up information related to the project instead of going around and asking different people. In my experience, this step proved to be invaluable to new hires and the overall onboarding process.
Step 3: Create Exploratory Testing Charters and Perform Timeboxed Testing Sessions
I had to not only quickly establish a test process in the teams I have worked with, but also start doing testing right away. There were often too many test plans or outdated, repetitive, or redundant automated scripts. I took the time to go through each one of the scripts and test plans and see what could be reused.When joining a new team, the biggest mistake you could make is ignoring all the previous processes and artifacts and trying to reinvent the wheel. Take the time to look into existing resources in order to make the transition as easy as possible for your coworkers.
After getting an idea of what you have, determine what can be reused from the older test plans and add new test ideas to your exploratory testing charters. The charters serve to communicate the mission of the test session to the testers on the team, as well as outline some test ideas to use. For examples of exploratory testing charters, I recommend reading this paper by James Bach.
Once the charters are ready, start doing time boxed test sessions and record all the observations in them. After you complete a debrief for the sessions, store all the charters in one central location so that they are visible to the whole team. This way, testing is not considered a separate or secretive activity, and it’s more transparent and open to everyone.
Step 4: Create a Bug Template for Consistent Reporting
Another practice I have observed at times was that all the team members, including developers, business analysts, and other stakeholders, reported bugs. This is not inherently bad, but each one of the reported bugs had different kinds of information. Some were descriptive, some had screenshots, and some were just one-liners about what the reporter had observed.To bring consistency to the way everyone reports bugs, create a bug report template for the whole team to follow. The report should contain the following information:
A one-line description of the bug
A detailed description of the bug
Steps to reproduce the bug
The environment it was found in
The devices and OS versions being used when the bug was found
The app versions being tested
Screenshots of the bug
Other details like priority, severity, who found the bug, and whom it is assigned to are usually handled by the bug-reporting tool used by the organization, so that makes this job a lot easier. Once you have created the bug report template, the team can start writing consistent bug reports that are now easily understood by everyone.
Following the above steps helped me adapt to any kind of project and contribute to the team effectively from day one. Do you have any other ideas that have helped you in similar situations? Feel free to share them with me in the comments below or by e-mailing me at raj@rajsubra.com
NOTE: This article I wrote was also published in Stickyminds -> https://www.stickyminds.com/article/4-steps-rebuilding-testing-team-bringing-stability-chaos?page=0%2C0