The little thing that made my week

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.    

Careers on coffee table

Coffee discussions seem be good food for thought. My company / colleagues have a principle of not talking about work, so we talk about all sorts of things - sometimes related to work. Today the topic turned out to be career - or sense of missing one completely.

As the remark of no career for a colleague made me curious, I had to ask how he defines career. With the answer, I learned that he joined the company (medium sized company) quite a number of years ago, same time with other people still in the company as a summer trainee. He felt he did the same job as programmer then and he does the same job now, whereas the other people who joined (traditional engineers) have had first more responsibilities in design and customer relationships, and later become managers. And he keeps on coding.

This left me wondering how strongly the idea sticks of career ladders always leading to management positions. And, how differently we perceive career - in particular the personal responsibility to one's career instead of waiting for it to land from somewhere outside.

Personally, I've felt making progress in my career for many reasons - ability to learn and to turn the learning into more effective (team)work in development being a core to it. The discussion made me dig out a slide I put together years ago on how I perceived career back then.

Looking at the categories I put together to make sense of my career, I feel the same things still make me feel I'm actually on path. First of all, I love the impact I have on results as the team's tester. I enjoy being recognized for making a difference, and I've seen ways of making the results of the team something I've enjoyed keeping on my personal agenda, where ever I work. Another core of my personal sense of career is that I'm not at a dead end, I have choices, and I actively take them. Money on the other hand is not so important to me. And again today, we came to discuss that it is really more of a relational aspect, a measure of respect for my contribution in the organization than an absolute of more is better.

For me career is good use of my time - work is such a big portion of life (and fun too!) - in a way that I feel is taking me forward. But the discussion today left me thinking: what if you feel you are not going forward? Is that true (all programming problems are same?) or just a perception? And does it actually rise from the idea of externalizing the responsibility of our career to a manager handed over to us by the organization? And since all my colleagues deserve to be happy and satisfied, is there anything I can do to help them?

Sharpening the sharp minds

A bunch of nice people got together for lunch yesterday to talk about software development. From the discussion opener ideas, we picked up the idea that testing (amongst other things) could be failure demand, that is, creating need for more of it because of suboptimization within the value chain.

That topic is probably worth a post on it's own, but for the purposes of this post, it gives me a trigger to think of things I do. I work as a tester in my teams. And as I was reminded of yesterday in late hours of team building, a catalyst for change, a voice of concerns people are afraid to speak out on and a source of team motivation (wow, I feel appreciated) as they succeed and can change things for better with the feedback. But what I try to avoid is suboptimization.

As much as I love testing (for a good reason!) I don't think the more the better. Doing testing that concludes a broken product works - if I just close my eyes tight enough - isn't helping my team except to cover their ass by saying the task was done, three days was used. Adding testers to a project where we have too little time for fixing isn't helping us either. And it might just be smarter to invest in an architectural rewrite than another tester working on the swamp that we all know will keep failing. We can all care for the flow with our special skills.

Eventually, I believe software creation requires a group of sharp minds. And a task I particularly enjoy picking up is helping to sharpen the minds. With this inspiration in mind, I'm bringing in people to wake us up. To help us stay awake. And to give us ideas that take us forward. I organize trainings and discussions.

Is that testing? To me yes, as I get the ideas of needs from testing and information gathering needs for my testing tasks. I don't really care for the categorization but on the fact that I can help my team members to create less 'failure demand' for me to test on. Play your strengths - a love of people and connecting communities is one I bring to the table in addition to sharp mind and picky eyes. What's yours?