Get Involved/Quality/Akademy2012BoF: Difference between revisions

From KDE Community Wiki
(Initial Import from text)
 
 
(10 intermediate revisions by 2 users not shown)
Line 1: Line 1:
KDE Quality Team BOF
KDE Quality Team BOF


== Review of 4.9 testing ==


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


Improving User Testing
== 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,


EBN
* The checklists in Plasma worked well, found (and fixed) many issues.
- too many false positives / minor issues hide the big issues
* This needs to be extended to everything
- Aleix Poi apparently has a static analyser written for a thesis we could look at.
* Aurélien Gateau, 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.


Jenkins:
== EBN ==
- Needs to be more open
- We need examples/docs
- What it does + how to use it.


* 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.


Valgrind (memcheck):
== Jenkins ==
- 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:
* Needs to be more open
- RG to make VirtualBox images of ProjectNeon. Has some issues, hopefully can all be fixed before 4.10
* We need examples/docs. What it does + how to use it.


Release numbers:
== Valgrind (memcheck) ==
- AG suggested modifying the release numbers to something more easier.
 
  4.9.71 = alpha1
* 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)
  4.9.72 = alpha2
* Someone should write a wiki page on how to memcheck, filter out nonsense that we can't fix.
  4.9.73 = alpha3
* Then submit leaks as bug reports with valgrind backtraces
  4.9.81 = beta1
 
  4.9.82 = beta2
== Improving Tester numbers ==
  4.9.91 = RC1
 
  4.9.92 = RC2
* Rohan Garg to make VirtualBox images of ProjectNeon. Has some issues, hopefully can all be fixed before 4.10
 
== Release numbers ==
 
* Aurélien Gateau 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
* suggest changing for 4.10
 
== Other ==
 
* everyone should listen to Jeroen on bugzilla management.
 
== Extra Mile ==
 
* [http://community.kde.org/Akademy/2012/Extra_Mile_BoF Extra Mile BoF]
* 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 (Albert attended the BoF, he already knows about)
* Write a tool for showing "UI test steps"
* Write some test examples (suggest Aurélien Gateau does gwenview, David Edmundson 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


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:
[[Category:Testing]]
- 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

Latest revision as of 01:42, 16 February 2015

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
  • Aurélien Gateau, 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

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

Release numbers

  • Aurélien Gateau 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

  • Extra Mile BoF
  • 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 (Albert attended the BoF, he already knows about)
  • Write a tool for showing "UI test steps"
  • Write some test examples (suggest Aurélien Gateau does gwenview, David Edmundson 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
Retrieved from "https://community.kde.org/index.php?title=Get_Involved/Quality/Akademy2012BoF&oldid=41608"