As a tester, I provide a service. As a person, I provide this service because I enjoy it - often very much. There's a but - it seems some developers have the ability to take all joy out of testing work. I had an experience like that today.
I reported an issue on a feature we had just been working on, that had a similar consistency within product issue fixed since last week. The fix moved the problem elsewhere, and I thought to be helpful, and let the developer know of the problem.
The first issue had been raised by the team's architect and the developer gave up under pressure on his idea that while for the rest of the product we aim for polished and finished experience, on his first feature on this product / technology we would not.
The reaction to the issue I raised probably got all the steam that had been building under the hood, and the response was much stronger: fixing this would be a waste of his time. I explained, that if we, as the team, indeed think that this type of an issue is waste of time, I'm happy to not report issues like that. But as far as my experience with the product, we have had the habit of fixing these issues and I'm happy to change that practice, but the rules should be for the product - at least similar features within the product. He agreed on a compromise from his point of view: if our GUI designer thought it should be fixed, he'd fix it. He would prefer waiting to see if real users see that as a problem, implying that what ever I did was something a user he can think of and cares of would not do.
An hour later, the GUI designer had taken a look at the problem, and said it should be fixed. So I suppose it will.
There's testing that is fun - creative, intellectually challenging and that makes me feel useful. Fighting about information that isn't wanted isn't exactly fun. Finding same problem step after step in the effort of fixing a problem instead of the mentioned symptom isn't exactly fun. One skill that I feel I've built over the years is to try to find the fun way of doing the things where developers see no fun - much of the absolutely necessary testing falls into that category.
I remember many testing courses and conferences, where I've been educated (and educating) on how to be considerate towards the developers. How to report bugs in a non-judgemental way, how to discuss things face to face rather than resorting to passing messages through the bug tracking system. Today I'm wondering about the extent that kind of skills are taught to developers. I'm trying to provide a service, but my service usually does not include accepting insults, belittling or swearing. I find it amazing that there still are people who might think that this would be acceptable behavior. Luckily, my two examples are both older. I can put my faith into the future generations of developers, who treat colleagues in teams with respect, right?
Another lesson I'd love to see more of my developer team mates catching is that while comparing an hour of end user time and team time, we may actually see more value for the end user time if it is not used on serving our needs. The end user might actually be able to do his job - like selling our product - if he wasn't always busy letting us know that he could not really do what he was trying to do. And seriously, users are not necessary happy even if they don't complain. Workarounds allow them to do what they tried, but is that really what we wanted to offer, a workaround to get the thing done that we were trying to implement for real? Who wants to drive their software development with the idea of "let's just react to problems when users see them"? I hope that too is a thing of the past.
I reported an issue on a feature we had just been working on, that had a similar consistency within product issue fixed since last week. The fix moved the problem elsewhere, and I thought to be helpful, and let the developer know of the problem.
The first issue had been raised by the team's architect and the developer gave up under pressure on his idea that while for the rest of the product we aim for polished and finished experience, on his first feature on this product / technology we would not.
The reaction to the issue I raised probably got all the steam that had been building under the hood, and the response was much stronger: fixing this would be a waste of his time. I explained, that if we, as the team, indeed think that this type of an issue is waste of time, I'm happy to not report issues like that. But as far as my experience with the product, we have had the habit of fixing these issues and I'm happy to change that practice, but the rules should be for the product - at least similar features within the product. He agreed on a compromise from his point of view: if our GUI designer thought it should be fixed, he'd fix it. He would prefer waiting to see if real users see that as a problem, implying that what ever I did was something a user he can think of and cares of would not do.
An hour later, the GUI designer had taken a look at the problem, and said it should be fixed. So I suppose it will.
There's testing that is fun - creative, intellectually challenging and that makes me feel useful. Fighting about information that isn't wanted isn't exactly fun. Finding same problem step after step in the effort of fixing a problem instead of the mentioned symptom isn't exactly fun. One skill that I feel I've built over the years is to try to find the fun way of doing the things where developers see no fun - much of the absolutely necessary testing falls into that category.
I remember many testing courses and conferences, where I've been educated (and educating) on how to be considerate towards the developers. How to report bugs in a non-judgemental way, how to discuss things face to face rather than resorting to passing messages through the bug tracking system. Today I'm wondering about the extent that kind of skills are taught to developers. I'm trying to provide a service, but my service usually does not include accepting insults, belittling or swearing. I find it amazing that there still are people who might think that this would be acceptable behavior. Luckily, my two examples are both older. I can put my faith into the future generations of developers, who treat colleagues in teams with respect, right?
Another lesson I'd love to see more of my developer team mates catching is that while comparing an hour of end user time and team time, we may actually see more value for the end user time if it is not used on serving our needs. The end user might actually be able to do his job - like selling our product - if he wasn't always busy letting us know that he could not really do what he was trying to do. And seriously, users are not necessary happy even if they don't complain. Workarounds allow them to do what they tried, but is that really what we wanted to offer, a workaround to get the thing done that we were trying to implement for real? Who wants to drive their software development with the idea of "let's just react to problems when users see them"? I hope that too is a thing of the past.
