I would like to get your views on just how technical a Tester should be when logging a bug. My mantra has always been to provide the Developers with as much information as I can in order to help them debug the issue. This would generally include a summary of the issue and relevant test items (screenshots/steps to reproduce/reference numbers etc).
This is all fine, but sometimes I will go a bit deeper, for example if I discover a layout issue I may include a note suggesting a fix, eg: set margin-left: 1px for #thisID.
Is this good practice or am I stepping on the Developerās toes? Iām trying to be helpful but Iām aware that this could be misconstrued as telling them how to do their job.
It depends on the devs. Some welcome the deep research and appreciate you saving them time and effort. Othersā¦ donāt.
Iād recommend you do what works for the dev whoās most likely to get tasked with the fix, if you can. The other recommendation Iād make is not to be prescriptive about your suggested fixes, because if they turn out to be a red herring, the devs are more likely to be unhappy about it than if you hadnāt suggested anything.
Iāve found that language like āThis looks a lot like issue X, which was caused by problem Y. This might be a good place to start lookingā tends to work better than āThis is a recurrence of issue Xā, just in case it itās a different problem with very similar symptoms.
Like @katepaulk said, it does depend on the dev.
3 examples:
I had a dev once where certain types of issues would be met with resistance. But if I talked to him first about the issue, typically with a demonstration and asking him if that is how the functionality should work, then I could either make the issue official or let him fix it outside of the Jira (which is what we used for bug tracking) system.
Different dev, I could post a potential fix and be guaranteed that that fix is NOT the one which would be implemented. From him, I learned that suggesting a fix was not a good thing for that team (saving me a lot of time in the process)
Yet another dev. If I didnāt suggest a potential fix, getting a fix at all would be like pulling teeth. Often I would have to get a system architect or another dev to help him with the issue. But suggesting a fix would at least point him in the right direction.
In all of those cases, talking with your team prior to posting about the issue would save a lot of time, trouble and documentation. Especially in cases where:
You are confused about how the functionality should work (Or wrong)
It is a simple fix (the fix takes less time than writing about the issue)
The issue is complicated (talking about it reveals details which donāt come over in writing)
Backlog items donāt typically get attention
Getting a fix is more important than reporting metrics
I agree that how detailed you should get depends on the developer you are reporting to. Some get it from steps, result and expected result. Some need a video. Still, I think you should stay out of suggesting a solution, even if you know one. Why? Because of a number of reasons:
Your solution might not be the only one and therefore the best one.
When you deliver solution, your developer might stop thinking and start doing (really dangerous for juniors).
When you include a solution you might skip some important facts in your description of the issue, because you feel it is clear from the solution description.
In my team we call this: Solution mode. We donāt appreciate when our more technical customers do it. For the sake of a successful long term cooperation, we should be given a full description of the issue and be left to think about the best solution on our own. Think about a new developer in the team. They might need more time to solve some issues at the begging, but will be much faster later on when they get to know the software, domain, team members etc.
Totally depends on the context you are into. I am referring to the team members you are working with, their attitude, their rapport with you or vice-versa and many other attributes which helps in deciding how you need to go about your bug reporting. Either ways, you just need to be professional and I personally do not think that its bad to suggest a fix. If I were a developer, and you said āMaybe this fix helps?ā I would be happy to see a tester like you.
Now, how you suggest matters a lot. It can be blunt, or it can be very pleasant.
Blunt --> "Fix this using set margin-left: 1px"
Pleasant --> āMaybe set margin-left: 1px helps?ā What do you think?
By asking āWhat do you think?ā you are valuing the developers view and you are taking his / her opinion. This makes it team work and also this kind of communication helps better team relationships in my view.
I really like what youāve shared, @santhosh.tuppad! Iām a big fan of āWhat do you think?ā. Itās such an incredibly inviting and collaborative question.
Thanks And also I usually use those questions that you have listed in experimentation in different contexts. Thanks for sharing!
āWhat do you think?ā was just one of the example. Basically, āQuestioningā helps and these questions should be mixed with respect and kindness ingredients.
Iāve had similar issues where I had to get it right depending on the team or person I was working with.
In one company it was frowned upon for testers to even suggest a fix.
If you could include logs or so that was fine but no suggestion of a fix.
In another place I have been sent bugs back because they were missing the solution. Which baffled me.
The main thing I learned was to talk to the team and ask them which approach works for them.
Itās been quite interesting to learn who likes to work how.
Like everyone else said, depends on the team. As an embedded test engineer, itās not uncommon for my investigation to lead me from the logs/stacktrace to the code, and often include the specific method, line, etc in tickets I enter.
In your example, if you HAD to write the bug report first (e.g. developer wasnāt in the office, or isnāt immediately available to you) then I would perhaps include all of your investigation, logs etc in the bug report.
In terms of opinions on what the problem may be or how to fix it, Iād always leave this to face to face discussion and then put it into the bug ticket afterwards. There have been a few times where Iāve been SURE that the problem exists in area A and Iāve included it in emails/reports and when a developer has looked at it, theyāve found the problem is actually in area Z.
I try to avoid writing bug reports where possible. Any bugs I find Iāve been speaking to developers about and getting them fixed there and then. Of course, bug reports are still important for functionality which a) isnāt currently in development (existing features) and b) are complex and āunimportantā.
If you are avoiding bug reports, how does your team keep track of past bugs? At the current company I am at, getting a dev to talk to you can be difficult because they tend to be very busy. So it leads to a situation where itās like their work is thrown over a wall to me when it needs to be tested. Itās not a situation I like to say the least.
Whoaā¦ donāt turn it off your āSolution Modeā just modify it to suit the dev your working with.
Example: Dev turns around to me test analyst and mumbles something about a production issue after a release. We had a very good relationship then but trust me it took time to get there. Sitting beside me was the system QA expert but he asked me. I told him it was XYZ and this was because of 123. He couldnāt replicate but trusted my knowledge based on all our past experiences (I donāt give an answer unless I am 100% sure). He came back about 1hr later to let me know this was confirmed with business/production.
Example: Dev who I have an limited relationship with mentions a bug in stand up and I offer a solution based on historical information/experience. He looks at me like I have sprouted a second head out of my neck and instantly dismisses my comments as irrelevant. He then goes back, wastes 2 or 3 hrs chasing his tail and came up with the same conclusion. Next day he mentions this in stand up and honestly he just lost a little bit of street cred by wasting so much time on a previously identified issue. But that is his issue not mine having said that this is NOT the way to make friends and influence people as it literally took nearly 2 years before we had the same relationship as described above. I was very green about tester - developer relationships way back then.
Nowadays,when we have Agile! Agile! scrum teams around the globe and scrum teams expect technical testers- a self-organised with automation + performance +security testing skills.Moreover,as JIRA is being used for stories,issues as well bugs,so in Agile world,new style of bug description has come up :Scrum masters/product owners everyone speak agile language and expect the same from testers ,for example,some use Gherkin syntax (GIVENā¦WHENā¦THEN) to write bug description similar to stories and attach any logs/screenshots along with it.Agile world - everyone is called ādeveloperā in the team
I write bug reports currently for bugs which are not deemed important enough to fix at the development stage. For example - bugs with existing functionality, UI bugs which will not stop the feature being shipped etc.
Iād like to get away from this, because I find that the bugs sit there for months/years, so why waste the time writing them up? Iāve floated the idea of having a bug expiration data - so if a bug isnāt fixed within 6 months, it is automatically removed from our planning board.
I was speaking to someone at a recent meetup who have a āzero bug policyā - meaning that they donāt raise any bugs at all. If it is discussed with the team at the development stage and isnāt deemed important enough to fix then they donāt raise it at all. They still have āsession notesā with all the information, but no bug/defect is logged in Jira etc. I never got the chance to ask how this works with pre-existing functionality/customer reported bugs.
Either way, Iāve found much more success in getting bugs fixed by talking directly to developers, even the small bugs. If they have the code open in front of them and Iām explaining the problem then thereās a high chance it is getting fixed there and then.
Nice to read in the part of the world you work in, Agile is completely applied. Canāt wait till the rest of the world catches up to the kind of environment you are accustomed to. I am a big supporter of Agile methodology in itās purist form but unfortunately here, most companies apply a combination of previous methodology to the newly adopted Agile/Lean/Scrum.
If Iām in any doubt as to whether I am looking at a bug or a feature, or if I suspect my understanding of the functionality may be suspect, Iāll talk to the dev and if necessary ask āDo you want me to raise that as a bug?ā. Otherwise, Iāll raise the bug, if only to get it written down whilst my memory is still fresh (especially in terms of the steps to replicate); and then Iāll go and talk to the dev - or if theyāre not available or working remotely, send them a personal e-mail (as opposed to the automatic one theyāll get from our bug tracking software), if necessary putting the bug tracker number in the subject line and the request READ THIS FIRST! in large friendly letters.
I think the āwhat do you thinkā is a great thing to do - even better if it can be done face to face or on the phone vs. a ticket/email. One thing I find often happens is the interpretation of written updates can end up causing unnecessary issues between teams. More talking will not only foster better communication but also a level of trust and team work. I also recommend using any screen recording tools vs. screen shots - having the likes of Problem Step Recorder running in the background sometimes helps to show the steps taken better than screen shots.
