QA Feature Testing

Registered by Craig Hrabal

This blueprint has been superseded. See the newer blueprint "Expanding QA community coverage" for updated plans.

[crhrabal] Lets have deeper qa testing into experimental new packages like newest
unity, HUD2, 100 Scopes Project, Smart Scopes, Mir, experimental kernels, Ubuntu Touch Core Apps. Basically, allow for new feature elements to get more qa tracking
and create a much larger group of testcases. Possibly on some form of qa
tracking like iso.qa.ubuntu.com.

I'd like to refer to Nicholas Skaggs' blog, which lists the perceptions survey many months back:
http://www.theorangenotebook.com/2012/08/quality-perceptions-survey-results.html

I think that by addressing feature elements and in-development package testing early, we can address these user statistics. When asked "What Does Quality Mean To You?" most users said "Quality means the default desktop and applications should work without crashing." When asked "What's the biggest problem with quality in Ubuntu right now?" most users chose "Applications are always crashing"

By pushing more testing on feature elements and experimental packages, it will ensure that new features and packages have more testing and better quality.

Blueprint information

Status:
Complete
Approver:
Nicholas Skaggs
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
Superseded
Series goal:
Proposed for saucy
Implementation:
Unknown
Milestone target:
milestone icon ubuntu-13.10
Completed by
Nicholas Skaggs

Related branches

Sprints

Whiteboard

[smartboyhw] Here's my idea:
Use the current Packages QA Tracker (https://packages.qa.ubuntu.com) and put all applications which we hae testcases (or kernels or Unity or Smart Scopes or whatever) and we need to make sure these items were never marked as "Released"..

We can track packages according to the package version, like what Netboot ISO does (debian-installer). People who have subscribed to the package testcases and whenever there is a new Ubuntu version they can test it.

Each week (or cadence week) we tell people: "Hey, this week we want to test this specific app, but there are other packages you can test also!" this can strengthen package testing.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.