Tuesday, November 24, 2015

Discomfort of defects

Last week, I was testing yet another new feature. And testing of it was very straighforward. First I tested to learn what the feature could do with simple data. Then I extended the data, and extended the variation I could bring in with the new feature. I made a few checklists to cover through relevant scenarios. It was about a day of work, nothing major.

I found 10 issues. That too is a very typical number. But what was atypical was that this time, probably because of business priority of the feature, all the bugs got fixed within one day.

As I was going through the fixes based on code commits and Jira notes, I noticed an interesting phenomenon. Only 1 out of the 10 issues I had raised had a comment. And the only comment was to say that I had found something that was _relevant_  - a mistake in how the code had been written.

There were 10 changes, so I would argue there were 10 items. But the developer, working towards no faults in his code, dismissed the other 9 and focused on the 1 as his personal feedback.

This again reminded me on how differently we think. For me, all 10 were relevant for the end user, and I really did not care whose fault it is that those exist. The developer worked against the idea that just-in-case he would ever need to defend himself, 9 of them were "new information he did not have when implementing the feature" and that he "had only one code defect".

We haven't classified things for anything but unfinished work for over a year, and still the culture of looking for one's own responsibility remains. There was no complaint on the other bugs, but the feeling can be seen in the comments - what gets acknowledged as "my bug" and what is just work on the list.


2 comments:

  1. That's an interesting subject that you raise here. It made me look back at my team and try to recall my developers' response to problems I found. My initial response was "Such thing does not happen on my team", but then some memories just came and showed me that I do get a similar response from certain developers quite often (something along the lines of "are you aware that what you are taking about is a new functionality?", or "my feature was focused on *this*...").

    What I wonder about is your analysis of the reasoning behind the comment - is "having to defend himself" a real thing people in your team are experiencing, or is it just leftovers from previous experiences (or even imaginary situations)?

    What would be your guess as to what could cause such an approach?

    ReplyDelete
    Replies
    1. These things are really either previous experiences or as my theory goes, what we get taught through previous people's folklore when being taught about this. I recognize a bunch of that types of things in testing too.

      Delete