One of a series of test instances for migrating the Koha Wiki MediaWiki database.
For the current Koha Wiki, visit https://wiki.koha-community.org .How to QA
This is a landing page for people interested in the work of the QA team, considering joining it or starting out with testing in general.
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 or to Failed QA if testing revealed some issues to be fixed or questions to be answered. While the first independent tester is not expected to look at code, 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 in the source code.
- Failed QA: bug requires more work by the developer. QA will explain on the bug report what is required to continue. More work can also mean answering questions, missing documentation or meeting formal requirements like improving on commit messages and test plans.
- In Discussion: bug is not a clear fail or pass, but there is a disagreement about how to move on and that will need broader discussion.
Only QA Team Members and Release Managers 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 general guidelines on how to determine which bugs 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? Examples: (items,deleteditems), (borrowers, deletedborrowers, borrower_modifications)
- Does the code make sense technically?
- Is there unnecessary code duplication?
- Does the code add new warnings to the log files?
- 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?
Tools
- Dashboard - Helpful links to queues and list of oldest bugs awaiting QA
- Koha-Testing-Docker (KTD) - 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
- Getting involved | Development workflow | Bug Reporting Guidelines | RFCs | Plugins | Plugin hooks
- Version Control Using Git | git bz | Commit messages | Sign off on patches | QA Test Tools | How to QA | Debugging in VIM
- Coding Guidelines | Koha Objects | Rest Api HowTo | Coding Guidelines - API | Unit Tests | Continuous Integration | Interface patterns | Database updates | Adding a syspref | Bootstrap and LESS
- Debian Packages | Building Debian Packages | Easy Package Building | Commands
- External: Dashboard | Bugzilla | Schema | perldoc | REST API | Jenkins