Lecture 8 - Bug Tracking -> Quick Intro -> The Bug Tracking System -> Bug Tracking Procedure -> Quick Closing Note about BTS and BTP -> Lecture Recap1. The actual steps to file a bug must be simple, easy to understand, well documented, and devoid of bureaucratic BS. What happens if it’s hard to file a bug?
– Developers and testers will be reluctant to file bugs into the BTS and be inclined to communicate issues personally, via email, or IM, etc.
– Folks who are not developers or testers will not use the BTS at all. Instead they’ll use email, MS Excel files, Post-it notes, etc.
2. At the beginning of the lecture I used a quote by my dear friend, computer scientist Daniel Kionka: “Sometimes you have to write down unwritten rules.” The reason I did that is because often in start-ups many things are assumed, e.g., “P2 Priority can be attributed to this bug because, well, it feels like P2.” The problem is this: If we rely on individual assumptions for key things like the Bug Priority, we open the door to unproductive discussions and arguments. In the long run, it’s much better for everyone if we have clean, usable, documented standards. When we talk about bug tracking, the following 3 standards are a must:
Bug Priority Definitions
Bug Resolution Times
Bug Tracking Procedure
For all 3 of the above standards the key concept is effective simplicity. It’s not easy to develop solutions that are effective and simple at the same time, but once you develop them, your solutions (e.g., the BTS setup and BTP linked to the BTS) will work well for years. Next ->
Lecture 8 - Bug Tracking -> Quick Intro -> The Bug Tracking System -> Bug Tracking Procedure -> Quick Closing Note about BTS and BTP -> Lecture Recap
