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

Mon Jun 7 00:28:56 PDT 2010

Veli, if this is sort of a thread hi-jacking I apologize in advance...;)

Since you just noted that community stuff may be "bleeding edge" I
would like to see us provide some protection and rollback mechanism
for going back before a "bleeding edge" app was installed and consumed
the whole rootfs, or changed some hardware setup in a breaking way
etc.

Just one more thing to note- Having something like this would enable
us also to get more people to test as they know they have some "back
to working state" way after they've tested a community app.

Sivan

On Mon, Jun 7, 2010 at 10:08 AM, Yu, Ling L <ling.l.yu at intel.com> wrote:
> For website, I personally prefer to qa.meego.com.
>
> And I would suggest publishing the process and content which community will interest in so that we could attract more contribution from community. The simplified process instead of a full life cycle will be better for an open source project because it is easy to follow.
>
> The content organization on the web site could align with MeeGo arch, that is, create separate sections for Core and different verticals. Of course, test tools and automated test system should be in dedicated section.
>
> Each section could cover the common QA activities and their required materials:
> - Test plans, e.g. overall test plan for each verticals and test plan for each component
> - Released test suites
> - Quality metric of Meego, e.g. bug trend, test pass rate .
> - Hardware devices to be tested
> - Test methodology, for example, Netbook UX test method or application test guideline
>
> With above content, we can encourage community to do broad testing and contribute test cases, test results and etc. That will be great if there is a central place to collect the test results contributed by community.
>
> Thanks
> -Ling
>
>
> -----Original Message-----
> From: meego-community-bounces at meego.com [mailto:meego-community-bounces at meego.com] On Behalf Of veli-pekka.vatula at nokia.com
> Sent: Friday, June 04, 2010 3:13 PM
> To: sivan at omniqueue.com
> Cc: meego-community at meego.com
> Subject: Re: [Meego-community] qa vs. quality for MeeGo.com
>
> 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
>>>
>>>
>>
> _______________________________________________
> Meego-community mailing list
> Meego-community at meego.com
> http://lists.meego.com/listinfo/meego-community
>