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 in the comments below.
While bringing order to chaos through new processes is important, I think bringing in the right processes is more important. To do that you have to understand the context and the why a test team may be in a state of chaos. To do that you have to focus on the people first. I was brought into a team to fix what many considered to be a failing test team. I spent my first three weeks doing nothing but interviewing the team members, the developers they worked with, the project managers, etc. In doing so I was able to identify the most critical issues (some caused by the team, some by out-of-control release and dev processes) and address the most important ones first. Within a year the entire reputation of the team changed, and I didn't have to do any large process changes - mostly just small tweaks to exisiting ones.
It's important to remember that no process will work for every context and that the most important element to any context is the people. If you can get them on your side and set the vision for positive change you will be a lot more effective than if you go in and just start adding processes with no background and understanding of how they got to the chaos state.
First of all, thanks for taking the time to go through the article and give your thoughts on it. I appreciate it.
Secondly, I totally agree with you i.e "People" and "Context" are really important factors when thinking about any kind of change or improvement. The steps I have discussed here are the common patterns I have observed/done when I joined new teams, ONLY after I took the time to talk to the team members, looked at already existing process, artifacts and making sure I do not reinvent the wheel. I kind of eluded to some of this in "Step 3" but yeah you are right that we should make sure we pay attention to "People" and "Context" first.
In my experience, I talked to a lot of people and the one thing I have always observed with people joining new teams/projects in a "change agent" kind of role is that, they often do not know where to start and get that feeling of drowning in a ocean full of problems. I was one such guy and following the above steps constantly in different teams I have worked with, helped me to get some clarity in the process and bring effective change. This was especially true in mobile related projects.
I agree that this is not a blue print of what all people must follow when joining a new team but it was certainly helpful in my experience; as I have tried it out in multiple projects and also heard other people following these steps and getting some value out of it.
My motto in terms of any kind of change is "Make small changes->Measure it-> Get Feedback ->Pivot based on the learning" (Kind of the Lean startup cycle). This constant feedback cycle helps to bring effective change in any context.
Thanks for your valuable input.
Solid steps. Thanks for sharing. Would add that bringing stability to chaos also involves (re)building trust. The part about transparency with use of tools is a great step to developing, restoring and/or extending trust - which is the opposite of suspicion.
Great point Benjamin. Things I wanted to highlight from the comments you guys have mentioned and worth repeating again is "People", "Context" and "Trust". Something that I need to remind myself and other people I work with. Cool.
I agree with what is proposed, but what if some team leads and some in QA do not want to adhere to a new process and instead perform their work exactly the same way as they have done for the past 20 years? A process works only when it is a common process that everyone accepts and follows.
You had a valid point that "A process works only when it is a common process that everyone accepts and follows." I agree with that.
In terms of "what if some team leads and some in QA do not want to adhere to a new process and instead perform their work exactly the same way as they have done for the past 20 years?" this is my view on this...
Change is hard, especially when trying to implement change in a huge organizations. I have worked for multiple companies from small, mid-tier to large companies so I can speak on this aspect based on my experience. There are ALWAYS going to be people who do not want change, that does not mean we should not try out something different which may/may not work on a long run. Continuos experimentation leads to something good in the end (based on my experience). That is how even products we use in our daily lives have evolved.
The way I do process changes/improvements is after doing all the groundwork of what is happening and what needs to be fixed/removed, I collect statistics on what the old process was and what "could" be the improvement with the new process. Also, I first identify only those people who are open to hearing new thoughts and have broader perspective on things.
Once I identify these "like minded people", I talk about the cost vs value aspect of bringing a particular change and try to get feedback on it. This is really important because they may have some valid concerns that I would not have thought about before. After tweaking my proposed process improvement idea a number of times based on the feedback from this selected group of people, I get the approval from these people. Then, I pitch the process change idea to a larger audience may be a team or a group who would be involved in this process.
By doing this, I have already got buy in from a small group of people before approaching the whole team and so bringing process change would be lot more easier than not doing any of the things I described above.
The key is Build->Measure->Learn and starting small.
Hopefully that gives a different take on this subject
Thanks for reading