Friday, February 3, 2017

Making my work invisible

Many years ago, I was working with a small team creating an internal tool. The team had four people in total. We had a customer, who was a programmer by trade so sometimes instead of needs and requirements, you'd get code. We had a full-time programmer taking the tool forward. We had a part- time project manager making sure things were progressing. And then there was me, as the half-time-allocation tester.

The full time programmer was such a nice fellow and I loved working with him. We developed this relationship where we'd meet on a daily basis just when he was coming back from lunch and I was thinking of going. And as we met, there was always this little ritual. He would tell me what he had been spending his time on, talking of some of the cool technical challenges he was solving. And I would tell him what I would test next because of what he just said.

I remember one day in particular. He had just introduced things that screamed concurrency, even through he never mentioned it. As I mentioned testing concurrency, he outright told me that he had considered that and it would be in vain. And as usual, with my half-time allocation, I had no time to immediately try go prove him wrong. So we met again the next day, and he told me that he had looked into concurrency and I was right, there were problems. But there isn't anymore. And then he proudly showed me some of the test automation he had created to make sure problems of that type would get caught.

It was all fine, I was finding problems and he was fixing them, and we worked well together.

Well, all was fine until we reached a milestone we called "system testing phase starts". Soon after that, the project manager activated his attention and came to talk to me about how he was concerned. "Maaret, I've heard you are a great tester, one of the best in Finland", he said. "Why aren't you finding bugs?", he continued? "Usually in this phase, according to metrics we should have many bugs already in the bug database, and the numbers I see are too low!", he concluded.

I couldn't help but smile with the start of how nicely my then manager had framed me as someone you can trust to do good work even if you wouldn't always understand all the things that go on, and I started telling the project manager how we have been testing continuously on system level before the official phase without logging bugs to a tool. And as I was explaining this, the full-time developer jumped into the discussion exclaiming that the collaboration we were having was one of the best things he had experienced, telling how things had been fixed as they had been created without a trace other than the commits to change things. And with the developer defending me, I was no longer being accused of "potentially bad testing".

The reason I think back to this story is that this week, I've again had a very nice close collaboration with my developers. This time I'm a full time tester, so I'm just as immersed into the feature as the others, but there's a lot of similarities. The feedback I give helps the developers shine. They get the credit for working software and they know they got there with my help. And again, there's no trace of my work - not a single written bug report, since I actively avoid creating any.

These days one thing is different. I've told the story of my past experiences to highlight how I work, and I have trust I did not even know I was missing back then.

The more invisible my work is, the more welcoming developers are to the feedback. And to be invisible, I need to be timely and relevant so that talking to me is a help, not a hindrance. 

2 comments:

  1. I really liked this story.
    However, what do you mean by "invisible"? Doesn't the fact that the developer was quick to come and "take your side" mean that what you did was very visible to him?

    I'm not sure how to name that ("encapsulation" comes to mind), but from what you describe, it looks as if what became invisible is testing as a separate, measureable activity, and it now looks like (and probably is) a seamless part of the code delivery itself.

    ReplyDelete
    Replies
    1. Invisible to managers is what I mean. Invisible as a separate activity. So intertwined that some people see that it could (and should) all be done by one person.

      Delete