Moving to the Hardware Certification Team

After two years and a half in the Ubuntu QA team I have moved to the Hardware Certification team, on Platform Services. I was very happy to be given the opportunity to join the Hardware Certification team and I couldn’t reject. I am very excited to be able to help in the goal of making Canonical profitable.

How will that affect my collaboration with Ubuntu QA

It is been a great pleasure to work all this time with a great group of people  (both Canonical and non-Canonical). Obviously, as working directly on Ubuntu QA won’t be part of my paid job, I won’t be able to dedicate it as much as time as I did before. So, first of all, sorry if I am not getting back to you as quickly as I did in the past. But I love the Ubuntu QA community and I am still part of it. I will still be working on some of the things I did before, in my spare time. There are some projects, like the Desktop Testing Program or Desktop Testing Automation that are very close to my heart and I would like to stay somehow involved with them, I will try to attend the Ubuntu QA meeting at least twice per month and I will stay active in the ubuntu-qa mailing list.

The Hardware Certification Team

Having a successful certification program is both beneficial for vendors, ensuring their costumers that the hardware will work with Ubuntu, and the Ubuntu community, as they have access to the list of systems that work out of the box. We agree that sometimes we don’t expose the Hardware Certification program to our community as much as we should. There are people very active in the Ubuntu development that don’t know that Canonical has a public website where people can check what systems are certified to work with Ubuntu or even that the certification program exists. We don’t keep it as a secret, though; the Hardware Certification team has been attending UDS, our main testing tool is open sourced and installed by default in Ubuntu and, as I said, the systems that have been certified are published. I understand that we can do a better job explaining how the hardware certification program itself works and keep it more in the open, accepting suggestion and criticism.

To start with, Victor, the Hardware Certification team manager, has written a wiki page to explain a bit how the certification programs works and we have now a public project in Launchpad where you will be able to file bugs related to the project or ask questions. We would love to hear your thoughts and feedback about the program. In return, we will make our best to improve the program in ways that makes it more useful for our community.

Magomatic

It’s been a while since the last time I blogged about Mago, but Natty is going to be an exciting cycle for desktop testing automation (a lot is happening!) and I would like to present some of the work we have been doing.

Today I will write about Magomatic, a new side project related to Mago.

If you have tried to add a new testcases to an existing Mago wrapper, you can see that this is pretty straight forward. Most of the things that you need are already there, and you need to add only the code of the test, without thinking on the accessibility information of the application (OK, sometimes you have to, but it is quite simple to start the process). If you, however, have ever tried to add a new wrapper application to Mago I guess that you have found the process a bit difficult: you need to understand how the accessibility information is presented by LDTP, you need to create the application python file, you also will have to create a test suite python file, and a XML data file. This is time consuming and I though it could (and should) be automated.

So I created Magomatic. And how does it work?

Magomatic uses templates and accessibility information to create those files for you. Using it is pretty straight forward:

1. Open the application you want to create the wrapper for.
2. Run Magomatic:

   $ bzr branch lp:magomatic
   $ cd magomatic/bin
   $ ./magomatic

3. When prompted, you will need to select the window you want to create the wrapper for with the mouse pointer.
4. Done! Under the

   data/

   folder you will find a folder with the name of the application with the needed files to add to Mago and start coding your tests.

This is a work in progress, but the main and most important functionality is already there. We really hope that this will lower the entry barrier to Mago and more people will join us adding new tests in the Natty cycle.

HW Certification jobs at Canonical

The HW Certification team at Canonical is hiring three localized engineers: one in our offices in Lexington (MA), USA; one in Taipei, Taiwan; and one in Montréal, Canada.

The HW Certification team, part of Platform Services, provides certification as a service to partners. Basically, if a computer vendor wants to get one of their machines certified to work nicely with Ubuntu, they can buy this service.

The variety of work involved in our side is big and fun: from receiving the machines to be certified (some of them even brand new machines not yet public!), to commercial relationships, passing from a lot (a lot!) of technical work: writing testcases, maintaining our testing infrastructure, etc.

For me, working at Canonical, has been (and it is) the best professional experience I have had so far. It is great to be able to work in such a great environment, with very smart people and making Ubuntu better for everybody. I truly recommend Canonical as workplace. Please, ping me me on IRC if you would like to know more about how it is to work here.

So, if you live in any of these three locations or are willing to relocate (Canonical does not offer a relocation package), please, have a look to the following job descriptions and send your resume to victorp AT canonical DOT com.

• Lexington (MA) Hardware Certification Engineer
• Taipei Hardware Certification Engineer
• Montréal Hardware Certification Engineer

LoCo Teams on the Hall Of Fame

As you may know, during Maverick cycle we introduced statistics from our testers to be reflected in the Ubuntu Hall Of Fame. Well, now, and thanks to my good friend Daniel Holbach, we have, not only individual statistics, but also statistics by LoCo team.

This is how it looks on the Hall Of Fame. Nifty, isn’t it?

On First Experiences

Everybody agrees how important the Out-Of-Box experience is for a product. If the users’ first experience with any kind of product is frustrating it is very likely that they’ll return it and never look back.

On Operating Systems, usually, this first experience is turning on the computer and reply to some basic questions. For all the major OS like Windows or Mac OS, the software comes preinstalled in the computer. For many users, therefore, that’s the computer itself: something that you turn on and it starts working.

For Linux is quite different. Despite the efforts that some companies (including Canonical) are doing in order to be easier and easier to buy a computer with a Linux distribution preinstalled, nowadays, the first experience a user has with Linux is, most of the times, a CD and an installation process. Well, if you then want to have one of the best first Linux experiences ever, wait until Sunday and install the brand new Ubuntu 10.10. Its installation process is, ladies and gentlemen, pure joy:

I would like to congratulate the Ubiquity team for the fantastic work they do every six months. They make the first experience of those people who start with Linux better every time. It is great to have the opportunity to work with you, guys.

My experience upgrading UNE 10.04 to Maverick (and yours!)

As you might know, Ubuntu version for netbooks, UNE, is having a major re-engineering work for Maverick Meerkat,  soon to be Ubuntu 10.10. The old interface, which included packages like netbook-launcher or maximus, is going to be replaced by Unity. If you don’t know what Unity is, the nice people behing OMGubuntu published some days ago a nice review of the brand new UNE interface.

I will give you a clue: it does look very different from what you’re used to. That’s why we want to collect as many reports as possible of people upgrading from UNE 10.04 to 10.10 (with Unity).

My experience upgrading

OK, I don’t want to ask people to test something if I haven’t (and I have the means for it). I took my Dell Mini 9 (well, technically is Canonical’s, but, anyway) and I installed Ubuntu Netbook Edition 10.04.1 in Spanish. The installation went very well and fast.

After reboot, I updated my 10.04 installation and started the upgrade to Unity. Although the upgrade itself did not have any major problems it took almost six hours! Of course, I reported this as bug 646638. I talked with Michael Vogt on IRC and he will investigate.

Once the upgrade finished everything worked as expected: the language was still Spanish and there were no major crashes. Nevertheless, the global menu stayed there with “File Editar” even when no applications were running. I filed that as bug 646890 in Unity.

Apart from that, I found a couple of bugs in the Dash, but unrelated with the upgrade itself. These are bugs 646758 and 646756.

Your experiences upgrading

My system is not a real system. I use the Dell Mini 9 with SSD 8GB for testing purposes. I don’t use it on a daily basis. I reinstall almost every flavour of Ubuntu on it every milestone. My upgrade experience was from a nice, cleaned, UNE 10.04 to 10.10. No PPAs or third party software installed.

That’s why we need real feedback from the people that often use UNE 10.04 on their upgrades to 10.10. If you want to participate in our testing effort, just follow the next steps:

1. Create an account in our tracker
2. Upgrade to Maverick
3. Report back!

Use my testing report as an example. You see that you can add comments (like the system you used,or general impressions) and, of course, add bug numbers if you encounter any.

Thanks and happy testing!

So far, so good

It’s been more than two years since I started working at Canonical and, although I have been blogging about my daily job here, I have never talked about how this job is important to me.

I love testing software. Yes, I know it seems strange to love an activity that some other people find a bit tedious, but I do. I was a full time developer when I discovered that I liked testing the software. Testing software gets you the opportunity to see the product as a whole, but without losing the technical part of the job. So, when I got the opportunity to work at Canonical as a member of the Ubuntu QA team it was like a dream job. Not only I was going to be able to test free software during my daily job but, also, I was going to test ALL the free software that is included in Ubuntu.

When I was hired, one of my first missions was to create a way to to test the desktop in a repeatable way, easy to maintain. That’s how Mago project started, a couple of years ago. Working on this project has been great, as it has been working closely with LDTP upstream developers. I have contributed to LDTP through bug reports, patches and helping with the release of LDTP in Ubuntu. I always tried that the latest LDTP was successfully released and uploaded to Ubuntu.

I specially remember when we were trying to get the latest LDTP before Ubuntu 10.04 Feature Freeze. Nagappan, the main LDTP upstream developer and I worked closely on IRC to meet the deadline. Together, we fixes issued, verified them, got everything together and got it uploaded it to Ubuntu just in time. It was the perfect example of Open Source collaboration.

Mago, itself, is free software, released under the GPLv3. People inside and outside Canonical have contributed to it with bug reports, patches, new features and, of course, new tests to test the desktop applications, often GNOME applications.

But, apart from Mago and desktop testing automation, I am specially happy to be able to test all the open source bits that make Ubuntu: from the kernel to the desktop, from brand new topics as Multitouch, to all time classics as Firefox.

I work for Canonical, testing free software, trying to make it better for everybody. I need to remind myself everyday how privilege I am.

Multitouch testers in the Hall of Fame

Thanks to Daniel Holbach, the people testing uTouch and reporting back in the Multitouch Testing Tracker now appear in the Ubuntu Hall of Fame.

If you have been helping testing MT and you’re name does not appear there, is due to a bug in the ISO tracker, that prevents testers that haven’t set their Launchpad ID properly. This bug has been fixed, and it will be released in our next roll out of the testing tracker, but, in the mean while, there is a workaround that I explained in a previous post.

Please, if you are helping testing uTouch, check out how to appear in the Hall Of Fame.

GUADEC 2010 Videos

This year, due to family commitments, I was unable to attend GUADEC. Although the reason why I couldn’t attend made me very happy, I also was sad by the fact that I wasn’t going to be able to attend one my favourites FOSS conferences.

Happily, and thanks to Flumotion,  the videos are now available for download.

I have started downloading some of them and, of course, the first talk that I watched was the one given by my good friend, excellent hacker and accessibility advocate, Eitan Isaacson. In his talk, Eitan explains in a non technical way, why it is important to have accessibility in mind when designing any kind of products: from buildings to software. If you are a software designer or developer, I really recommend watching his talk. I am sure you will start thinking about accessibility when designing your next application.

Testing your multitouch device

Maverick is coming with multitouch & gestures support!

OK, right, this is not news, a lot of people have been already been talking about it, inside the Ubuntu community, and also outside the community. I cannot express how excited I am about multitouch support and the possibilities it opens (phones?, tablets?, the-next-great-small-device?). But, first, we need to test it!

So, maybe, you have a multitouch device. OK, maybe you don’t. Maybe you just have a single touch device (a touchpad, a tablet). OK, maybe you don’t. Maybe you just have a mouse. In all those cases we need your help. Obviously, our main interest is in getting feedback from people with multitouch devices, but, we also need to see if regressions were introduced in the process.

So, how can you help?

Setting Up Instructions

1. Install the utouch package.
2. You have to have an account in our tracking system.
   1. Go to http://multitouch.qa.ubuntu.com.
   2. Click on “Log In” and “Create New Account”
3. Once you’re done with the tracker, subscribe the Ubuntu Multitouch dev mailing list, where you will be able to contact the developers in case you face any problem.
4. If you want, send an email to the mailing list introducing yourself.
5. You’re all set!

Testing Instructions

We will be announcing new testing cycles in the mailing list. The tests will appear in the tracker and everybody is free to submit their results any time, while the testing cycle is opened.

Every testing cycle, you will see the tracker (http://multitouch.qa.ubuntu.com) reset. You need to click on a set of testcases to see the list:

The list of testcases appear, with a summary on how many results have been reported:

To read the instructions on how to perform the testing, and report your result, click on any of them. The testcase view will show a form to report your result and a link to the testcase wiki, to guide you through the process.

Please note that the link “Additional instructions are available” is actually the link to the testcase description. This is a wrong wording of the link and we will fix it in the next roll out of the tracker.

If the testcase passed, just mark it as passed.

Filing bugs

Utouch packages come with Apport hooks, that will make it easy to file bugs with the relevant information for the developers. To file a new bug please, open a terminal window and type:

$ ubuntu-bug utouch

After the relevant information has been collected, it will be sent to Launchpad, where you will be able to describe your problem. As easy as that! You have to love Apport!

You can also point to bugs that have been already reported.

Update: note that the images are cropped screenshots; to see the full text, please visit the http://multitouch.qa.ubuntu.com