[Meego-community] qa vs. quality for MeeGo.com

Fri Jun 4 00:12:51 PDT 2010

Hi

I would like to proceed like this, please comment:
1) set quality guidelines for requirements (which we will get public soon) and review those when available
2) set quality targets for different phases of release creation (like you mentioned alpha/beta etc).
3) create and agree on base guidelines for test asset management, test case creation / review (we are working on proposals already) and publish tool for storing the cases. Ville will propose test case documentation formats (xml) and we need to agree on test case template as well.
4) set test coverage targets for components (as you mentioned) and start publishing test asset according to agreed process and approach (points 2 & 3)
5) set testing targets for integrations and start agreeing asset together with maintainers (when nominated) and set up the test system so that those could be run automatically
6) Agree how to publish test results so we all share a common view about the SW quality

I have understood that we get the release creation bases and life cycle (published in fiev days) so we can start working based on that.

V-PV

-----Original Message-----
From: sivang at gmail.com [mailto:sivang at gmail.com] On Behalf Of ext Sivan Greenberg
Sent: 02. kesäkuuta 2010 22:04
To: Vatula Veli-Pekka (Nokia-D/Tampere)
Cc: Tahvanainen Jari (Nokia-D/Helsinki); meego-community at meego.com
Subject: Re: [Meego-community] qa vs. quality for MeeGo.com

Hi Veli,

 Yes, I like this approach as well as the items you listed there. So
let's indeed co-ordinate and work on quality topics there.

 I propose we start by getting a thorough specification of what
functionality each currently available component (=package?) provides,
and then create unit test plans to test cover it with every iteration
of the release (minor/alpha/beta/RC/final).

 I then propose that we move on to integration test plan authoring,
meaning to cover test cases of component X that is supposed to
integrate with with component Y and Z and write test plans that verify
the integration is working as expected. That of course would require
us to first survey and specify what higher level functionality each
integration combination yields.

How does that sound?

Sivan

On Wed, Jun 2, 2010 at 7:32 AM,  <veli-pekka.vatula at nokia.com> wrote:
> Hi
>
> About openness of QA, I do not see why this should be closed. Anybody can experience it anyhow.
> I think it so that from MeeGo perspective it is good to share test assets, get contributions to it and also let Community participate testing.
>
> So, about QA WG Proposal, to me it sounds like a good idea to start working on quality topics with that page.
> I BTW listed there (rudely) a couple of things related to it, which I think we need to consider as well. If this approach is ok to you Sivan (as a owner of page) let's start working with that.
>
> V-PV
>
> -----Original Message-----
> From: sivang at gmail.com [mailto:sivang at gmail.com] On Behalf Of ext Sivan Greenberg
> Sent: 01. kesäkuuta 2010 11:46
> To: Vatula Veli-Pekka (Nokia-D/Tampere)
> Cc: Tahvanainen Jari (Nokia-D/Helsinki); meego-community at meego.com
> Subject: Re: [Meego-community] qa vs. quality for MeeGo.com
>
> My understanding is that this is going to be an internal thing, if you
> have other input I'd love to hear.
>
> Otherwise, yes, my QAWG proposal is there, although very thin since I
> did not have much time to love it so far, but we can use this as a
> starting point to brainstorm and collaborate.
>
> e.g. according to the lists the TSG is unlikely to approve something
> like that in the near future, so better we start doing work and find
> out what we can do before embarking on new subdomains.
>
> I also like the "quality." for the record.
>
> Sivan
>
> On Tue, Jun 1, 2010 at 11:07 AM,  <veli-pekka.vatula at nokia.com> wrote:
>> Hi
>>
>>
>>
>> To your question, personally I prefer QA.
>>
>>
>>
>> I have understood from TSG members
>> (http://meego.com/sites/all/files/MeeGoDevStructureTSG_May5.pdf) that QA WG
>> will not be established as such, rather MeeGo will be having QA Team. So,
>> before we get name decided and web established we could utilize QA WG Wiki
>> to start with. Just changing the name.
>>
>>
>>
>> V-PV
>>
>> ---
>>
>>  Veli-Pekka Vatula
>>
>>
>>
>> From: meego-community-bounces at meego.com
>> [mailto:meego-community-bounces at meego.com] On Behalf Of Tahvanainen Jari
>> (Nokia-D/Helsinki)
>> Sent: 01. kesäkuuta 2010 10:39
>> To: meego-community at meego.com
>> Subject: [Meego-community] qa vs. quality for MeeGo.com
>>
>>
>>
>> Hi all,
>>
>>
>>
>> I'm one of those quality and testing obsessed fellows ;-)
>>
>> In order to make quality/testing work more visible I would like to have
>> quality/testing collaboration space.
>>
>>
>>
>> So, how about http://qa.meego.com ?
>>
>> Or do you prefer http://quality.meego.com ?
>>
>> Or something else?
>>
>>
>>
>> Doing a bit of research it looks like ubuntu.org is having qa.ubuntu.com
>> while Mozilla is having quality.mozilla.org. Now, that's not a large number
>> of organizations, but I suppose these two examples are including the purpose
>> of this particular collaboration space.
>>
>>
>>
>> And after getting consensus on this we can have both IRC channel
>> #meego-[qa|quality|something_else] and mailing
>>
>> list with the same naming scheme.
>>
>>
>>
>> Br, Jari
>>
>> Jari Tahvanainen
>>
>> Quality (with common sense) Obsessed
>>
>> _______________________________________________
>> Meego-community mailing list
>> Meego-community at meego.com
>> http://lists.meego.com/listinfo/meego-community
>>
>>
>