Quality Sense Podcast: Mukta Sharma- Defect Management

Welcome to another episode of the Quality Sense podcast! Today’s guest is Mukta Sharma, she’s been in the world of testing for over a decade and is very active on social media where she shares her knowledge with her community.

In this episode, we’ll discuss Defect Management,  the importance of collaboration and communication when raising bugs, we’ll give some advice to people starting in the testing world on how to create a good and useful LinkedIn profile, and more. So get comfortable and enjoy the episode!

Episode Highlights

• The importance of Defect Management
• Best practices when reporting a bug
• The importance of Communication
• Building a professional social media profile

Relevant Links

Follow Mukta on LinkedIn
Follow Mukta on Twitter

Listen Here

Episode Transcript

Federico:

So hello, Mukta. It’s a pleasure for me to have you here in the show. How are you doing today?

Mukta:

Hi, Federico. Good morning. I am doing very well, thank you. How are you?

Federico:

I’m great. Thank you for asking. I have a lot of questions for you. I love the opportunity to meet people from other parts of the world. You live in London, I am here in California, and we have the chance to share experiences and learn from each other. I think this is fantastic.

Mukta:

Yeah, Federico, even I am looking forward to our discussion today.

Federico:

So my first question related to one of the topics we wanted to visit today, what’s your view on defect management? How important is it in order to have a good delivery process?

Mukta:

I think as a tester, Federico, this is very, very important aspect of software testing, because as a tester, when I’m testing any software, any application, if I come across any defects, irrespective of the priority and severity, it is important to bring them on the table, to let the developers know about it, because that is how you are contributing in improving the quality of a system.

So defects are very important. If it is low priority, high priority, if it’s cosmetic defect, you should raise it. And like this morning only, I made a post on my profile, on my LinkedIn profile, like, “If you come across any bug while testing a particular user story, and it is not related to that particular user story, then what you should do? Should you raise it or ignore it? So what will be your action item as a tester?”

And I would say we should always raise a bug. Even if it is related to a user story, it’s good. If it is not related to a user story, then also, we should raise it after discussing it with senior person or with the confirmation from BA, business analyst, and then we should raise it. And then the user story, we can add it as a comment stating that, “We found this bug while testing so-and-so user story,” and then assign it to a developer, because that is how we can contribute in improving the quality of a system. That is what I do, I have been doing over the years, and that is what I believe in, also.

Federico:

Yeah, probably it’s one of the main points of collaboration between the developers and testers, right? You mentioned a couple of things that I remember having different conversations with some customers, or with some colleagues about not only when, but also where, should I report a defect? For instance, if I’m working on a story, a specific user story, and I find a bug associated with it, should it be a different ticket on the issue tracking system, or is it okay to describe it as in a comment on the same user story, on the same ticket? Do you know what I mean? Does it make sense for you?

Mukta:

Yeah, yeah. Yeah, so what I think in this particular scenario is, if the bug is outside the user story, then you should raise it, giving the bug ID. And in this particular user story, which you are testing in that, you should add a comment stating that this was the bug that you found, but this lies outside the area of testing, if that is what you mean. You want to say, you have found a bug outside the user story, so should you raise it or not? So my answer would be, yes, you should raise it, but not with that user story. It should be raised as a separate bug, but it should be added with a comment.

Federico:

Oh, okay. Makes sense, makes sense. Yeah, another thing I remember talking with someone was, I remember this particular tester that, she used to decide when to write about, and according to the priority, instead of discussing with the team and agreeing in which bugs are important and which ones not. She decided to file only the bugs that she considered important. What do you think about this approach?

Mukta:

I think as a tester, first of all, we should have sufficient knowledge of the application which we are testing. What are the critical areas? What can be the impacted areas of that application? And then depending upon our knowledge, we should consider the bugs priority. I think to raise only important bugs, in my opinion, is not a very good approach, because maybe we are losing some bugs which may not be important, but which might be causing some loss to the organization, or which might be reducing the value to the organization.

So I think if we find any bugs which are of less importance, we should discuss it with other persons, like BA person, or scrum master, or maybe that time, we can discuss with developers if we are not very sure. But we should not only rely on only the important bugs. Sometimes, cosmetic bugs are also very cost-effective.

Federico:

Yeah, collaboration is key there. It’s like having other perspectives, because typically, we don’t have the full picture. Typically, testers, I think we need to have a broader, a wider, view on the quality, on the business, on the product, but maybe we are missing something, and having these type of conversations with other people in the team, and maybe also a product owner, or not only the developers, but also people with more knowledge about the business, can help us to decide which things are important or not. Yeah, I totally agree with what you said.

Mukta:

And having said that, you are right. Sometimes, developers may also reject our bug. So in that case, you should not be agreeing with developers. You can also discuss with product owners in that case. Maybe developers may not be aware of the … he may not aware of what you have actually found, so you should discuss with the product owner to have the full understanding, and maybe product owner will approve your bug. So in that case, it’s a win-win for you.

Federico:

Yeah, totally. And you mentioned another important thing, what to do when a developer rejects your defect, right?

Mukta:

Yeah.

Federico:

Is that something that happens to you?

Mukta:

It has happened with me in the past, and there could be many reasons why a developer rejects your bug. First, you have not provided enough sufficient information to him so that he can replicate a bug. Second, maybe, again, the miscommunication happened. So in that case, what I would say and what I have done, first, have a call with developer, try to make him understand the scenario in which you have found a bug, prepare a nice bug report, or whatever tool you are using to raise that bug. So you should have all the information related to that bug like, first, the title should specify the screen name or the page name where the bug has actually occurred, then what is the priority and severity of the bug, then what is the environment in which you have found the bug? Is it QA environment? Is it test environment? Is it UAT environment? So that is very important environment you should mention.

And next is test data. Sometimes, as a tester, we forget to provide test data, and when developer tries to replicate a bug, he’s using some other test data. For this reason, he might not be able to reproduce the bug. So to provide the test data is very important. That will help him in exactly replicating the issue which you have found.

Then you can also provide environment details like configuration, which operating system, and which browser you are using for testing so that he can also replicate the same thing, and then steps to repro, or steps you have performed in order to get to the bug. And what are the impacted areas? If you have good knowledge about the product, if you have good knowledge about the application which you are testing, then you must be aware of the impacted areas. What all areas are affected because of this bug? If the bug doesn’t get fixed, then what could happen? What are the risk areas?

So that, also, you should include in your tool, or whatever, in your report, and then give it to developer. Then tell him politely to go through everything, and if he’s not able to understand anything out of that bug report, then have a call with him, share your desktop, and then replicate the issue in front of him. That should help. That should resolve the issue. Sometimes, most of the time, this helps, actually.

Federico:

Yeah, it’s about clarification, it’s … I remember I have a friend who used to say that things are never clear enough. You can always improve the clarity of what you are trying to say, and looking for ways to improve that, it’s a very important part of our work.

Mukta:

And because as a tester, we should be contributing … we should be providing some value to the project, and as our developer, he’s also doing his duties, so at that point of time, we should work as a team. So if he or she developer is not able to understand anything what you have documented, then definitely, you should take initiative and make him or her understand that that is how the bug was reproduced, and this is a scenario exactly what you did, what all steps you performed.

And sometimes, what happens, developer ask you, “Can you reproduce it in front of me?” So that time, you should do that and take his inputs also, so that both of you can work as a team and can face the issue, and then he can resolve the issue. And once he resolves the issue, then again, it will come back to you for retesting, and when you do retest, then maybe you are able to close the bug. And so when you’re closing the bug, it’s good, then go ahead with your next and proceed further for the testing.

Federico:

Yeah, totally. Something that’s been helpful for me also is going to those meetings with a developer or someone else in your team, not only to try to explain how I’m correct, and this is a bug, and you should accept it as a bug, but also with an open mind, trying to understand, to learn more about the system, or about the particular situation, or something like this. And maybe it’s not a bug, or maybe I misunderstood something, but for sure, I will learn, and we will learn, and we will be able to do a better job from now on, right?

Mukta:

Right, and considering one more scenario similar to this, what happens sometimes, like when we discuss with developers, we get to know that we missed something.

Federico:

Yeah, exactly.

Mukta:

So that was consider, and there is no harm in admitting your mistake if you’re doing something wrong. It should not be on your ego, and we should not take it personally when our developer rejects your bug. It’s work, and we are working, we are giving our best, everybody is trying to give their best in their work, so if a developer rejects your bug, then I would say have a clear communication, open communication, have an open mindset, and then if it comes out that it is not a bug, then please accept it, we should accept it, and just move on with your testing.

Federico:

Yeah, and now that you mentioned that, maybe another part of the communication that we need to pay attention to is the tone, or the way we communicate in order to avoid hurting someone’s feelings. Do you have any recommendation related to that?

Mukta:

I personally very much emphasize on the tone that we speak in, and the words that we use to speak, because I think words can make or break a situation. And in professional world, this is very important, the way we communicate our thoughts and ideas to others, because you are not seeing the person in … face-to-face meetings are not happening these days, so this is just virtual meetings happening. So only through your tone of the communication, and the words that you use while communication, makes a big difference. So yeah, it should be taken into consideration.

And also, the level of the person also should be taken into account. If you’re talking to your peer, if you’re talking to a junior person, then how you should be talking, what the team … and the tone can be little friendly a casual way, but if you’re talking to product owner or some stakeholders, then you should be very professional, and your tone also should be in that professional way, very business-oriented, so that the communication can progress further.

Federico:

Yeah, totally. We have to take into account different things about our context. I’m thinking now, if we are in a hurry, a lot of pressure in the middle of trying to release the new version, or a bug fix, or something, is not the same than a normal situation when we are just starting to sprint or something like this. And having this type of considerations, and align our communication and our work to that, it’s also important, I guess.

Mukta:

Yeah, sometimes, Federico, what happens, suppose there is a sprint ending, and you find a bug in the end of the sprint, and all of a sudden, you start panicking. So that way, it’s normal scenario. It can happen with everybody. So that way, we should keep our mind calm and then look for these solutions. How can we solve this solution? Instead of starting blame game, we should analyze the situation that, it’s the end of the sprint. Now, how we should resolve the issue so that … Or we can discuss with our manager, or we can discuss with the senior person, can it differ, or should it be immediately fixed?

Federico:

Yeah, totally, because we all have the same goal, which is deliver best-quality software. So yeah, totally. I have another question related to that topic. According to your experience, what’s the most common mistake you have seen in defect management in testers?

Mukta:

So as per my experience, what I have seen, and in fact, what I have done also in the beginning of my career, is a lack of communication. So when you find a bug, you are documenting it. Sometimes, we miss some important parts, like we forget to provide test data if you’re using JSON Payload in your script, and you forgot to mention that, then again, it creates … developer not able to reproduce a bug. So miscommunication, or lack of communication, happens. From, I’m a tester, so I would say tester side, so we should keep this thing in mind that we should provide as detailed information as possible to developers so that it can help them in reproducing the issue so that they can fix it also.

Federico:

Yeah, definitely. Another thing that I’ve seen is that you are sharing a lot on social media related to how to prepare your resume or your LinkedIn profile, in order to apply for a specific position as a software tester. Can you share what you typically suggest to testers about that?

Mukta:

Yeah, sure, Federico. Actually, I found my previous two jobs because of my LinkedIn profile. So yeah, I would like to say create your LinkedIn profile as detailed as possible, because recruiters will look at your profile, and then you will get more job opportunities. And what we do generally, we create our profile on LinkedIn, we add all our skills, and years of numbers of experience, and the companies with which we have worked, but we don’t update it frequently.

If I’m working with a company today, and if I left the company after three years, what did I do in those three years? Have you written your main responsibilities in your LinkedIn profile? If it is not there, that means you are missing something important, you are not catching recruiters’ attention. So you should mention your main core responsibilities which you have done in the organization while working on so-and-so projects. This is one. Second, keep updating your profile. It’s not like you have updated today, and then you have left your profile just like that for 60 days. No. Update your profile once in a month, be it anything, any small skill, any change in responsibility. So we should keep updating our skillset.

Also, one more thing I wanted to say, the domains. Whatever domains you have worked with, so mention that in your LinkedIn profile. And now, LinkedIn has come up with some badges, like open to work, and if somebody’s hiring for jobs, then you can use that badge on your profile. So if you’re looking for job opportunities, use that badge, open to jobs, so that when recruiters are looking for any candidates, they will see that, “Okay, this candidate is looking for jobs, and let’s see if the profile matches to what we are looking for,” and if it matches, then they will send you a message, they will send you an email, so that you can take further action.

Federico:

It’s important to continue learning. There are tons of free resources out there, so this is a way to learn something new. And what you mentioned, it’s important to reflect that on your LinkedIn profile, right?

Mukta:

Yes, but I would like to just add one thing. So-

Federico:

Yeah, go ahead.

Mukta:

If anybody is in the same career as me, if you are a tester, and if you think you can take some tips from me, if you can learn from my experience, then you can approach me on LinkedIn. I’m more active on LinkedIn rather than other social media platforms like Twitter and other stuff. So you can approach me on LinkedIn, we can connect, and then I’m very well happy to share my thoughts, my knowledge, with you, if that’s helpful to you.

Federico:

That’s excellent. Thank you so much. It’s been a pleasure to have you here in the show, and thank you for all the thoughts, and tips, and everything you’ve shared.

Mukta:

Thank you so much, Federico, and it was great talking to you. Thank you.

Federico:

Bye-bye.

Mukta:

Bye-bye.