Diff for "PolicyAndProcess/QAProcess"

Not logged in - Log In / Register

Differences between revisions 2 and 3
Revision 2 as of 2009-11-30 03:44:12
Size: 2523
Editor: ursinha
Comment:
Revision 3 as of 2009-11-30 18:06:11
Size: 2940
Editor: ursinha
Comment:
Deletions are marked like this. Additions are marked like this.
Line 21: Line 21:

    * Running an automated script that watches the main development branches analysing the commits one by one, as the current test-plan tool does, but instead of adding all items to the wiki test plans, it marks the mentioned bug as Fix Committed in Launchpad, adds a comment to it documenting which commit was responsible for that status change, and adds the qa-needstesting tag. If the commit is an orphaned one, it adds to the team wiki page as a fallback.
    * All the orphaned commits need to be handled by creating one bug for it. The goal is to eliminate orphaned commits per cycle.
    * The search for items to QA to a given person can be done through an advanced bug search in Launchpad:
       * with Fix Committed or Fix Released status
       * with qa-needstesting tag
       * that are assigned to you
       * Don't hide duplicates (some bugs fixed may be dupes of others and not show as pending)
       * Eating our own dogfood. :) 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 use all that organized and aggregated information than use some parallel that contains duplicated data. Also it's much easier to change a status of a bug from untested to tested than editing the Test Plan wiki page.
Line 41: Line 35:
    * Explained in "What we are doing?"     * Running an automated script that watches the main development branches analysing the commits one by one, as the current test-plan tool does, but instead of adding all items to the wiki test plans, it marks the mentioned bug as Fix Committed in Launchpad, adds a comment to it documenting which commit was responsible for that status change, and adds the qa-needstesting tag. If the commit is an orphaned one, it adds to the team wiki page as a fallback.
    * All the orphaned commits need to be handled by creating one bug for it. The goal is to eliminate orphaned commits per cycle.
    * The search for items to QA to a given person can be done through an advanced bug search in Launchpad:
       * with Fix Committed or Fix Released status
       * with qa-needstesting tag
       * that are assigned to you
       * Don't hide duplicates (some bugs fixed may be dupes of others and not show as pending)

  • Name: Pre Release QA Process (Using Launchpad)

  • Owner: Launchpad Team

  • Effective: Under experiment as of 2009-10-01.

  • Experiment: Will replace Pre Release QA Process

  • Review: 2009-12-01

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?

  • Eating our own dogfood. :) 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 use all that organized and aggregated information than use some parallel that contains duplicated data. Also it's much easier to change a status of a bug from untested to tested than editing the Test Plan wiki page.

What are the risks?

  • Leave untested items behind, if not using a bookmarked advanced Launchpad search;
  • Face limitations of Launchpad search that creates barriers instead of removing them;

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

  • Running an automated script that watches the main development branches analysing the commits one by one, as the current test-plan tool does, but instead of adding all items to the wiki test plans, it marks the mentioned bug as Fix Committed in Launchpad, adds a comment to it documenting which commit was responsible for that status change, and adds the qa-needstesting tag. If the commit is an orphaned one, it adds to the team wiki page as a fallback.
  • All the orphaned commits need to be handled by creating one bug for it. The goal is to eliminate orphaned commits per cycle.
  • The search for items to QA to a given person can be done through an advanced bug search in Launchpad:
    • with Fix Committed or Fix Released status
    • with qa-needstesting tag
    • that are assigned to you
    • Don't hide duplicates (some bugs fixed may be dupes of others and not show as pending)

Comments

  • Launchpad doesn't have in its UI a way to do a full search per team members, as if we're looking in the Wiki page. We only can search items for team or for tag.

PolicyAndProcess/QAProcess (last edited 2017-03-30 14:19:02 by cjwatson)