We in QA discussed some possibilities for the browser test automation community activities, and we suggest that the first couple of community events be educational. In particular, we think it would be beneficial to start with some introductory topics to be presented as a hangout+IRC chat+documentation on the wiki. Our suggestions for the first two events:
* how anyone can write an Test Scenario to be automated (and why this is important!) * how to read, understand and analyze results in the Jenkins system we have for browser automation -Chris On Wed, Jan 23, 2013 at 2:56 PM, Quim Gil <[email protected]> wrote: > This proposal got a basic agreement and is being implemented at > > https://www.mediawiki.org/**wiki/QA/Weekly_goals<https://www.mediawiki.org/wiki/QA/Weekly_goals> > > A rough start is expected in the first iteration of the four areas but we > hope to have improvements every week. > > Get involved! > > Development teams: your proposals for testing & bug management weekly > goals are welcome. > > > > On 01/16/2013 02:25 PM, Quim Gil wrote: > >> There are ongoing separate discussions about the best way to organize >> testing sprints and bug days. The more we talk and the more we delay the >> beginning of continuous activities the more I believe the solution is >> common for both: >> >> Smaller activities and more frequent. Each one of them less ambitious >> but more precise. Not requiring by default the involvement of developer >> teams. Especially not requiring the involvement of WMF dev teams. >> >> Of course we want to work together with development teams! But just not >> wait for them. They tend to be busy, willing and at the same time >> unwilling (a problem we need to solve but not necessarily before >> starting a routine of testing and bug management activities. If a dev >> team (WMF or not) wants to have dedicated testing and bug management >> activities we will give them the top priority. >> >> >> Imagine this wheel: >> >> Week 1: manual testing (Chris) >> >> Week 2: fresh bugs (Andre) >> >> Week 3: browser testing (Željko) >> >> Week 4: rotten bugs (Valerie) >> >> >> All the better if there is certain correlation between testing and bugs >> activities, but no problem if there is none. >> >> From the point of view of the week coordinators this is how a cycle >> would look like: >> >> Week 1: decide the goal of the next activity. >> >> Weeks 2-3: preparing documentation, recruiting participants. >> >> Week 4: DIY activities start. Support via IRC & mailing list. >> Group sprint on Wed/Thu >> DIY activities continue. >> >> Week 4+1: Evaluation of results. Goal of the next activity.... >> >> >> During the group sprints there would be secondary DIY tasks for those >> happy to participate but not fond of the main goal of the week. >> >> If one group needs more than one activity per month they can start >> overflowing the following week, resulting in simultaneous testing & bugs >> activities. >> >> Compared to the current situation, this wheel looks powerful and at the >> same time relatively easy to set up. There will plenty of things to >> improve and fine tune, but probably none of them will require to stop >> the wheel. >> >> What do you think? >> >> > > -- > Quim Gil > Technical Contributor Coordinator @ Wikimedia Foundation > http://www.mediawiki.org/wiki/**User:Qgil<http://www.mediawiki.org/wiki/User:Qgil> > > ______________________________**_________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.wikimedia.org/mailman/listinfo/wikitech-l> > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
