Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Should testers participate in code reviews

53 views

Published on

Peer review can be a major contributor to code quality, but the practice is usually ill-defined and excludes some team members who can make a huge difference - those whose focus is testing.

The orthodox reasoning is that, if someone doesn't have development expertise, then they will not have anything to contribute to a code review. This is wrong on several levels. Software should be easy to read, logically structured, with clear, comprehensible names - and the people who are best placed to notice when it isn't are those who won't focus on syntax and coding style.

As well as contributing to the readability of the code, testers will gain early insight into areas of complexity or confusion, which is invaluable when making risk-based judgements about where additional testing is needed, whether automated, scripted, or exploratory.

In this interactive session, we'll explore how and why team members with testing expertise should participate in the peer-review of development commits. We'll dig into the positive impact this has on our products, our processes and our people. You'll leave with concrete next steps, including a structured description of an inclusive peer-review process and a modified Definition of Done.

The focus of peer reviews is frequently limited to code structure and conformance to coding standards not enforced by static inspection tools. The documentary value of the code (and specifically the unit tests) is frequently ignored, as is the need to communicate the extent of developer testing to their colleagues whose focus is on testing.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Should testers participate in code reviews

  1. 1. @sebrose http://cucumber.io Seb Rose Should testers participate in code reviews? TL;DR - Yes
  2. 2. @sebrose http://cucumber.io Agenda • Some definitions • Primary motivation • Typical approaches • A technique • Two examples • Why testers? • Wrap up
  3. 3. @sebrose http://cucumber.io Do you have a DEFINITION of what constitutes a review?
  4. 4. @sebrose http://cucumber.io What is a review? a formal assessment or examination of something with the possibility or intention of instituting change if necessary
  5. 5. @sebrose http://cucumber.io Formal •done in accordance with rules of convention or etiquette •suitable for or constituting an official or important situation or occasion •officially sanctioned or recognised
  6. 6. @sebrose http://cucumber.io What makes it a CODE review?
  7. 7. @sebrose http://cucumber.io What is a code review? a formal assessment or examination of something with the possibility or intention of instituting change if necessary
  8. 8. @sebrose http://cucumber.io What is a code review? a formal assessment or examination of source code with the possibility or intention of instituting change if necessary
  9. 9. @sebrose http://cucumber.io Will you review the ALL the code?
  10. 10. @sebrose http://cucumber.io What is a code review? a formal assessment or examination of a source code change with the possibility or intention of instituting change if necessary
  11. 11. @sebrose http://cucumber.io What is a code review? a formal assessment or examination of a small source code change with the possibility or intention of instituting change if necessary
  12. 12. @sebrose http://cucumber.io Who should CONTRIBUTE to a review?
  13. 13. @sebrose http://cucumber.io Peer a person that is of equal standing with another
  14. 14. @sebrose http://cucumber.io Today’s working definition a formal assessment or examination of a small source code change (by one or more of the author’s peers) with the possibility or intention of instituting change if necessary
  15. 15. @sebrose http://cucumber.io Why review? A. Style, structure, conformity B. Understandability C. Performance efficiency D. Bug prevention / detection E. None of the above The PRIMARY reason for carrying out a review is:
  16. 16. @sebrose http://cucumber.io What is the LIFE EXPECTANCY of your product?
  17. 17. @sebrose http://cucumber.io Simulation @robsmallshire
  18. 18. @sebrose http://cucumber.io Simulation @robsmallshire
  19. 19. @sebrose http://cucumber.io Why peer review? To ensure that the next person who works with the code will be able to do so safely.
  20. 20. @sebrose http://cucumber.io Programs must be written for people to read, and only incidentally for machines to execute. Harold Abelson, 1984 This is not news!
  21. 21. @sebrose http://cucumber.io How do we conduct reviews?
  22. 22. @sebrose http://cucumber.io Behind closed doors CODE REVIEW IN PROGRESS How do we conduct reviews?
  23. 23. @sebrose http://cucumber.io In pairs How do we conduct reviews?
  24. 24. @sebrose http://cucumber.io On our own How do we conduct reviews?
  25. 25. @sebrose http://cucumber.io Which is best? To ensure future understandability, reviews should be conducted without the presence of the author(s).
  26. 26. @sebrose http://cucumber.io Tests as documentation So if you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read. Robert Martin
  27. 27. @sebrose http://cucumber.io Tests as documentation @Test public void scale() { Date now = new Date(); Calendar calBegin = Calendar.getInstance(); calBegin.setTime(now); calBegin.add(Calendar.HOUR, -4); Date begin = calBegin.getTime(); Period p = new Period(4); long delta = p.getBegin().getTime() - begin.getTime(); Assert.assertTrue( p.getEnd().compareTo(now) >= 0); logger.trace(delta); Assert.assertTrue(delta < 10 && delta > -10); Assert.assertEquals( new Integer(4), new Integer(p.getScale())); }
  28. 28. @sebrose http://cucumber.io @Test public void smoker_requires_manual_referral() { Customer customer = customerBuilder .standardSingleFemale() .smoker() .build(); Referral referral = underwriting.process(customer); Assert.assertEquals(Referral.Manual, referral); } Tests as documentation
  29. 29. @sebrose http://cucumber.io How were they different? Intention revealing names are easier to understand.
  30. 30. @sebrose http://cucumber.io Sample pull requests (PRs) Other source control software is available
  31. 31. @sebrose http://cucumber.io Example 1: a poor pull request
  32. 32. @sebrose http://cucumber.io https://github.com/sixty-north/cosmic-ray/pull/374/commits Example 1: a poor pull request
  33. 33. @sebrose http://cucumber.io What do you think of this commit? https://github.com/sixty-north/cosmic-ray/pull/374/commits
  34. 34. @sebrose http://cucumber.io Example 2: a better pull request
  35. 35. @sebrose http://cucumber.io https://github.com/cucumber/cucumber-jvm/pull/1342/commits Example 2: a better pull request
  36. 36. @sebrose http://cucumber.io What do you think of this commit? https://github.com/cucumber/cucumber-jvm/pull/1342/commits
  37. 37. @sebrose http://cucumber.io What do you think of this commit? https://github.com/cucumber/cucumber-jvm/pull/1342/commits
  38. 38. @sebrose http://cucumber.io What do you think of this commit? https://github.com/cucumber/cucumber-jvm/pull/1342/commits
  39. 39. @sebrose http://cucumber.io How were they different? The test acts as documentation of the developer’s intent. Non-developers canunderstand the test names
  40. 40. @sebrose http://cucumber.io Including non-developers … • Ensures diverse perspectives • Brings the beginner’s eye • Keeps the language ubiquitous
  41. 41. @sebrose http://cucumber.io Including testers … • Brings the test perspective • Spots missing tests early • Allows testers to identify risk • Helps cross-skill
  42. 42. @sebrose http://cucumber.io h"p://www.slideshare.net/ehendrickson/the-thinking-tester-evolved
  43. 43. @sebrose http://cucumber.io Readable unit test names • Gives visibility to non-developers • Allow focus on risk • Minimise duplication of effort • Maximise time spent exploring
  44. 44. @sebrose http://cucumber.io Unvalidated hypothesis Health Warning
  45. 45. @sebrose http://cucumber.io Takeaways Primary purpose of review is understandability Drive reviewfrom the tests Include non- developers in the review Exclude theauthor(s) from the review
  46. 46. @sebrose http://cucumber.io Should testers participate in peer reviews? Should non-developers participate in peer reviews? YES!
  47. 47. Seb Rose 
 Twitter: @sebrose Blog: http:/cucumber.io/blog E-mail: seb@cucumber.io http://bddbooks.com Questions?

×