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.


What is the process?

The QA Team is responsible for the second step in testing patches before they are integrated into the Koha code. They look at bugs and patches in Signed Off status and can move them to Passed QA after successful testing. While the first independent tester is not expected to look at code, the QA Team Members are expected to in order to check for adherence to our Coding Guidelines.

Basic process:

  • QA Team Member picks a bug and sets the QA Contact field on Bugzilla to their name.
  • QA Team Member tests and reviews the code. They might set:
    • Passed QA: bug moves on to be reviewed by the Release Manager for inclusion.
    • Failed QA: bug requires more work by the developer. QA will explain on the bug report what is needed to continue.
    • In Discussion: bug is not a clear fail or pass, there are points that need a broader discussion in order for things to move on.

Only QA and RM will usually be allowed to set Passed QA with an exception for the Packaging Manager. They are allowed to jump directly to Passed QA for patches concerning the build process.

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

Also the Release Manager can use the RM_priority keyword to highlight important bugs.

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?
    • Does it fit into the bigger picture?
  • 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?


  • Dashboard - Helpful links to queues and list of oldest bugs awaiting QA
  • 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