A fruitful week

  I thought I would write up my prior week activities as it was an unusually varied week, where I got to try a lot of new things.

  Starting off last Tuesday, we had an IRC meeting for the Outreach Program for Women, where I got to hear about the projects all the interns are working on.  Here is a description of how the meeting went from an email that I sent to my mentor Zeljko:

  "All 37 of the interns introduced ourselves and talked about our projects. I mentioned that we are looking for volunteers to help us do Cucumber/Ruby test cases, and one of the OPW interns messaged me that she was interested in helping us!  She is familiar with Gherkin, which I believe is the language for Cucumber. (editors note: Yes, I confirmed Gherkin is the language for Cucumber).  Anyhow, I sent her the link for our QA mailing list, and she signed up while we were chatting!   Her name is Shivani Poddar and here is her blog: http://shivanipoddar.wordpress.com blog. She is working on the Gnome Music project for her internship.   I also learned there is a $500 travel allowance for each OPW intern...I'm not sure of the criteria but I can send the complete transcript of the session when I receive it from Marina who runs OPW.
Also I discovered Marina, who runs the OPW program at Gnome, works nearby which is quite amazing.  We are going to try to meet up on Thursday for coffee . So, I found it to be an enjoyable and productive meeting."

  The next day, Zeljko requested that I test the new Mediawiki-Vagrant software that has recently been developed at Wikimedia.  MediaWiki-Vagrant is a nifty piece of software that creates a portable MediaWiki development environment.  It consists of a set of configuration scripts for Vagrant and VirtualBox that automate the creation of a virtual machine that runs MediaWiki software.  Once installed, there are a number of configurations or "roles" that can be set up for this software.  The one we are using is the Selenium automated testing role.  I was asked to document the steps it took to get this working on Windows, so that volunteers could use Mediawiki_Vagrant to automatically set up their own QA environments for the upcoming workshop.  Rather than having to install Ruby and the other QA tools, they can just run Mediawiki-Vagrant to get their test environments set up automatically.  The software had already been tested on Ubuntu and Mac, and my job was to test it on my Windows machine.  Well, this turned out to be more than I had bargained for.  All three pieces of software (VirtualBox, Vagrant and MediaWiki-Vagrant)  are needed to make MediaWiki-Vagrant work, and there was a lot to learn as I installed and tested the software.  One problem I discovered is that  Mediawiki-Vagrant won't work if it is installed in the  C:\Program Files directory.  It doesn't like the spaces in the name, Program Files, and the command "vagrant up" that starts the config process will bomb out as a result.  This wasn't obvious at first, but after some in-depth troubleshooting I was able to figure it out.  I then reinstalled MediaWiki-Vagrant at the C:\ level, and the "vagrant up" command worked, and config completed successfully.  I then changed the roles.yaml file to point to selenium testing, and ran one of our tests.  This time I got another error message: "Unable to pick a platform for the provided browser (RuntimeError)", at which point Zeljko pointed me to a section about Adding a Gui  that he thought would solve the problem.  After installing the Nomachine client as suggested, I am still unable to connect to mediawiki-vagrant.dev through NoMachine.  If anyone has gotten NoMachine working with Vagrant on Windows, please drop me a line in either the comments or in email to let me know how you did it.


On Thursday, we ran a great QA Automation Workshop for volunteers.  It was Zeljko's first time running a workshop, and my first time helping out with one.  He did a great job explaining the material and keeping everyone engaged.  During the workshop, Zeljko used our Cucumber/Ruby/Selenium tools to demonstrate how to write and run an actual test for the Wikilove feature of Wikipedia..  I would encourage you all to watch the YouTube video of his presentation, or at least part of it, to get an idea of how we run our workshops at Wikimedia.  In this case, the workshop was not onsite at the Wikimedia offices, but was run completely remote through Google Hangout.  (You may want to skip the first 3-4 minutes of the video as we were we sorting out technical difficulties getting the video feed working ).  I have been impressed by the number of volunteers that have turned out for our QA workshops.  For this workshop, we had 11 volunteers attending!  Some of them have already contributed to our QA efforts by writing new tests for us, or by fixing easy bugs.  We have just set up a link to our easy bugs in Bugzilla, so volunteers are able to browse for bugs that are easy to fix, assign a bug to themselves, and then work on fixing it.

After the workshop, I was able to run out and meet Marina Zhurakhinskaya for coffee, which was totally awesome.  I learned a lot from her about the history of the OPW program and more about the FOSS movement.

Of course, in between all of these events I was hard at work on another Visual Editor test that checks if  Visual Editor is present when user logs in.

 So, all in all, a very productive and interesting week.  Now it looks like I've caught up a bit with my writeups, so I will try to keep it up and catch up on the current week's activities in my next blog.

 
Anyone interested in helping us write QA tests?
Please sign up at our Wikimedia QA mailing list.

Further questions or queries?  Feel free to email me at rachelqa99 [at] gmail [dot] com .

Thank you for your interest :)

How I got to my first finished test

   Sorry, I am afraid that I have neglected my blog as of late.  Life has a way of getting in the way!  I have had my plate full to the brim doing my OPW internship, and at the same time I am doing a lot of juggling coordinating my kids summer schedules and mine.  It has been an extremely hectic few weeks, but I hope at this point things are settling down, and I will have more opportunity to blog.

   As I mentioned in the last entry, my project this summer is to provide a battery of tests for the new WYSIWYG editor feature of Wikipedia, called Visual Editor.  Visual Editor is an important new feature that was launched in July to all logged-in and anonymous users as the default editor for the English-language Wikipedia. It is expected to be deployed to almost all Wikipedias by the end of July, making it available for all editors.  There are a huge number of things to be tested within Visual Editor, so I am planning to do a battery of tests on some parts of it, rather than attempt to cover it all.  One of the first things I decided to test is to make sure that links are working properly within the Visual Editor.  As I wrote the test case for the links feature, I was pleased that I also made progress towards my individual goal of learning Cucumber, Ruby and Page Object Design.  Finally, last week after 19 commits over several weeks,  I was able to reach a milestone and commit the test as finished.  After this last commit, my links test was merged into our master repository.  The link test is now part of the automated browser-level tests that run continuously on our Jenkins instance, doing compatibility and regression testing.

  It is a good feeling to know that I have completed a test that is already being run by WMF to check that links are functioning properly in the newly released Visual Editor feature.  So what did it take to get to this final commit for my Visual Editor links test?  Well, a lot of elbow grease, more than anything else.  This is what I've always found to be the main ingredient when coding.  A lot of trial and error has to happen before you get to the point where you are able to get your final code committed.  In  this case, there were 19 commits along the way to getting the test case finished.  There was also a lot of help I received along the way from my mentor Chris McMahon, who pair programmed with me several times as we developed the tests.  I have found pair programming is an extremely effective technique, and I'm pleased that Chris and Zeljko have introduced me to the concept.  I have found that you can learn much more efficiently and quickly when you pair program, especially at the earlier stage of coding in new languages.

  I ran into several other issues as I developed the code for the link test.  One early issue was that Chris realized some of my Cucumber code duplicated code we had already written for other tests, so he had to refactor the Cucumber links script I had written.  This meant that I had to redo some of the coding on my Ruby scripts that corresponded to changes he made to the Cucumber script after refactoring.  I believe that due to the fact we were pair programming, this was caught before too much time went by, and it was a relatively easy change for me.  If I had handed the test case over after weeks of working on it by myself, it probably would have taken me much longer to rework the code.  This is example of how pair programming can work well, and can end up saving time in the end.

  Another problem I ran into as I developed my Cucumber feature script was that the sequence of steps I had created in Cucumber did not create the proper link in the Link UI.  Upon looking at the Link UI, I realized I was missing a step.  I then had to add the missing step to my Cucumber script to make it work properly.  Another issue I encountered towards the end of my coding was the need to reformat some of my scripts to get rid of the extra white-space and new lines.  It was also necessary to rename the script from ve_links.feature to visual_editor.links.feature to correspond to the naming conventions we were using.  In a nutshell, these were some of the challenges I faced when creating my links test.

Now for some public service announcements concerning Wikimedia automation testing..

Coming this Thursday, July 18th...
 QA automation workshop at  16:00 UTC !  Workshop is being held at this time especially for our Asia/European volunteers to get onboard!  Please sign up at the link if you are interested in learning or working with Cucumber and Ruby and contributing to our test case coverage.



Can't make it but are interested in learning more about current and future WMF QA activities?  Please sign up at our Wikimedia QA mailing list.

Further questions or interested in volunteering to write tests?  Feel free to email me at rachelqa99 [at] gmail [dot] com .

Thank you for your interest :)