Today everything went smoothly:

Teamwork rocks!

Yes, if you updated your Karmic repositories lately, you can install Mago just typing “sudo apt-get install mago”. What does that mean? Not much, for the moment.

We have packaged the library and harness, but not the tests. Once you have installed Mago in your machine, you can start writing tests using the library, you will be able to run the tests with the Mago harness and get nice reports in XML and HTML. You won’t have the already written tests, though. Tests change a lot, so it does not make sense to keep them in the repositories, which are quite static. PPAs are a much better place for tests, which I am planning to maintain.

I still have a lot of work to be done regarding this: I have to set up the PPA for the tests and update the documentation at the Mago site, to start. Why did I push Mago into Karmic, then? There are two main reason: Feature Freeze and Holidays. Ubuntu development schedule has an important date called Feature Freeze, after which no new packages are generally accepted and only bug fixes are supposed to get uploaded. Karmic FF is happening August 27th, but I will be on holidays since August 14th, so it was now or never (or Karmic+1).

The main advantage of having Mago in the repositories is that, if a project wants to use it as part of the testing of their daily builds, they can set Mago as a Build-Depends of the project and forget about whether Mago is installed or not in the build machine. And, don’t worry, I will be updating the documentation and setting up the tests PPAs after my holidays, but, in the mean time, Mago is there, ready before Feature Freeze. Happy testing!

Earlier this month, Michael Bolton (not the singer, but the software tester), wrote about testability of software. Basically he answers the question of how to increase software testability and if it involves something more than making it easier to automate.

Testability is anything that makes the program faster or easier to test on some level.

Indeed it involves a lot more.

His explanation is very concise and it gives useful tips to increase testability. If you are writing any kind of software, I recommend you reading his post to improve its testability.

Why should we care about testability? I guess it is hard to think about every non-functional risk when writing an application. Not only you have to make it work, but now you also have to think about performance, accessibility, usability, and now, if all that was not enough, testability.

Making a software easier to test not only makes testers’ jobs easier but also it gives more time to developers to fix the issues before the release, as bugs can be found earlier in the cycle.
Not long ago I filed a couple of bugs in Notify OSD that, if fixed, they will make Ubuntu’s notification system easier to test. They do not imply making the application easier to automate, they are just a couple of bugs about improving its logging system. Making an application logging system more intelligent is just an example of an easy way to improve its testability.

I’ve added the tag “testability” to these two bugs and will start to do the same with the bugs I find that makes testing harder. If you are a software tester or a developer that cares about testing, do the same. Usability, accessibility, testability, performance; they all share a common objective: making software better.

Jono asked about thoughts on why women are such a minority in open source communities. I already talked with him and Matt about the topic during GCDS, but I would like to write down my thoughts and experience.

From my point of view, there isn’t just one reason. I will talk about the reasons why I don’t feel completely comfortable in the FLOSS communities. I cannot generalize, extrapolate and conclude that those are the reasons why women are a minority, but I can offer my experience as an example.

ONE MERIT – Meritocracy is one of the greatest things (and one of that I love most) about free software communities. At the beginning you don’t need to be someone, or know someone or know someone who knows someone. You just do and get credit for it. Theoretically no matter who you are, your gender, sex orientation, race or origin. Problem is that normally only one merit is taken into account: hacking hours. “Show me the code!” is the motto here. Nobody says: “Show me your strategic plan!”, “Show me your documentation!”, “Show me your funding efforts!”. Although it is now changing a bit (a great example would be the Ubuntu Hall of Fame, which gives credit not only to developers, but also to translators, PR people, and the alike), the motto is still “Show me the code!”. All-night-long hacking? 95% of the times that person would be a man.

SEXISM – Maybe is not that relevant, at least for me, because there is sexism everywhere. We have to fight against it, but we have to continue with our lives in the mean time. But it does exist. Oh, really it does. Let’s transcript a conversation I had during GCDS as an example (my thoughts while it was happening, in brackets):

Guy: Mmmm, it only took me two days to realize that chicks from Barcelona are way hotter than those from Gran Canaria
Me: Yes? Only two days to arrive to that conclusion? That’s fast! (What???? Why is he telling me this?? Talk to me about weather, please)
Guy: Yes. I pay a lot of attention.
[...]
Guy: So, what did you study at university?
Me: Computer Science
Guy: What??????? Since when *chicks* are starting to study Computer Science?
Me:(Mmm, people like you make me think that I made the wrong decision)

LACK OF AFTER-WORK BEER SPIRIT – When I worked for software companies outside the free software world I used to love Friday after work beer. We’d go to a pub, have a couple of beers and talk about anything but work. OK, sometimes we talked about work, but it was more in the sense of complaining about the bosses and things like that. Normally conversations were about love, life, future, past, present, etc. When I go to conferences now, after all day hacking, listening to new technologies, plan new projects and/or collaborations, which is great, what I need at 6pm is a break. Sometimes I feel that the only way to have that break is just going for a walk on my own. Going to a pub for a beer and keep listening to conversations about CouchDB, GNOME Shell, Clutter, OpenGL, pro Mono rants, against Mono rants, etc. does not seem like a break for me.

OH, IT’S A GEEK WORLD – It is a pity that free software communities are so geek. Not in the sense that I don’t like geeks, I would consider myself a geek, but in the sense that if you’re not, it is difficult to enter (or if you enter, to survive). It is a pity because free software is great. It is great because of the technology, it is great because is open, it is great in the sense of libre. People should be willing to know more about it, but I understand the entry-level barrier. I consider myself a geek, and I find difficult to survive because I am not *that* geek. For a non-geek it has to be even harder. And, let’s face it, men are geekier than women.

I guess these are the main reasons why I don’t feel 100% happy about being in an open source community. And that’s a pity, because I love the spirit and theory about software libre. I should feel like I was in the best job ever.

Today I gave my talk at Gran Canaria Desktop Summit about Mago. Although it was a testing talk, I think people enjoyed it and I hope to get more contributions from upstream.

I will send the slides to the GUADEC committee, and I guess they will be publish them soon. In the mean time, you can get the slides from the presentations launchpad project that Ted just set up.

Everybody is blogging about it, so do I.

Tomorrow I will be travelling to Gran Canaria to attend the Desktop Summit.
If you're interested in testing, I will be presenting Mago on Wednesday.

I hope to see you there and meet a lot of new people!

A year ago I started a project, as part of my work at Canonical QA team, that aimed to have a consistent way to add automated desktop tests to Ubuntu. That project was originally called Ubuntu Desktop Testing.

The project grew and as the GNOME testing community started to be interested in it, we created a mailing list and an IRC channel (#gnome-testing at irc.gnome.org) for the GNOME folks.

The problem about having two projects (one for Ubuntu and one for GNOME) is that it was very difficult to maintain both synchronized. Also, having the project named as another project (Ubuntu Desktop Testing, GNOME Desktop Testing…) confuses people, as they think that it is exclusive for Ubuntu and/or GNOME, which is not true (as soon as AT-SPI gets migrated to D-BUS KDE will also benefit from this effort, i.e.).

So, today, I am pleased to announce “Mago“, a desktop testing initiative that will replace the other two and that can be used to create desktop tests for any AT-SPI enabled linux desktop.

Mago is hosted in Launchpad at https://launchpad.net/mago and you can start adding test cases by just creating a branch of your own and propose merges as you go by.

The trunk branch is owned by a Launchpad team, mago-contributors, that it is a moderated team. Once you have contributed through merge proposals, you can apply to be part of the team and will be able to push to trunk and review some other members contributions. Join us!

Happy testing!
Ara.

P.S. For those interested, “mago” stands for “magician” in Spanish.

As announced in the LDTP mailing list, LDTP 1.5 is out.

This new release contains some nifty new features:

  • Log all failures and take screenshot on each failure
  • Create default log file in /tmp/ldtp-$USER
  • Screenshot using pygtk, instead of ImageMagick import, when possible
  • Added new api – appundertest

We are specially happy for the screenshot feature, for which we had specially pushed for, to have better reporting options. You can see an example of a report at the QA site.

Also, if you’re running Jaunty, you can start using LDTP 1.5 new features with ubuntu-desktop-testing, using the reporting_ldtp_1.5 branch (soon to be merge into trunk), as LDTP 1.5. is already in the archive :-)

Thanks Nagappan and the rest of the LDTP dev team for the best LDTP release to date!

Next Thursday Januanry 15th the Bugsquad team is organizing their first Ubuntu Bug Day of the year.

The chosen package this time is network-manager. Please, read the details at the event wiki page.

Go ahead! Triaging bugs is a great way to contribute in making Ubuntu better!

At the QA team we are going to organize Testing Days to cover new features for Jaunty.
It has happened before that a new feature well documented with its blueprint and its spec never gets tested and it happens to have a major bug that it is only found very late in the cycle.

We are trying to minimize these cases organizing special Testing Days to cover such features. So, if you’re developing a new feature and want it to be tested in a Testing Day, please, add the feature to the list in the wiki, so we can schedule it.

We will soon announce the next Testing Day and instructions on how to participate in helping to make Ubuntu better.