How can developers improve relations with testers?

Question

Testers and developers don't always get along, which can lead to a lot of inefficiencies between testing activities and perform QA.

What can developers and other people do to make working with software testers easier, more productive and more enjoyable?

What can be done to make the testers job easier?

Answer 1

Good and Interesting question.

Here are some to make the tester's job easier:

1. Developers should perform basic testing before giving the product to the tester.
2. Include QA from the beginning of the project, not when the product is ready to test.
3. Work as a Team, not as two different departments [Developer & QA]
4. As the developer, never ask the QA to ignore bugs. It is QA's job to verify that bugs have been fixed.
5. Support the QA if they do not have a clear understanding of the product.
6. Work toward the common goal of making a solid product. Do not think that you are the developer and they are the tester.

Answer 2

Treat them as equals.

I have seen a lot of developers thinking they are more or better then testers in their companies and also treat them that way. Developers and testers have a similar goal: Making high quality software.

Answer 3

Just a few quick ones off the top of my head:

1. Run the code they've completed at least once on their machine before marking it as 'Done'.
2. Consult with QA on their intended route to implement a feature or bug fix to help flush out potential issues or bugs before even one line of code is written
3. Encourage QA to participate in sprint planning/grooming, design and other relevant meetings. QA usually has a wider breadth of knowledge about the entire system and end user that can be helpful in early planning stages.
4. Don't view QA as the 'enemy' but rather as the safety net that prevents a bug that costs the company $$$ from making it into production

Answer 4

I've worked in both roles for a while and my recommendation is:

• Pair (before coding when possible) on test plans
• See QA as an asset that is protecting you and customers from the mistakes we all make
• Have an open mind when a QA approaches and avoid the (common) mistake of explaining away an issue as their lack of understanding
• Don't assume that they can pass a coding change quickly. For example, don't work on a change for 2 weeks and then assume that QA will pass it in 2 hours.
• Don't assume that a ticket is basically done when you give it to QA, be open to more code changes the same way you would be for a code review
• Take into account how your organization works. A developer:QA ratio of 2:1 will mean a different role when compared to a ratio of 10:1 Take this into account.
• Volunteer to help testers out with fixing environment or setup issues so they can test.
• Treat testers as engineers when they do engineering tasks and when possible/practical think of technical testers (that write testing code) as Quality Engineers. QA tends to 'mean' manual testing for a lot of folks and is associated with entry level / intern / co-op manual testing where as QE indicates a more technical role
• Invite them into conversations where there are different opinions or if the functionality is in a well-known problem area to get their input
• Encourage QE testers to learn more about the code
• Publicly value their role, e.g. "Well I think I've got this right but let's see what QE thinks first"
• Publicly thank their findings, e.g. "Well, I'm working on ticket-1234 because thankfully QA found the issue with the DB not being updated for anonymous posts in Firefox" that we'd all been trying to track down from those log errors.
• Physically seat the QA folks with the developers they are supporting.
• Include QE in team activities such as: Onboarding, Lunches, Planning Meetings, Departure lunches, Ticket Grooming, retrospectives, etc.
• Share a common wiki that documents the setup knowledge
• Share tools and techniques that you use to debug code
• Work on making sure their environment is the same as yours so that bugs found are not just due to environmental differences.
• Use a "three amigos" approach to help bring QA, product, and dev together to work collaboratively.
• Be open to different points of views they may represent. Good testers think of many different user personas such as happy, sad, angry, forgetful, distracted users.
• Be humble and publicly thank testers for their finds (instead of silently just fixing them).

Some organizations need to promote this for their developer-developer relationships too!

Answer 5

This is a simple point, but very effective:

Be a developer who says "thanks" or "good catch!" or something positive whenever a tester finds a defect.

It's the daily currency of the respectful working relationship. All the formal processes are good, but they flow from the basic attitude of respect.

Answer 6

• To start off, have a positive attitude towards tester's activities & identified issues
• Provide unit + dev-smoke tested builds to QA
• Share release notes with info like included fixes, features and known bugs etc
• Provide support in technical & back-end understanding of system
• Provide support in analyzing hard-to-reproduce issues
• Be appreciative towards efforts of Testers/QA and work as a single unit
• Last but not least, follow all the best-practices / QA processes for example sharing release notes, avoiding frequent interim builds, doing proper versioning, marking bug status etc.

Answer 7

All the answers so far are good.

A few other comments:

• Remember that the testers aren't there to make your life miserable. They're there to provide business stakeholders with information about how well the software fits what its intended users need from it.
• Don't just throw code over the wall and figure the testers will catch any bugs. They might, but they'd rather be looking for the edge cases because the code you send them is rock solid in the steel thread.
• Communicate what testing you've done and any areas that you're concerned about. The testers don't always know the internals so they might not be aware they need to test that.
• If the testers are technical enough to ask about your implementation or point you to the line of code that has a problem, don't get offended by this. They aren't playing "gotcha", they just want the software to be as good as it can be and they're trying to help you (yes, this happened to me. You do not want to be that developer).
• Always remember that you and the testers have the same goal: producing quality software your customers want to use.

I'm sure there's at least one question here that takes the perspective of what software testers can do to win the hearts of developers: I just haven't found it yet.

Answer 8

All good points here, but there's one I run into somewhat regularly as QA, that is to remember that while I may know the product fairly well, I do not know the code at all. It's generally frustrating being asked what part of the code has the problem. If I find a problem with a dog fetching a stick, I don't know if it's the dog class or the stick class. For all I know, it might be a problem in the fetchables interface implemented by the stick. (I might do some testing with ball objects that also implement fetchables that could rule out the stick class at least)

Additionally, when you find and fix the problem, I will need to know if it was with the dog class, the stick class, or the fetchables interface so that along with just testing the bug, I can do regression testing to see if the fix broke anything else (sadly, this is something I need to badger my developers for constantly)

Answer 9

Respect the time requirement for QA

All to often, test time becomes the project buffer time. If the release candidate is a day late, do you shift the release date or do you tell the QA folk to test faster or to test less?

Keep them it the loop if it looks as if there might be a delay.

Give the testers recognition (like bonuses, promotions, ...) if they run their tests fast and effectively despite the late delivery of the release candidate. (As a side note, don't reward them for the number of bug reports.)

Inform them what your unit tests cover and how

When the QA people have reviewed your unit tests and seen the most recent protocols, they can avoid duplication of effort (unless there is a deliberate decision to double-check). The testers can concentrate on things which automated tests are less likely to catch.

Let them see and challenge the original specifications/stories

QA professionals are trained to see edge cases and failures where developers want to make things work. Let them write most of their test cases and show them to the developer before the first line of code is written. (Test Driven Development, TDD)

I've once been in a project where a tester rejected the specification as buggy. The tester was right, the spec wasn't consistent with a previous requirement.

Consider if the QA should be a separate team or part of the dev team

There are good reasons for both. If the project is waterfall-like and documentation of compliance is important, make the QA a separate team with a team lead at the same level as the development team lead. If the project is agile and documentation of tests is less important, put the testers into the dev team. If using scrum, write passed tests into the definition of done. The story isn't finished until the tests are finished.

In the most extreme case, that could mean abolishing testers. Every developer is responsible for quality.

Answer 10

I read my Software testers' test cases and give them feedback. I ensure every workflow-path you only would know from reading the code is covered or at least brought to their attention. I also keep them up to date with features I myself that may not be really covered in meeting or UX specs (normally small fillers).

Answer 11

I personally think that the relationship should be improved in both directions, on the Dev side and the QA side. From my young experience, I'm the only QA in the team and the relation with the developers is good, I have never experienced drama with any member of the team or any kind of complaints.

I think this is due because we consider ourselves as equals and also because developers consider me as an help and not a constraint or someone who is here to annoy them.

So I think there are few things to consider to have a good relation QA/Dev:

1. Developers have to accept that QA testers are here to help and they are not a constraint, there are here to help them on how to improve their code or their thinking on the Product

2. QA have to accept that developers can do mistake and create bugs, and so they have to explain issues in a detailed and correct way. There is no need to be angry at someone. If a fix is wrong it's probably because the scenario or the expected behaviour were not detailed clearly

3. Moreover it's really important that QA and Devs work together in the same area and not in different offices (when it's possible, I personnally have to deal with remote devs).

4. Personal touch: Congrats. It sounds stupid, but each time I close a ticket, I give a kudos to the developper because he has done a good job and they will appreciate that because you give value to their work. A small Good job doesn't cost a lot but it could be efficient.