How to QA

From Koha Wiki

Jump to: navigation, search
Koha > Technical > Development
Koha > Technical > Development > Quality Assurance Testing

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

Developer handbook

Personal tools