Collecting the right data when logging bugs: P.E.A.R.S

Collecting the right data when logging bugs: P.E.A.R.S

2013, Oct 22    

P.E.A.R.S. is a bug logging acronym I’ve used in the past, and it works really well from a developer’s perspective. I recommend not accepting any defects that don’t follow the P.E.A.R.S. guidelines—meaning, the defect report should include the following information.

  • Priority – indicator to the importance of the issue, 1=showstopper, 5=Meh? if time
  • Expected result – clear concise explanation of what you expected to happen, if possible reference requirement id
  • Actual result – What actually happened?
  • Reproduce (steps to Reproduce) numbered steps to Reproduce to error/issue. You cannot be too detailed in this section.
  • System – Os version, device mobile/version, version of app, Browser version, etc.

This idea came up during a talk at Droidcon 2011, but I can’t for the life of me remember who presented it. It’s a great and simple approach, so thank you! If it was you, please let me know so I can give you proper credit.