Get Involved/Quality/Akademy2012BoF

KDE Quality Team BOF

Review of 4.9 testing

• Was really only a trial, went well.
• Definitely better than if we hadn't done anything
• Regression email to Plasma worked well (though should probably stop now)
• We need to scale up what we're doing into more areas, without doing a worse job on it

Improving User Testing

• The checklists in Plasma worked well, found (and fixed) many issues.
• This needs to be extended to everything
• AG, Copy Ubuntu's "checkboxes" (TODO find a link)
• It tells the user "do this [worked, broken, skip]"
• Then submits a report
• Don't be too specific in what to check, that way the user can spot bugs that are hard for automated testing to find.
• Less work to write than automated tests, and more flexible.

EBN

• too many false positives / minor issues hide the big issues
• Aleix Poi apparently has a static analyser written for a thesis we could look at.

Jenkins

• Needs to be more open
• We need examples/docs. What it does + how to use it.

Valgrind (memcheck)

• This is a useful test, however it's quite tricky to use/analyse, so reports should only be done by developers testing (to identify which lib a leak is in for example)
• Someone should write a wiki page on how to memcheck, filter out nonsense that we can't fix.
• Then submit leaks as bug reports with valgrind backtraces

Improving Tester numbers

• RG to make VirtualBox images of ProjectNeon. Has some issues, hopefully can all be fixed before 4.10

Release numbers

• AG suggested modifying the release numbers to something more easier.
  • 4.9.71 = alpha1
  • 4.9.72 = alpha2
  • 4.9.73 = alpha3
  • 4.9.81 = beta1
  • 4.9.82 = beta2
  • 4.9.91 = RC1
  • 4.9.92 = RC2

• suggest changing for 4.10

Other

• everyone should listen to Jeroen on bugzilla management.

Extra Mile

• [Insert Link to AG bof here]
• Was agreed to put it under the banner of "KDE Quality" and do the discussions/planning on our mailing list/IRC channel. If you have any objections to that, please raise them now.

Actions

• Write an email to the kde-release-team with the proposed release numbers
• Write a tool for showing "UI test steps"
• Write some test examples (suggest AG does gwenview, DE to do KTP, then we can encourage users to write tests for the others)
• Sort out Jenkins
• find a way to highlight the important issues in EBN
• Tools page in wiki needs splitting into debuggers/profilers (such as gammaray) and actual testing tools