Re: [Proposal] Test Day Guidelines

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




----- Original Message -----
> From: "Adam Williamson" <adamwill@xxxxxxxxxxxxxxxxx>
> To: "For testing and quality assurance of Fedora releases" <test@xxxxxxxxxxxxxxxxxxxxxxx>
> Sent: Thursday, April 12, 2018 3:57:33 AM
> Subject: Re: [Proposal] Test Day Guidelines
> 
> On Wed, 2018-04-11 at 03:23 -0400, Sumantro Mukherjee wrote:
> > Hey All,
> > 
> > I would like to make a proposal for updating and fleshing out some of test
> > day guideline.
> > 
> > To start with the wording on the Top of Test Day page:
> > If you come to this page before or after the test day is completed,
> > your testing is still valuable, and you can use the information on
> > this page to test, file any bugs you find at Bugzilla, and add your
> > results to the results section. If this page is more than a month old
> > when you arrive here, please check the current schedule and see if a
> > similar but more recent Test Day is planned or has already happened.
> 
> > # Proposal 1: We would also like people to *not* do testing if we are
> > testing something which are compose sensitive and post-test day
> > chasing and finding the same bugs in the compose and filing dups
> > won't make much sense. So, it will be best to reduce the time frame
> > from a month to a week.
> > Also, check the current schedule for something fresher and ready
> > requiring testing love.
> 
> I picked 'a month' more or less arbitrarily, 'a week' is certainly an
> OK choice too. Note that the template really is just a *template*, and
> can (and should!) be adapted to each event as appropriate. So if *some
> specific event* is very time sensitive, this text could be changed as
> appropriate - to say 'a day' or whatever.

True. I will keep this in mind from next time :)

> 
> > # Proposal 2: We would love to see more coverage on the test cases,
> > let's take Modularity and as an example, Contributors found bugs in
> > Rpi 3 (ARM) which weren't the case with x86_64, Profile field in the
> > test day results
> > page becomes very important and crucial. Maybe, we should avoid
> > putting "Fedora-Server-dvd-xxxxxyyyyyyz.n.0.iso" which doesn't give
> > much info about the testing environment or how it was executed. We
> > might
> > want to flesh out the importance of that field and it will be very
> > helpful in coming future.
> 
> I'm actually not quite sure what you're referring to here, or where the
> "Fedora-Server-dvd-xxxxxyyyyyyz.n.0.iso" example comes from. Could you
> provide a bit more context?


The context where it stems from was, if you have a look at http://testdays.fedorainfracloud.org/events/38
we have mostly all testers, mentioning Fedora 28 Server on (KVM,ARM,x86_64,VMware,ppc64le) which gives
us a bit more idea if there is a failure. Just writing Fedora server dvd gives us absolutely no idea as to how the
test were executed. In one certain case during Modularity test day, a certain issue just came up which was specific to
ARM ... the profile also lets us know about the coverage across archs and various virtualizations. I felt, we should,
flesh out a bit more about the importance of the same.


> 
> In general I'd certainly say that, again, the way in which result
> reporting is set up should be carefully considered for each individual
> test day; the template and SOP are only guides. You can set up a result
> table in many different ways to capture results from different
> combinations of environment factors...

yes, thats something I will look at :)

> 
> > # Proposal 3: Test Days have a specific team which takes on the task
> > of curating the #fedora-test-day channel and these are mostly the
> > people who are working on the feature being tested or developed for a
> > significant amount of time.
> > This is done to ensure that all the contributors/participants can pin
> > point folks who are playing the role they are designed for.It's in
> > the best interest of contributors that they shouldn't edit this
> > section as they misleading if done without proper knowledge.
> 
> Are you saying there should be a specifically-identified 'team' for
> each individual test day, or an ongoing permanent 'team' for test days
> as a whole? Either could potentially work, but I think the proposal
> could do with a few more details...


No, I am good with either, I am strictly against people editing the organizing list.
The team is defined and kept there to make sure the contributors know where to come and
whom to grab hold of , when something is breaking. Randomly editing the section renders to pupose moot.
Context:
[http://fedoraproject.org/wiki/Test_Day:2018-02-22_Kernel_4.15_Test_Day] 
[http://fedoraproject.org/wiki/Test_Day:2018-04-10_Add-On_Modularity_Test_Day]


> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> _______________________________________________
> test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 
_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux