What should a Software Tester do to become more valuable and helpful for the Development Team?

Question

When I write detailed defect descriptions or bug reports, then my team's Development manager feels satisfied. What are few things a blackbox tester can do to help the Developers become more productive and fix the defects easily?

One thing I observed that made my Development team concerned was when I reported important bugs just a week before the Production release and after the code had been freezed.

Also, when I did retesting of a bug fix in the new build and failed it and after the 2nd time the bug was fixed by developers, I again found a symptom of the same bug, which I missed and should have found earlier.

I have noticed that the Dev team doesn't appreciate these things as They always defer the late found bugs to the next release, am I being ineffective over here?

Thus, what exactly do good and experienced developers really expect from the QA team? How can we Testers create more value for developers working in the same project team?

Answer 1

It is very admirable for you to consider a tester's role from this perspective.

The hard cold fact:

• No one is happy when there is a bug found in their code. Imagine yourself as a developer, you have done coding, you have done unit testing and you feel pretty good when you check in your code. How would you feel when someone shows up shortly before code release and tells you your work is not good enough.
• It is a common reaction for a developer to be defensive; a defensive mentality has two manifestations: 1, it is not a bug; 2, a tester could have told me earlier.

How does a tester handle this kind of situation?

You mentioned that you discovered bugs shortly before code release and / or code freeze, your development became very concerned.

• It is inevitable; you do not have complete control over when you discover a bug. Before code is frozen or marked ready for release, are you consulted? Testers should be consulted before code is frozen or marked ready for release. If you are not consulted, you should make a recommendation to change it. And yes, in some culture or some companies, it is not possible to change it. (There is a chance that your release management is not well organized, but without further details, it is merely my speculation.)

You mentioned that your development team does not appreciate your effectiveness as a tester when you found a new symptom of the same bug.

• It could have been a different bug or the same bug that had been partially fixed. If it was a new bug, then it was your credit to find it, you did your job. If it was as the developers claimed, the same bug that was only partially discovered and hence partially fixed, it does not mean you have not done a good job. Remember it is not possible to discover all the bugs. Everyone misses something. The solution is to improve how you communicate with developers.
• One effective way to point out there is a bug in their code is to sandwich this bad news within two pieces of good news. For example, when a bug is discovered; go to your developers right away, start this conversation by saying: I like your code, it does its job beautifully. When your developers are not in defensive mode, bring out the bug; then make a compliment to finish off this conversation. Gradualy over time, developers will not consider you as their mortal enemy but a helper.

There is one question I want to clarify:

• When i write detailed defect description or bug reports, then my team's Development manager feels satisfied...., who are you sending your bug reports to directly? The developer who owns this piece of code or your manager? I have seen managers who cause unnecessary delay and misunderstanding between QA and Dev. Ideally, a bug report should be sent to its developer directly, of course, in some companies, managers want to read them first so that they can do prioritization and etc.

Answer 2

For testers to become more valuable and helpful for the development team...

Focus on helping developers earlier in the process

Focus on adding value much earlier in the process. Focus on working with developers before and as the code is being written, not after it has been deployed in a testing/staging environment. This will help change your role from a critic to a helper.

Practical ways to achieve this change:

• Attend sprint planning meetings and give inputs on quality issues in the meetings
• Maintain a variety of browsers and mobile devices that are used by the target audience so that they can be used by QE or developers as needed.
• Attend stand-up and listen for tickets that you feel would benefit from QA / testing and then seek out the developer who has the ticket and ask to pair with them.
• Ensure that you have management support for working earlier in the process with developers. Typically this means that you report to and are supported by the director of development, NOT just the lead programmer, architect or programming team leader.
• Evangelize Quality Assurance / Quality Engineering with Lunch and Learns, Demo's and Presentations.
• Look to provide input before the formal code Pull Request is release, not afterwards.
• Continue to develop your practical technical skills. You will get more respect from developers if you have the ability to:
  • search and parse server logs
  • perform SQL queries
  • browse through and understand source code
• Continue to develop your technical knowledge in
  • programming principles
  • quality engineering principles
  • user experience, usability and accessibility
  • design principles

I'm a former developer and the above reflects my experience.
Hearing from QA once I finally have the code finished is quite annoying. Having them work through a test plan or break out a mobile device or IE browser on the spot to check out development still in progress was helpful and more welcomed by me.

Answer 3

From the perspective of a developer,

I am a freelance developer, and as such I work with many different QA setups. From one guy testing everything to full teams of people checking down other teams of people's work. I am usually either the only developer or in a "management" type position (Dev manager, Lead Dev etc.) I only mention that as it's important to know "what side of the isle" I'm on.

First, and most important QA plays a vital role. I can write awesome code. But I can only write code to my understanding of the problem that I am trying to solve. If QA does nothing more then provide a different mind set, their value is already astronomical.

Here are some things you can do as a QA "person" that will really help.

• Understand that you are not a road block to release, but a step along the path. Too many times I have seen QA "people" get drunk with power, and "block" a release because of a bug or issue. Some times that happens, but more often then not it's about identifying issues then blocking a release. Specially on short release cycles, a list of "Known issues" is often better then no new features.
• Remember that you are a support role. The program is better for having you, no doubt about that, but your there to help the program become better. A lot of times QA people get the feeling that they are the keepers of the keys to the kingdom.
• It's not a damn score board I see this one a lot. QA people feel like they're doing their job better if they find more issues. This leads them to start finding all kinds of non-sense. I have received bug reports that say that a "address import" doesn't work because the user couldn't upload a JPG. I have also seen QA people submit a tiny little bug for every missed comma in text.
• Learn to use the issue tracker Hopefully the dev team your working with is using some kind of issue tracking system. Often times I see QA people not search the system and list the same issue several times, or put the issue in the obvious wrong place (like a web site issue in the desktop app category). Using the issue tracker correctly will help a lot.
• Report problems early Lets take a fake example. Monday and Tuesday I write new code, Wednesday and Thursday are devoted to clean up and maintenance. Friday is release to production. Don't wait till Thursday evening to dump 600 issues into the issue tracker (or even 1) it's too late. Instead, as I am writing code on Monday, you should be testing it. Your Thursday tasks should be going (in a perfect world) "yep that fixed it". If you do find issues on Thursday, you of course need to bring them up, but the goal is to be solving issues not finding new ones.
• When reporting issues, be verbose No developer that I know will ever get angry about having too much information. Tell us the problem, what you did to get there, what version, what branch, the error message, include screen shots, include stack traces if you have them, and what the expected output is. At the very least you should be able to say "When I do X, Y should happen, but instead Z happened." Too many times I have seen QA people go "It doesn't work" or "I got an error". But that is not enough for me to do anything with. Errors are supposed to be there. So was it a good error or a bad error.
• Know the program and the path A great many times, QA People will submit a "bug" because a feature changed, when the entire point of the release was to change the feature. For example if we say we want to limit uploads to 2 megs. Then QA needs to be aware of this change, and not submit a bug when their 5 Meg file fails to upload with a proper error. You also need to be aware of secondary changes. I will see a ton of reports like "phone numbers are causing validation errors" after a new feature of "support international phone numbers". Try to understand, the cause and effect of the changes being done to the application.
• ASK QUESTIONS at an appropriate time of course. One of the worst things you can do is walk up to the Dev people and go "is it supposed to do this?". One of the best things you can do is send an email, or a chat asking the exact same question.
• Support your dev team Many times, QA people say things that make them the enemy of dev. They don't really mean to, but they do it all the same. "I'm waiting on dev to fix the issue with the address upload." That's bad. "We are still addressing the issue with the address upload." That's good. As soon as you say something that makes the problem "dev's fault" it's a natural reaction to prove that it isn't. If instead you take a team approach, dev won't "have" to "throw you under the bus" to clear their name. It's a matter of leaving a way out. Maybe the address issue is that you tried to upload XLS instead of CSV. It's much better to get a ticket that says "XLS format not supported, try importing a CSV" then to have the response to an email chain be "QA is not testing the feature properly. The feature is CSV import, they are testing with an XLS. These are not the same thing."
• Think of your self as part of the bigger team A lot of times QA people tend to think of the selves as the Referee. There not. If dev is the offensive line, then QA is the defensive line, they have different goals but there all part of the SAME larger TEAM .

Answer 4

So, first, I think you have a management problem. It sounds to some degree like there's an "us against them" philosophy, where test is seen as an obstacle to release, not an integral part of the Development process. A good developer, in my experience, is fully aware that they're human, and will make mistakes. They understand that test is there to protect the end user, and both the developer and the tester are equally important to the overall effort. Things to look at include questions like is there a path for advancement for testers in your organization? Or is test seen as a way to get into development? If there isn't a path for testers to become senior testers, and have as much influence on the development process as a lead developer, that's probably a problem. If developers become defensive when you report defects, that's a problem. And it's not necessarily something you can solve without help from management. For example, if the developers are evaluated on how many defects are found in their code, then that's a recipe for a contentious relationship.

Second, since you're a black-box tester, you have an opportunity to understand the system as a whole better than any developer does. As a general statement, developers understand their area of expertise quite well, but they don't understand how their piece works with everything else, or with the surrounding infrastructure. This is often true of architects as well. You have an opportunity to become an expert in this, and a real advocate for the end user.

Third, just like developers aren't perfect, neither are testers. That's why you shouldn't be just testing code. Your job, along with everyone else's, should be improving the process to make defects less likely to end up in the code, and more likely to be found when they do. Sometimes, this means writing code so that it's easy to test. What process you're using, waterfall vs. agile, doesn't matter. What does matter is that you look for places the process can be improved, and defect discovery can be done as early as possible. To take your example of bug rediscovery, why didn't the developers have unit testcases that could detect the bug, after you'd reported it the first time? Or if you found a symptom of a bigger problem, why didn't they realize the problem was bigger than it was? You're not the only person responsible for software quality.

And, finally, it's far better to find and report a bug, even if it's late in the cycle, than to not find the bug. Would you/they prefer it be found in the field? Note that this doesn't mean that it isn't sometimes/often appropriate to defer fixing a bug to the next release, but that decision should only be made after the impact of the defect is understood, along with the likelihood of hitting it. If it is a serious bug, then you should figure out why it wasn't found earlier. Was it because there were bunches of other bugs that were blocking finding this one? Was the bug introduced as a fix for another problem? Maybe having more people testing would surface bugs earlier.

Answer 5

Feels you are testing too late in the process. Focus on preventing defects and testing in parallel with coding.

I like how the Testing Manifesto puts it:

How you achieve this is too broad to answer here.

Update:

Waterfall or not you can still apply most of the idea's. Lets take preventing bugs. Instead of playing ping-pong with your developers you could ask them how they think this can be resolved? You better testing is not the issue since they could break something else with their changes. Meaning you would keep coming back, this is the issue, you keep finding issues in code they created.

I firmly believe part of being a good software developer is being a good tester.

-- John Sonmez

The developers are making the defects not the testers. I think you should teach the developers to be better testers, so you can focus on the big picture and not the details.

Answer 6

Most of the answers so far seem to be approaching this problem from the perspective of helping you deal with stubborn/grumpy developers when you find and report a bug. Lots of people have (correctly!) pointed out that the job QA/testers do is of huge importance to the success of a project and you certainly should not feel bad about raising issues, even if you find them late in a release cycle.

I would add a couple more points, from the perspective of a developer. I've worked with lots of testers, and I can't stress enough how much developers appreciate testers who submit good defect reports. The sorts of things that to me make a good defect report are:

• step-by-step guide to reproducing the problem
• screenshots showing the defective behaviour, especially for web apps
• expected behaviour
• actual behaviour
• any specific data you used to produce the bad behaviour
• versions of software / browser / etc. that you were using

Developers, like everyone else, ultimately want the product they're building to be wonderful and awesome, and while it can certainly affect the ego when bugs are found, it's obviously to everyone's benefit for bugs to be reported. That being said, when a defect report is submitted without sufficient data to reproduce the problem, it generates a ton of extra work for everyone involved.

I've certainly uttered my share of muttered curses against those darned testers finding bugs in my code, but when those testers make it as easy as possible for me to fix the problem, all is quickly forgiven.

Answer 7

Adding with the other answers,

A test engineer has to maintain a strong personality where he can introduce a new bug anytime because both developers and testers all know the fact that, either developing or testing can't be declared complete apparently! No tester can guarantee to catch all bugs earlier as like as no developer to write a perfect working code at once.

Rather it's a huge relief to find it before going to production! Even if it might go unfixed to current release but it's now a known issue to all. So in worst case, if a real user reports this issue then software team can ASAP fix this or declare this as 'known' rather start panicking!

There will be always scope for betterment of quality of product. If a tester remain strong to his statement and towards this view, then no developer or management can treat him/her like this going as unappreciated! We have to earn this through strength of our personality!

But again there might be fact that, to meet the the hard deadline management has to defer this bug to be fixed in the next release. This time tester has to be considerable enough. Because complaining about the fact is not always appropriate. Knowing the situation and adapt with it should be of great quality for both developer and tester to build/maintain a better software!

Answer 8

QA engineers in qa testing companies face this problem with development team if processes are not properly followed between teams.

The best way to reduce these type of problems is to use agile environment where there will be a process of meetings for every defined sprint. All the QA and Dev actions are done within the sprint cycle. Moreover, all the requirements are finalized before the sprint start date and QA team can write the test case during the development phase and use those test case for execution in the initial phase of testing. In this way, there will be less chances for missing any defect.

For the case if any defect is missed by chance and after getting the fix, QA team found more defect in the new build then it is quite obvious that something has been changed which was common to the working features and broken features. In this case, root cause analysis feature should be added to the fixed defect so that dev and QA team can make sure the root cause of the fixed defect and can do the fixing and testing accordingly.