Guest post: The Importance of QA

Today we have a guest post from Buovjaga, our friendly local QA evangelist for LibreOffice, KDE, Inkscape, Firefox and Thunderbird. Without further ado, I’d like to present…

The Importance of QA

With this post I hope to convince you that a strong quality assurance team can do miraculous things for a free software project.

The spectrum of QA is wide, and reducing the skill requirements is particularly relevant for KDE’s onboarding initiative.

The critical phase of onboarding a new contributor is the first contact. Sometimes the new person does not know what they want to do. Often you do not have a clear picture of what skills they have. You need to act fast or they will lose interest and disappear! This is the moment where you should hand them snacks: a query of bugs that need to be confirmed or re-confirmed. This is the lowest threshold for them to step across and into being a contributor, because:

• They do not need to learn version control
• They do not need to learn the patch submission processes
• They do not need to be wordsmiths
• They do not need to know interface design or how to draw pretty pictures
• They should not even need to know how to use the features they are testing, because a valid bug report includes clear steps on what to do!

QA is highly important in itself, but it is also a gateway drug. A simplified story of the evolution of a contributor might be as follows:

1. They work on something meaningful
2. They get familiar with the structure of the project
3. They discover their own potential and the multitude of things they can help with

Not only does this evolution flow naturally through the QA team, but the experienced members are in a unique position to speed it up. This is because QA in the course of its work typically has to ferret out information from all the other teams. This leads to QA

1. Knowing who the subject-matter experts are
2. Discovering weak points in the organisation
3. Helping the various teams stay in sync with each other

In this aspect QA is acting like neurotransmitters in the body of the project.

The most apparent beneficial effect of having a strong QA team is that the developers are not distracted by massive amounts of first-stage bug analysis.

In QA, too many cooks do not spoil the broth. A large and diverse team is more effective than a small one when trying to keep up with a myriad of software and hardware configurations.
A large teams allows the freedom for members to level up their skills. The more experience on advanced triaging techniques the members have, the less work developers have to spend per bug fix.

There is a long road ahead for KDE to reach a healthy state regarding QA. Recruit contributors early and often. Aim for a feedback loop of recruiting, where even fresh contributors brainstorm to come up with ways to find new people.

I invite everyone to go through these articles and improve them:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging/Identifying_duplicates
https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports

I also recommend KDE to look into making it easy for QA to perform git bisects for pinpointing regressions. Perhaps this could be achieved by offering compressed repositories containing binary snapshots for every single commit in a project like LibreOffice does.