Hi all,
As a result of discussion at the developers hackfest at the 2015
conference, we adopted a QA guideline to include a comment in git commit
messages for bug fix patches that explains how to test the bug that the
patch fixes. While preparing for next week's Bug Squashing Day, I spent
some time this morning reviewing recent LP bug fixes.
We have some bug fix patches that explain how to test the bug fix, but
many others are still submitted without some kind of test plan. The
rationale for including a test plan is it provides the tester with clear
guidelines for ensuring that the patch does indeed do what the author
intended. When I look at some of the bugs that have been languishing in
Launchpad for months and, in some cases, even years, I often have the
thought of "Looks great, but I have no idea how to test that."
By incorporating an informal test plan in your commit messages and on
the LP bug itself, you'll make it easier for testers to make the
decision to test the patch and possibly increase the odds of the fix
being merged to master.
I just wanted to send along this reminder to please include these test
plans in your git commit messages if your patch is fixing a bug. In some
cases, it might not be a bad idea to include them in new feature
branches too, especially if the new feature is particularly complicated
or is covering an obscure test case that not all libraries are likely to
encounter.
If you are unsure of how the message should be written up, Galen
provided an example on the QA page at
http://wiki.evergreen-ils.org/doku.php?id=dev:contributing:qa.
Thanks everyone!
Kathy
--
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
[email protected]
Twitter: http://www.twitter.com/kmlussier
