I don't know if you have faced the situation but I wanted to open a discussion about the following topic: How to motive developers to test their own work?

When I mean "their own work" it can go from a feature they have realized or a fix to a bug.

I'm the only QA in a team of 9 developers for a project involving mobile, web and server work. The amount of work is more and more important and my time becomes precious. The current problem that I sometimes experience is that some developers develop features or fixes but don't really test what they have done. They compile and then send that to me for testing.

With my project manager who is also a developer we want to incite other developers to review their own work and perform a minimum of testing. It is annoying to see that a bug is still happening with exactly the same reproduction steps when i'm reviewing a fix.

How is it working in your team? Did you faced this issue also? I know that Atlasssian is doing a great job on this side and motivate developers to review and test their jobs.


6 Answers 6


A viable option is to bake quality into the process.

When planning a sprint/feature/..., add default tasks to each item such as Code review, Write unit tests, Code review fixes, ... That way you make the work visible, and because the tasks are there, they have to be done. For defects, you can add similar tasks apart from the fix itself (for example, some unit tests for a bugfix, or a review for a complex refactor).

Of course, you must realize that development itself will slow down partially because time is invested in broader activities - but that should repay itself over time in terms of quality (less bugs, happier end users).

First discuss this with the team (in the hope that they are somewhat willing to cooperate along this path), and maybe go about it step by step to allow them to get used to their new obligations. But above all make them understand their responsibility - a good developer does not simply throw untested/unreviewed code over the fence!

Another fun one to try: if a developer commits code, have him go over the acceptance criteria together with the analyst, on the deployed testing environment (because it always works on their local machine ;). The analyst might already catch some things the developer can fix immediately, saving you and himself time later on by not having to log a defect.

If you want to take it to the next level, think about having developers assist you in writing automated tests at API and/or GUI level. Especially when you're the only QA person for 9 developers, consider this approach: you write the cases for automated tests, they implement them, you review them.

  • Nice last sentence, but with a nine on one situation. I would teach them to write their own cases as well. Then review randomly once in a while :) Something I should be doing more with my 12 developers. Thanks Commented Nov 11, 2017 at 17:17

Answer is unit-testing and test-driven development.

For every bug, first a new unit-test is written (or code added to existing test, if appropriate). This test will fail because bug is not fixed, but it proves that your unit test checks for the correct conditions.

Then developer fixes the code, and test should pass.

All test should pass before commit (definition of "DONE" includes passing all unit tests).

As a bonus, if some changes months or years later would cause the same bug, unit test will catch that before change was even committed to the trunk, far before it went to QA.

This is a big cultural change for devs (write a failing test first), but this is industry standard, and best way to quality software.

This also allows for refactoring and paying down the accumulated technical debt - so developers are not afraid to improve code because they might not understand all consequences of the changes - unit tests (and end-to-end tests) take care of that.

But I am not sure how QA can motivate developers to make that change: only dev manager can do that, and it most companies QA is not in position to manage developers and decide what devs do in their time. It CANNOT be a responsibility to QA tester. QA manager (senior person whose responsibilities include quality) need to talk to dev manager.

You as QA tester can only suggest to dev manager, and if you will get no traction, it might be good time to start looking for a new position, because you are being set up for failure. QA cannot "assure" the quality (and certainly cannot motivate devs to do something their manager does not care about), quality has to be designed in to the product, and QA can only assist management to provide information about current status of quality

  • I know you have lots of experience @NielsvanReijmersdal , but our QA manager asks us (manual QA and QA automation engineers) questions to be able to argue for our interests with developers' manager and other managers. And she in not a power-hungry, I guess it depends how healthy your company's culture is, and I might be luckier than average, because in our company, we DO care about the quality, and we CAN argue for it, and note when quality is slipping. Commented Nov 11, 2017 at 18:17
  • Also, QA CANNOT be solely responsible for quality, or for the quality of the process. We are ISO certified, and our responsibility as QA is to make sure that all involved parties follow the process, and if not, we report to the managers (because we as QA cannot give orders to developers or anyone else). They all have own managers, and managers manage their people, we don't. We just provide info. Commented Nov 11, 2017 at 18:23
  • We (QA) are explicitly said by our manager to notify developers about quality slips, but do not argue or force them to do anything )because cannot force them to do anything anyway) - just report back QA manager, so our QA manager can argue for it on higher level, so dev's manager's manager knows about it and info goes up and down the chain of command. Commented Nov 11, 2017 at 18:25

You need to change the culture. Not easy.

Addressing motiviation

I recommend looking into:

  • Relating performance in this area to pay*
  • Management focus on good testing practices
  • Frequent presentations on quality issues and approaches
  • Hire developers who are already passionate about testing
  • Have lunch and learns on testing videos (no prep needed)
  • Have automation and application engineers go to testing conferences
  • Make sure automation engineers are not treated as second class citizens
  • Make code review processes meaningful and include tests and reviews from QE
  • Have 'issue specific retrospectives' with root cause analysis for better testing opportunities

* be careful using metrics though. This is often better assessed by a person.

  • This "Hire developers who are already passionate about testing" +1! Commented Nov 11, 2017 at 17:18

The best situation is one in which the developer has internalized delivering a high-quality product. You do that through education, e.g. by showing the relationship between quality and the organization's success and their own success. Sometimes that works, especially in a small organization like yours.

Another way to motivate developers to test their work is by providing incentives that reward high quality and/or punish low quality. Some companies do that through shaming (e.g. publish quality metrics). If you are comfortable using code coverage as a proxy for quality, you could break the build if the code coverage is too low. These kinds of measures require some overhead. They can also have unintentional consequences, e.g. developers gaming the system so that they meet an explicit goal but do not necessarily improve quality.


In his book "The Clean Coder" Robert C. Martin writes:

QA should find nothing

Therefore, when you release your software you should expect QA to find no problems. It is unprofessional in the extreme to purposely send code that you know to be faulty to QA. And what code do you know to be faulty? Any code you aren't certain about!

He goes on to explain how you can do this. It includes things as TDD, testing your own code and more. Personally I think all programmers should read Robert C. Martins books (Clean Code, the Clean Coder, Agile Principles, Patterns, & Practices and Clean Architecture.) Let your company buy the books and place them near the developer. They do not have to agree with all his ideas, but becoming a professional programmer includes being a good tester in my book.

I like his ideas about double booking keeping with automated tests, where he compares it with accounting, but also like how law defines rules doctors. Programmers also needs a law he thinks. Resulting in the programmers oath. One of the nine items says:

I will produce, with each release, a quick, sure, and repeatable proof that every element of the code works as it should.

I guess repeatable proof is a form of testing either scripts or automation.

If your developers do not like to read, cant blame them they already read code all day. Then watching the Clean Code video series is really nice, most developers tend to love it. The first free episode explains how messy un-tested code can ruin companies, explaining quality concepts for developers, managers and any one working on software. Watch it it is worth your time.


I think this is common situation for all QA.

but i think that might be solution there.

if functionality are Completed then force to Developer to do UNIT Testing. if Unit testing are not done from developer side that means developer has not Developed proper, because if developer Done The UNIT Testing then most of the functionality is working proper so we have to think only different cases on that functionality.

" Unit Testing is normally performed by software developers themselves or their peers. In rare cases it may also be performed by independent software testers."

So Force to Him For UNIT Testing.

  • Forcing people todo unit-testing will result in the most horrible tests, code and a lot of other issues. Watch Steve Freeman - Test-Driven Development (that’s not what we meant) for some examples: vimeo.com/83960706 Commented Nov 11, 2017 at 17:05
  • When you hire a software developer, you expect them to do everything necessary to create a fully functional, bug-free application. However, doing the “right” thing often takes additional time and effort. And if the budget and deadline are tight, cutting corners sometimes comes with the territory. You don’t want developers to skip out on certain procedures that would otherwise be a normal part of the testing phase—and that includes unit testing. Commented Dec 27, 2017 at 13:28
  • Yes, I wrote the code and I am confident it’s working properly. No need to test this path, no need to test that path, as I know it’s working properly. And right here developers skip the bugs. so that kind of excuse here from the developer side. Commented Dec 28, 2017 at 8:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.