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 <qgil(a)wikimedia.org> wrote:
This proposal got a basic agreement and is being
implemented at
https://www.mediawiki.org/**wiki/QA/Weekly_goals<https://www.mediawiki.o…
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/…
______________________________**_________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.…