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.

Raatajat_rahanalaiset.JPG
Primitive development team working in the bug tracker without the luxury of a QA team

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.

Advertisements

4 thoughts on “Guest post: The Importance of QA

    1. That’s a really nice approach and I think they’re doing an amazing job there. We could definitely look into doing the same. However the situation isn’t as dire for us as it was for the GNOME folks since we use Phabricator, which already makes it fairly easy to test patches, and we have pretty comprehensive documentation on how to use it: https://community.kde.org/Infrastructure/Phabricator

      The flatpaks-for-every-merge-request approach is awfully nice though, just for being a GUI solution. It’ll be quite the bandwidth hog, though.

      Like

      1. LibreOffice build master every night so you can review your change after you wake up 😉 but to be fair kde neon dev unstable did it the same way and it’s really nice to have it.

        Like

  1. Hello, I do not know if it’s a common problem, but I happen to both the desktop and the notebook, both on Tumbleweed and on Kde neon, the problem is that sometimes the windows switch (alt + tab) crashes Plasma, if instead of breeze I use another works well, the problem is only with breeze

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s