Adding software testers successfully to any product team: Experiences, struggles, and tips

Once upon a time, some people would have you believe, project teams consisted only of developers, analysts and product owners, and everyone worked together in eternal harmony. Then, out of the blue, some software testers crashed the party, and peace was a thing of the past. Demanding change and seemingly criticizing everything, they shook up their new teams thoroughly.

Okay, all that might seem a bit over the top. But to a development team that suddenly has testers thrust into their midst, this will feel relatable. The development team might feel threatened: the testers don't seem to trust their abilities. Who are these testers, anyway, to question their carefully made design decisions and unit-tested code?

However, when the decision is made for testers to join a team, the only way is forward.

I will share some of the things I learned when I joined an established project team as a tester. The team had projects in maintenance AND in active development.

Tip 1: Plan a trial test run with all team members on board

Schedule an initial get-to-know-you meeting

After the team has been informed that testers are coming onboard, and their onboarding has been planned and scheduled, a meeting is in order. There are different ways to go about this meeting: everything depends on how much time is available and the degree of apprehension you feel from the team. 

If testers are necessary but their role in a development team is unclear, you will need a longer and more thorough first meeting. Her, you discuss the team’s needs and figure out what kind of tester they require. 

Choosing a format for the first meeting(s)

You have a wide range of possible meeting formats to choose from. For example, a RiskStorming session can work well. At the meeting, the entire team should plan to evaluate the level of testing currently being done, how you work as a tester, and how you will be able to integrate into the team and start testing. ‘How can this be tested?’ is not a question that people other than testers usually ask, so be sure to describe what you need for tickets to be testable.

In my case, analysts did some testing, developers wrote some unit tests for code coverage, and there was some user acceptance testing. However, functional test engineers had never been a part of their process. The team knew what the testers could do, and they were more than welcoming, but they were still apprehensive of us and the changes we represented. Knowing what a test engineer does in theory and in practice is very different, and knowing the bias against testers, they probably dreaded the criticism we would have.

Try a trial testing period

Since the team was quite welcoming, our first meeting was more about setting the terms for a ‘trial period’. Here's what our meeting agenda looked like:

• An overview of how things work: We testers explained how we usually work, how we organize our work, and what we would need from the rest of the team. Testing was set as a part of the ‘Definition of Done’, and testability became a new quality measure of tickets added to a sprint.
• Clear is kind: We made it clear that testers joining the team wouldn’t mean more work for the rest of the team. For example, some team members panicked when they saw a ticket I'd created for test plan administration. I took the time to reassure them that they wouldn't have any more work as a result of the ticket. But even after reassuring them the apprehension remained unchanged.
• Decide how to move forward: We needed to decide where to start. Since the team had projects both in maintenance and in active development, we decided to pick one application that was in development and focus on those tickets. This way everyone could ease into the transition, instead of diving in head-first.

In brief: What should happen at the first meeting

• Put the rest of the team at ease
• Ask about the testing that happened before you arrived
• Explain how you work
• Specify some necessities to make sure you can test
• Agree on where to start

Tip 2: Show the team how testers work

Dealing with jitters and reluctance to let go of the reins

With the first negotiations over and done with, it’s time to get to work. Although everyone goes in with good intentions, this can quickly turn into the staking of territories. Change is always difficult; even though tasks might be divided and assigned clearly, it’s difficult to give up control, especially when you watch someone else invade your hard-won territory. But keep in mind that even though everyone has their own tasks, it’s everyone’s project to share. People shouldn’t be staking their claim in the team. Instead, they should try to find their place in it!

Let’s make that a little bit clearer. As mentioned above, just because there weren’t any testers on the team before our arrival didn’t mean that no one was testing the applications. Usually, each analyst would test their own ticket and, of course, developers worked on code coverage.

Giving up this piece of control, not having the last say before a feature is presented before your clients, can be difficult. As a tester, it’s all too easy to see this as your task alone and demand that they let you do your work. After all, that is what your whole job is about! The people who did any level of testing before your arrival might insist on reviewing the ticket before you test it, and you might insist that you do all the testing. It’s important to remember that everyone can and should test: the more the merrier! So clearly communicate your frustrations if people are drawing lines where there shouldn’t be any.

Calming the anxious team: bring others along for the testing ride!

If there is still a lot of apprehension, a good way to get everyone on board is taking them along while you test a ticket. Take a ticket you know how to test and ask your colleagues to join you in testing it. This will also allow you to demonstrate your testing know-how (subtly)! 

You can start with the people involved in the ticket or give yourself a challenge and invite the people who seem to be the most skeptical of your role. While testing, explain what you do, and share the specific parts you pay attention to when testing.

Know the product you're testing inside and out

Learning as much as you can about the project and application is an absolute must. Whether it’s poring over the documentation, asking for a meeting with the team where they explain the application, or doing exploratory testing to learn more, each approach gives you different insights.

Ask for help and clarification

Don’t shy away from asking for clarifications or help! You’re part of the team now: not only will gathering all this knowledge help you in your job, but it will also help the rest of the team understand what kind of information you need. And it might give them new insights into their application as well.

In brief: Tips for successful tester integration into a new team

• Don’t demand control over testing! Before you, others tested the application, so work with them to learn more about the application and how to test it.
• Simply start testing. Don’t wait around for others to tell you when or what to test.
• Ask questions, read documentation, explore the application. Learn as much as you can without being prompted to do so.

Tip 3: Look for ways to keep improving and put them into practice

Make sure your progress is reflected in sprint planning

Once all members of the team get used to your presence and work, it’s time for another meeting to discuss the next steps. The transition period is coming to a close, so now it’s time for the testers to start working on more tickets. 

On a new team, it takes some time to be able to cover everything. So instead of immediately committing to take on everything, set some attainable goals. Increase test coverage with every sprint, until you can test every ticket.

Build in testability

Try to make the query ‘how can this ticket be tested’ part of the analysis and development process. Defining approval criteria during the design process can help improve the testability considerably. Some assistance from developers might be required to mimic integration with other applications that aren't available in the test environment of your application.  

Start the conversation during meetings where tickets are discussed, like sprint plannings and backlog refinements. Before you know it, thinking about and building in testability will be a part of the process for everyone.

Ask for feedback and act on it

Don’t forget to ask the team how they think the integration of testers is going. Ask about all aspects you can think of, from the testers’ presence during sprint ceremonies to how well they think the testing is going, and of course ideas on how to improve the workflow and cooperation.

After holding a retrospective meeting with the entire team, do not forget to organize one for the testers themselves as well.

Every team and project is different. So, during this transition, you might have adapted your methods to fit the team or stuck to what you know works. It’s important to reflect if your way of working needs to change.

Accept that the testing process will probably need to change over time

On  my team, we had to modify our testing process a couple of times. For example, when we had spare time, we wrote regression tests for the parts of the application that had been developed before we joined the team. But when a defect fix for these features was occasionally added to the sprint, we sometimes fixated on solely what the ticket contained. The narrow focus allowed us to increase test coverage more easily, but the resulting tests lacked maintainability and integration coverage. Quite a few tests were not reusable, so we turned this into a point to improve on for ourselves: keep the bigger picture in mind and write tests for the entire feature, instead of just a test for the bug fix.

It also became difficult to maintain our test repository, since there were a lot of projects to test. To solve this, we discussed a naming convention that helped us quickly identify the tests for a specific application. We also made cleaning up the repository a part of our routine, so tests could be traceable.   

In brief: Establishing yourself as a tester on the team

• Don’t overcommit on test coverage. Set attainable goals and gradually increase the number of tickets you can cover.
• 'How can this ticket be tested?’ should be part of the entire team’s thinking. Pose the question often, and before you know it, others will start asking it themselves.
• Do a retro on the integration process. Recognize both the good and bad!

Happily ever after? Commitment to continuous improvement is the key

Integrating testers into an established team is a process with ups and downs, but at some point, the integration comes to an end. You can keep improving the way testers work in the team; in fact, aim for that continuously! However, there comes a time when you need to declare the integration complete.

But when is that time? When you know everything there is to know about the projects? When the team has complete trust in the testers’ skills? When there is full test coverage for every ticket in every sprint? Every team needs to decide that on their own. But I dare to argue that the conditions for declaring that the moment has arrived should be crystal clear, and when that moment arrives, its declaration should be public knowledge. This is the moment when the testers will finally feel like complete members of the development team. 

For me, this moment came after quite a while on the team. During that time, I put in a lot of effort in bug reproduction and keeping up with testing and sanity checks for high priority tickets that needed quick releases. I showcased the added benefit of testers to everyone in the team and was rewarded with many acknowledgements during the retrospective of that sprint. 

Now that I am sure my team knows what I can offer, I am confident in my place on the team.

For more information

• Pairing With Developers: A Guide For Testers, Lisa Crispin
• RiskStorming In Agile Teams With TestSphere, Gem Hill
• In-Sprint Test Automation On Agile Teams: Yes You Can!, Swathika Visagn