7

Let me start with some contexts in the form of a quote from JUnit Test Infected: Programmers Love Writing Tests:

The Problem

Every programmer knows they should write tests for their code. Few do. The universal response to "Why not?" is "I'm in too much of a hurry." This quickly becomes a vicious cycle- the more pressure you feel, the fewer tests you write. The fewer tests you write, the less productive you are and the less stable your code becomes. The less productive and accurate you are, the more pressure you feel.

I am working as a Test Engineer for three (five developer sized) Scrum teams. I cannot do all of their testing work. Therefore I am training them to become better testers and continuously improve their process.

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

-- John Sonmez

This leads to my question:

What methods do you use to make your engineers (either Testers or Developers) Test-infected (or TestHappy)?

I am looking for methods I haven't tried are unaware of. Preferable one method per answer, unless they cannot be used a single method. (This way we can vote for which we think are the best or most promising methods to try, certainly for a single tester in larger teams.)

Improve this question

7 Answers 7

Reset to default
5

Challenge developers

Another company I was working for held competitions among developers / testers. People love challenges; when challenged with coming up with new testing ideas and writing tests as quickly as possible, they became very motivated.

Results:

  • Within a few hours, lots of new ideas turned up as well as written test cases.
  • You got to know your peers better on a personal level.
Improve this answer
2
  • 1
    Do you have examples for challenges?
    – Niels van Reijmersdal
    Commented Nov 24, 2016 at 20:53
  • @NielsvanReijmersdal, challenges can be contextually based. E.g. anything related to your current system under test. From the top of my head, there was a website we needed to test; so we had this code-jamming session; developers / testers were asked to write scripts to discover as many bugs as we could. The team with the best results was given a 500 dollar gift shopping voucher.
    – Yu Zhang
    Commented Nov 24, 2016 at 21:07
5

Testing on the Toilet (from Google)

Repeating the testing on the toilet prints on your toilets might be a way to spread testing knowledge and get developers to do more and better testing.

I have downloaded all the Google ToT articles to a single folder, you can find them here. This so you don't have to go through the whole blog.

Print one for each toilet you engineers goto every (other) week. I have started with Test behavior not implementation.

The results are:

  • Reactions have been positive
Improve this answer
4
+50

Make it easy

  • Build frameworks which Mock and Stub out portions of the system
  • Set up examples
  • Use frameworks which allow reuse for integration testing (BDD frameworks work well here)

Make it beneficial for the Developer

  • Use new technology

  • Treat it as an R&D project

  • Allow Developers to use the test classes as areas to expand their skills

Make it fun

  • Do challenges

  • Have group sessions/knowledge transfers

Explain Benefits

Prevent:

  • Calls at night

  • QA-Dev loop

  • Undefined sections of code

  • Unclear ramifications of making changes

  • Difficult refactoring

  • Low code quality

  • Poor understanding of requirements

Give Team ability to reject Unclear Requirements

Possibly the most important piece, ensure that the team has the ability to reject the requirements or create a research task to define them. If during planning the team can not define the majority of the basic tests for the requirements than they are unclear. By having the team more enthusiastic about testing, it will give them the ability to define the tests up front and understand what changes need to be made. If they are unable to define the tests than the requirements should be redefined to make it clearer.

Improve this answer
2
  • Is there a reason the benefits are striked-through?
    – Niels van Reijmersdal
    Commented Nov 30, 2016 at 15:05
  • They are the issues that are typically faced. Essentially, they wouldn't have to deal with them is the benefits. I could add "Prevent" to the beginning of every line
    – Paul Muir
    Commented Nov 30, 2016 at 15:11
3

Get a Tester invited to the planning meetings along with the Developer and Product owner. As the PO describes the feature to be built and they way it should work, the Developer is already building the feature in his head. He's thinking about how to make it work. The Tester is thinking about how it might not work. If the Tester shares his scenarios in the form of "What happens if this happens?" or "What happens if this is broken?" gets the Developer thinking about alternate scenarios, edge and corner cases that need to be addressed. He will then proactively program against those scenarios, leading to successful testing by the Tester.

Soon the Developer will anticipate the Tester's questions and have an answer for him in the planning meeting. The Developer already knows what edge cases the Tester is going to attempt, and programs against those without being prompted by the Tester. In that scenario testing is a matter of the Tester asking the Developer, "Did you handle this edge case? How?". If the Tester and Developer trust each other and have handled similar edge cases before, the Tester's effort can be significantly reduced while increasing the robustness of the code and minimizing the number of tests the Developer needs to write.

Improve this answer
2

Detailed post-mortems

With a clear objective of answering one question

What should we have tested that would have helped us avoid this situation in the first place.

The unstated side-effect will be for folks to ask "what (test wise) should we do going forward in our work to avoid repeating this?".

However you don't need to tell engineers that second question, good ones are very lazy (in a good programmer way). They will enjoy asking and answering it themselves with better tests going forward.

Improve this answer
1

Coding Dojo: Test Driven Development

I have been executing TDD coding dojo's as described by Emily Bache in her book and Pluralsight video's.

The engineers are very enthusiastic about this approach.

Each iteration we do a single Dojo and watch a CleanCoders fundamentals video, which also works towards TDD.

The results are:

  • Developers proudly telling me they TDDed their first class recently
  • Getting good practise with TDD in a safe environment
Improve this answer
1

I asked my manager the same question a few years back. The answer he told me is:

If developers test their own codes they will help themselves.

While I could not personally convince developers to write tests, the management especially the scrum master certainly could. During our sprints, a certain portion of tests was identified and assigned to developers.

The management organized training sessions to demonstrate how much developers can help with testing and improving product quality as well. Various graphs showed the number of bugs discovered during various stages of SDLC.

We also got a champion to lead the course; the champion went around and did lots of research on new testing methods and tools, introducing them to all of us.

Results:

  • We got developers to write tests.
  • Developers were very interested when shown new testing tools and new testing methodologies, they wanted to use them.
Improve this answer

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.