In last months, me and my remote tester have ended up with different products. I'm still the test manager for the product the remote tester works on, but I've cut down my hours to a level where I spend no time testing. Then again I spend most of my time testing without managing anyone in the other team.
At EuroStar 2013, I pointed out to the remote tester (face to face time, nice!) that I feel alone with the developers. I'm considered the odd one as I like - LOVE - testing and the puzzles that unveil while testing. And on the two teams with 15 developers, the connection with developers just isn't the same, it's great too and built around purpose of the product. But none of them gets excited about testing.
So we agreed to spend half a day testing together, with a talk connection open while we test the same thing. Every second round is devoted to each product, and the session theme comes from the one that spends more time testing that particular product.
We've been doing this for two months now, and for our latest session a developer had a perfect timing. He asked if we would by any chance have some time to spare on testing an area he refactored and if he should even check it in at this point. We agreed that the only way is forward, and he mentioned he'd spend the next few days doing own testing. I promised to find time to help and talked about that to the remote tester. She immediately suggested that the side-by- side session on her product should have that change as the theme. Mentioning this to the developer, he went apologetic telling he has not tested that completely yet, as he's been told our process works. But he committed the changes and was happy to get the perspective he asked for.
We tested the area and found problems. And the developer fixed them, right there and then. We got a nice idea of the state of the area, and while the dev might have found some of the issues himself, I was glad he didn't. It felt like we were actually working together, instead of being forced to be the ones who told the developer that his best attempt on testing just did not do the trick.
Towards the end of the session I realized there was an opportunity to invite the developer to listen in to us debriefing what we had covered, and he seemed happy to join. In a short meeting, we told what we had covered and identified as areas of more focus. And agreed on how to go forward.
It was a great experience. The right timing, the right collaboration. And left me wondering: why don't we manage to do more of this? But the story of this experience worked great on the manager who tends to think that saving my time is more important than great flow of collaboration. So, I'm hopeful.
At EuroStar 2013, I pointed out to the remote tester (face to face time, nice!) that I feel alone with the developers. I'm considered the odd one as I like - LOVE - testing and the puzzles that unveil while testing. And on the two teams with 15 developers, the connection with developers just isn't the same, it's great too and built around purpose of the product. But none of them gets excited about testing.
So we agreed to spend half a day testing together, with a talk connection open while we test the same thing. Every second round is devoted to each product, and the session theme comes from the one that spends more time testing that particular product.
We've been doing this for two months now, and for our latest session a developer had a perfect timing. He asked if we would by any chance have some time to spare on testing an area he refactored and if he should even check it in at this point. We agreed that the only way is forward, and he mentioned he'd spend the next few days doing own testing. I promised to find time to help and talked about that to the remote tester. She immediately suggested that the side-by- side session on her product should have that change as the theme. Mentioning this to the developer, he went apologetic telling he has not tested that completely yet, as he's been told our process works. But he committed the changes and was happy to get the perspective he asked for.
We tested the area and found problems. And the developer fixed them, right there and then. We got a nice idea of the state of the area, and while the dev might have found some of the issues himself, I was glad he didn't. It felt like we were actually working together, instead of being forced to be the ones who told the developer that his best attempt on testing just did not do the trick.
Towards the end of the session I realized there was an opportunity to invite the developer to listen in to us debriefing what we had covered, and he seemed happy to join. In a short meeting, we told what we had covered and identified as areas of more focus. And agreed on how to go forward.
It was a great experience. The right timing, the right collaboration. And left me wondering: why don't we manage to do more of this? But the story of this experience worked great on the manager who tends to think that saving my time is more important than great flow of collaboration. So, I'm hopeful.
