gathering useful statistics for QA team

"Jóhann B. Guðmundsson" johannbg at gmail.com
Tue Jul 20 19:38:42 UTC 2010


  On 07/20/2010 05:48 PM, James Laska wrote:
> I think you've only captured part of the motivation for this.
> Recognition for hard work is a motivator for some people, but not all.
> Long story short, you can't improve what you don't measure.

I whole heartily agree that you can't improve what you don't measure I 
just simply don't agree with the "Hall of Fame" approach where ever in 
the community since I think it will in the long run have more negative 
effects then positive and lead to more divided community for various 
human behavioural issues + trying to accurately measuring individual 
contribution is a bit hard ( quantity vs quality of the contribution ).

We will need to go back to first release to be able to get measurements 
of several key changes we made to see if we went out of something that 
work into something that did not work and at the same time stepping back 
and look at all of the community activity which may have work in Y but 
not Z part of the community etc.

To give one QA specific example that's the evolution from 
alpha,beta,preview -->  nightly builds + alpha,beta,preview and now 
boot.fedoraproject.org + alpha,beta,preview. Once we have those metric 
we can start asking us how have these changes affected the QA community 
like did we get more or less testing? Was it because of these changes or 
was it because of some high profile features happening at the same time 
etc.

Another QA specific example would be AutoQA so fourth so on.

Anyway to be effective in analyze various community/individual ) 
activity including our own and since the product we ship is you know 
"code" we need to have the stats on the components in place to the very 
beginning and once we have those stats in place then each team can start 
asking itself various questions, what changes happened in the code and 
how it affected that's team purpose within the community and what the 
team was trying to achieve at the same time.

And it's very vital for us in QA that we have the component stats before 
we can start measuring anything we do and have done in any useful manner 
as far as I see it.

JBG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/test/attachments/20100720/25018780/attachment.html 


More information about the test mailing list