I’d been testing at my current company for over 5 years before I met a tester from another team. When I started at the company I now work for, I had no idea there were other software teams as part of our business. I only knew about my team, and how we made our products.
After about 2 years, the company I work for was part of a merger. As we transitioned into the new organization, our software team was made aware of other teams making software. Some of these teams worked for the new parent company, but some had been working at my old company all along. Even as I started hearing about these other teams, I knew shockingly little about them. I was aware of what kind of products they made, but I had no idea what their teams looked like, or how they developed software. I assumed that if there were something important to know, someone in management would find out and tell me about it.
Three years later, the company realized that the software development process across our teams was disparate. They hoped to find a way to allow teams to work together seamlessly, but first they needed to identify what each team was doing. I was asked to join the “Testing Project” as a representative of my team. Each of the other teams sent a testing representative as well. We came from the US, Europe, and China to meet in Oslo, Norway to talk about our testing stories.
Get TestRail FREE for 30 days!
Many Ways of Working
As each group told their story, I couldn’t believe how different we all are. One team has fully integrated their testers into the development process. Many teams operate in various stages of waterfall-to-agile transitions. Some still use test plans and test scripting, instead of the chartering and session-based testing my team adopted. Another team uses a true waterfall process, with stage gates and time-based estimates. There is a team that has no testers, but instead has a release manager who conscripts groups of developers to carry out testing. Finally there is a “test center” that carries out testing as a service for a variety of development teams.
By far, the most interesting team to me is the agile team that has fully integrated their testers into the development process. They are doing things that I can only dream of. They start by mobbing the acceptance criteria for each of their user stories with an architect, developers, and testers. They have a definition of done that includes testing. As a result, developers are active participants in testing, since each single tester cannot be expected to keep up with multiple developers independently. Instead, developers and testers work together to get all the stories successfully tested. Also, no story is considered done until defects against the story are fixed, so falling behind due to defects isn’t a problem. Every two weeks, they host “Bug Crush” days, where development is devoted exclusively to the finding and fixing of bugs, keeping their product quality high throughout the development process. Finally, there’s a daily defect standup so that bugs that are found during testing are handled quickly and efficiently, and the product owner is consistently updated on the current status of the product.
Other test teams are doing interesting things, too. The Test Center team created a testing newsletter. They use it as a way to share recent undertakings, and help each other acquire new skills. They also established a Community of Practice to learn more about specialized topics like security and performance testing. Many of the teams are experimenting with cloud-based test environments and are well-versed in automated tools that my team may need in the future.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Not So Different
What really struck me after attending the “Test Project” sessions wasn’t how different all the teams were. It was that all this time, problems that I’ve seen have actually been solved in large part by people working at the same company. I’ve wished testing could be more closely integrated with development, and there’s a team already doing that. I’ve wanted to begin a community of practice so I could develop more skills and help others develop theirs, and it already exists. I wish I’d known about the amazing community of testers we have sooner, but I’m grateful that I know it exists now.
I can’t wait to start working with other teams, asking for advice, and learning from all the amazing people I’ve met, right here in my own company. I’ve already invited my newly discovered coworkers to a Slack team, and I’m emailing them regularly when I spot an article, meetup, or conference that might interest them. Soon I’ll be asking them questions so I can find out how to move my testing to be more integrated with the development team.
Sometimes the best place to start looking for answers is in your own backyard.
This is a guest posting by Carol Brands. Carol is a Software Tester at DNV GL Software. Originally from New Orleans, she is now based in Oregon and has lived there for about 13 years. Carol is also a volunteer at the Association for Software Testing.
