How to QA
From Koha Wiki
This will be landing page for people interested in the work of the QA team, considering joining it or starting out with QA.
Which bug should I pick?
When trying to pick a bug, there are some guidelines which should be processed first. Of course, time available and what the QA person feels confident with will always factor in too.
- security bugs before normal bugs
- bugs before enhancements
- bugs sitting longer in the queue before newer bugs
QA team members are added to the default CC list for security bugs.
Note: QA Contact on bugzilla should be set, while a QA person is working on the bug.
What to look for?
- Violations of the Coding Guidelines
- Do patches pass the QA Test Tools
- If there is a database update:
- Does it follow instructions for Database updates?
- Will the result be the same for existing and new installations?
- Can the statements be run repeatedly without causing harm?
- Have all necessary files and tables be changed? (items - deleteditems, borrowers-deletedborrowers-borrower_modifications)
- Does the code make sense technically?
- Is there unnecessary code duplication?
- Does the feature/fix make sense functionally?
- Will this work for all libraries, or should it be optional?
- Does it change existing workflows?
- Could there be unwanted side effects in another part of Koha?
- What does the test plan NOT cover?
- Is there code in the patch unrelated to description and test plan?
- KohaDevBox - Development and QA environment with tools below already set up
- Git BZ - Applying patches, attaching them to bugzilla and editing bug status
- QA Test Tools - Checking for problems and adherence with some of the coding guidelines