Katrin's Proposal for QAM 3.12

From Koha Wiki

Jump to: navigation, search
Home > Koha Versions > 3.12

Koha is growing and improving very quickly, and a lot of great developments are underway. But every change we make risks regressions, breaking existing features or changing them in a way that will not work for some libraries. To avoid all those problems, we have agreed on a strict QA process that I think is very important for the happiness of Koha libraries and the future of the project.

As QAM I want to help to make 3.12 the most stable and bug free release possible.

What would be important to me as QAM?


I like shiny new features, but while I like them, there are things more important. One thing that will help us to keep things stable is the automated test suite. Let's make Jenkins a happier bot!


I think design patterns help people find their way around the interface and maybe even around the code. Being consistent doesn't mean things can't be changed for the better, but we should think about it and make good decisions.

  • Does a patch use existing design patterns or does it introduce something new (UI)?
  • Is the new way better than the old way of doing things?
  • Does a patch use the standard terms we use in Koha?


As a German Koha user translations are naturally important to me. So I would definitely keep an eye out for everything that can cause trouble for translators.

What would I do as QAM?

Be annoying.

  • Ask for documentation - How is the feature supposed to work? How will it integrate into existing functionality? How does it affect workflows and what are the use cases?
  • Ask for test plans from developers and testers. I think test plans from developers are great and much needed, but a tester should go beyond that and also try to find the things the developer has not thought about testing or taking care of. When testing something I would encourage people to note what they have looked at and tested, because it will make it easier for other people to spot what might have been missed. There is noone to blame here - Koha is huge and has lots of features, no library is using all of them and knowing your way around is even made harder by new features being added constantly.
  • Ask for a more opinions where a feature changes a workflow, might need a more general approach or touches core functionality that is just important to get right. For me QA implies more than code review, but also questioning if something makes sense in the bigger picture.
  • Ask for more sign-offs for big patches and patches that touch critical areas of Koha.

Also I would like to work with the QA team on

  • checking new code obeys the coding guidelines
  • improving developer documentation to make it easier for people get started with developing Koha and to avoid mistakes.
  • making sure every patch adheres to our agreed on QA workflow.
Personal tools