How to motivate devs to test their own work?

Question

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.

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.