Libsysguy's Proposal for QAA 3.12
From Koha Wiki
Improving The Quality of Koha's Code
Koha has grown quite a bit in the the last few years. As it continues to grow we face new issues and are able to create new solutions. Currently Koha's code base is quite large and reflects the history of a system in a period when many of the technologies it uses have changed rapidly. We need to improve the quality of our codebase to enable growth and encourage and enable contributions from new developers.
As it currently stands, we as a community have developed certain standards and paradigms that we try to adhere to when submitting code. As QAA I would do my best to make sure that these standards are followed through each patch that is passed. I would also do my best to make sure that these standards are well known to current and new developers through feedback about patches and answers to questions through the IRC.
The primary role of this position should be testing. The question I should ask myself every time I test a patch is "Does this break something the original sign-offer missed?".
The Personal Touch
Each patch that is QA-ed should be installed and tested against the current working master branch. This includes adding additional workflows for QA-ers to be able to say "Yup, I checked this".
Each patch should include a testing plan so that those who are not familiar with the area of Koha the patch deals with should still be able to test it. Yes, this does deal more with community members signing off, but it can also be helpful to QA team members as well.
Unit tests are now required for all new additions to C4 and Koha. I would like to make sure that all new submissions adhere to this standard set fourth.
After reading JCamins proposal for automated testing I think it is a great idea. This could be a great asset to Koha. I would like to start developing automated suite using WWW::Mechanize so that Koha users could run these test on development systems against their data. Inevitably, we will miss something in testing no matter how many layers of testing we have. This could alert them to any potential problems and allow us to expand our testing ability beyond just our QA team and RM.
As a developer I often find writing documentation akin to having my fingernails pulled out. That being said it is a very important part of development, especially in a large project like Koha. I would like to work to develop POD templates for submitters to use. This would make documentation more uniform and give submitters a good place to start with documentation.