• Name: Pre Release QA Process (Using Launchpad)

• Owner: Launchpad Team

• Effective: March 2010

Using Launchpad as main QA tool

Why are we doing this?

• Improve how we do QA today, by:
  • Being able to search items dynamically using Launchpad search and Launchpad API
  • Not forcing developers to edit the wiki pages to do their QA
• To reduce/eliminate the number of orphaned commits per cycle.
• To make easier and more reliable to gather stats of the cycle

What are we doing?

• The experiment consists in using Launchpad to know which bugs are yet to be tested, and to test them using the information we already have in the Merge Proposals (now shown in the bug page). It's easier to be consistent when data is centralized.

What are the risks?

• Leave untested items behind. By ignoring orphaned commits, assuming they don't need to be tested, it's possible to miss items that should be QAed because people forget to add bug numbers to their commit messages.
  • The script tries to workaround this by trying to identify the branch that originated that revision, finding on Launchpad its linked bugs. We need to guarantee that people will link bugs to branches for this to be successful.
• Face limitations of Launchpad search that creates barriers instead of removing them;
• Testing not properly, considering we're using the instructions in the MP and this could be incomplete. This means, no more wiki free editable information to describe the test.
  • We can workaround this by assuring people will detail their tests well in the MP, and if not, do that in the bug itself.

How will we know if we were successful?

• The intention is to make QA easier by using only Launchpad and removing the need of editing wiki pages, so we'll know we're successful when we have few (or none) items pending to test during the cycle.

Process under experiment

The process mainly consists in replacing the old testitems in wikipages by bugs in Launchpad, that will carry qa tags to show how they look in the QA process.

The tags

Bugs can have one of the five qa tags:

• qa-needstesting: the script should add this tag when the bug is ready to be QAed. Don't add it manually! It's the only tag you shouldn't care about setting. From the moment the bug has this tag on, you're allowed to change for one of the other tags.
• qa-ok: when your bug is QAed and OK, just remove the qa-needstesting and add a qa-ok. The same as moving your old test item from the NEEDSTESTING section to the OK one.

• qa-bad: similarly to qa-ok, but when your bug isn't working as expected, of course.

• qa-untestable: to those items that can't be QAed for some reason. I still don't know how useful this tag is, given all items we cannot test shouldn't have bugs.
• qa-rcfixed: when a bug is fixed in RC mode.

The script

A script monitors the main Launchpad branches, and handles the new revisions as explained below:

• For each new merged revision:
  • Checks if the commit is a testfix or a buildbot commit. Those are automatically ignored. [1]
  • If not, tries to find out the bugs related to that commit:
    • By looking in the commit message;
    • By looking at the branch nick;
    • By fetching the original merged branch in Launchpad, examining if there are linked bugs.
  • If bugs were found:
    • Marks them as Fix Committed;
    • Adds a comment in the bugs, documenting which commit was responsible for that status change;
    • Adds the "qa-needstesting" tag. If another qa tag has been found, removes it and adds the qa-needstesting one. It assumes the commit is trying to fix the bug again, so should be re-tested.
    • Assigns the bug to the committer, if the bug has no assignees.
    • Assigns the bug to the current milestone, to guarantee the burndown script will find only bugs related to the present cycle.
  • If no bugs are found, the commit is considered orphaned, and ignored.[2]
• To have a list of items one should QA, do the following advanced bug search in Launchpad [3]:
  • With Fix Committed or Fix Released status;
  • Targeted to any of the current milestones for all projects;
  • With qa-needstesting tag;
  • That are assigned to the person;
  • Don't hide duplicates (some bugs fixed may be dupes of others and not show as pending).

It's possible to search a person qa-needstesting bugs through a Launchpad search like this: https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&assignee_option=choose&field.omit_dupes.used=&field.tag=qa-needstesting&field.assignee=ursinha .

[1] Testfixes need to be separated commits. They're ignored, so should be really only testfixes. Do not commit bug fixes along with testfixes.

[2] Be careful when writing your commit message. If you use ec2test script, it should automatically add the bug number to the commit message. If you don't, and you forget to add it manually, the script will try to find out if the bug number is mentioned in the merged branch nick or if the merged branch has linked bugs. If everything fails, bzzt, your commit goes to /dev/null. So, if your branch needs QA, be sure to add the bug numbers, all of them, to the commit message, and link them to your branch in Launchpad, otherwise it will fall into oblivion. The script isn't creating bugs to orphaned commits because we QA bugs, not branches, and by creating bugs for each branch we're possibly filing a bunch of invalid bugs, that will take some time to be triaged. (Hopefully) most orphaned commits in fact don't need any QA. A script is being implemented to send developers a daily email with their orphaned items, until we reach a very low error ratio. So, if the items are really orphaned, can be safely ignored. One alternative to that is always adding the tag bug to the commit message, but having it with value None (as we do with ui) when no QA is needed, but this approach wasn't well accepted when suggested in the mailing list.

[3] A list of of QA items by milestone can be found at http://people.canonical.com/~lpqateam/testplans/

Comments

• Launchpad doesn't have in its UI a way to do a search so we'd get the same results we have in the testplan page, that are all items of all members of that team. We only can search items per team, per tag or per assignee (one at a time). So if someone commits a fix for a bug of other team it will only show up in the search for his own bugs, and not the team's (project). I've filed a bug for that: https://bugs.edge.launchpad.net/malone/+bug/520569.