Henrik Skupin on March 25th, 2013

Eisige Temperaturen bei ca -4° und wunderbarer Sonnenschein. Besser kann man sich einen Lauf nicht wünschen. Mit insgesamt 1677 Läufern fand gestern der 23. Karstadt sport City-Lauf hier in Dresden statt. Für mich selbst ist es immer wieder ein besonderes Ereignis, mit so vielen anderen Läufern laufen zu können. Einen besseren Motivationsschub, das Training noch mehr zu intensivieren, kann es nicht geben. Die Zugkraft natürlich nicht zu vergessen.

Ich wusste jedoch bereits vorab, dass ich hier meine Bestzeit vom letzten Oktober nicht wiederholen oder verbessern kann. Die 40km Wandertour vom Donnerstag lag mir einfach noch zu schwer in den Beinen. Trotzdem wollte ich die bestmögliche Zeit herausholen. Ich startet mit einem wohl etwas zu schnellen Tempo. Das legte sich aber wieder schnell, denn gleich von Anfang an gab es auf einigen Streckenabschnitten einen ordentlichen Gegenwind, dem wir alle trotzen mussten. Mein Tempo reduzierte sich somit auf die üblichen 5:00 min/km und ich entschied dabei zu bleiben, um durchzukommen. Das lief die folgenden Kilometer ganz gut, bis mich ab dem 7. Kilometer heftige Seitenstechen, hervorgerufen durch eine dumme Bewegung, quälten. Wie nervig das ist, kennt sicherlich jeder von uns mehr oder minder. Leider hielten diese fast 3 Kilometer an und raubten mir gute Zeit. Dann waren sie auf einmal weg und ich konnte im letzten Kilometer noch einmal gut zulegen. Ich erreichte das Ziel auf dem 68. Platz meiner Altersklasse und dem 540. Platz der Männer. Ich bin zufrieden auch wenn es etwas oberhalb der 50 Minuten-Marke liegt.

Beim nächsten Lauf (Sportcheck Stadtlauf in Dresden) am 16. Juni 2013 habe ich mir nun den Halbmarathon als Ziel gesetzt. Dafür gilt es nun gut zu trainieren…

Henrik Skupin on March 23rd, 2013

Jetzt ist es fast Ende März und immer noch hat uns der Winter im Griff. Das passiert nicht so oft. Ich kann mich jedoch an ein Ostern vor einigen Jahren erinnern, als wir auch Eier im Schnee suchen mussten. Und genau da waren die Feiertage genauso zeitig wie dieses Jahr. Gibt es da einen Zusammenhang? Naja mag sein aber das soll jetzt nicht mein Thema werden.

Während meines Urlaubs diese Woche wollte ich eigentlich mindestens eine Wandertour absolvieren. Erhofft hatte ich Sonnenschein und etwas wärmere Temperaturen. Jedoch Pustekuchen. Es gibt Schnee, Schnee und noch mal Schnee, und das Thermometer zeigt auch Minusgrade. Ist das ein Grund alles abzublasen? Nein, nicht für mich. Also Pläne geschmiedet und rausgekommen ist dabei eine Tour von Bischofswerda nach Dresden. Laut Erfahrung, da ich diese Strecke ab und an mit dem Fahrrad fahre, sind es circa 40 Kilometer. Das wäre ja fast Marathon-Distanz. Schaffe ich das? Die letzte Wanderung liegt eine Weile zurück und in all der letzten Zeit bin ich auch nicht mehr als 10km gerannt. Schwere Entscheidung, aber ich will es probieren. Wer nicht wagt, der nicht gewinnt…

Gestartet bin ich letztendlich vorgestern gegen 8:20 Uhr in Bischofswerda. Mit angepeilten 6 km/h und ein paar kleinen Pausen sollte ich somit die Strecke in ca. 7.5h schaffen. Wird der Schnee hinderlich sein? Bestimmt, denn gerade in der Dresdner Heide erwarte ich nicht durchweg geräumte Wege. Und wie es sich herausstellte ist auch die Glätte nicht zu verachten. Gerade auf den ersten Kilometern über das freie Feld wurde ich dadurch behindert. Aber ab Rammenau wurde es besser.

Ganz im Eifer des Gefechts vergaß ich natürlich meine Garmin-Uhr zu überprüfen, ob denn die GPS-Satelliten gefunden wurden und die Strecke getrackt wird. Wie ich 3 Kilometer später feststellen musste, war das leider nicht so. :( Das erklärt die horizontale Linie im unteren Garmin-Track. Rechnet also bitte 3 Kilometer hinzu.

Eine der wohl langweiligsten Abschnitte der Wanderung war definitiv das Stück von Hauswalde über Bretnig und Großröhrsdorf. Mit dem Fahrrad ist es schon lang, aber zu Fuß fühlen sich diese 8 Kilometer durch diese zusammenhängenden Dörfer unendlich an. Hier muss ich falls es ein nächstes Mal gibt definitiv eine andere Route nehmen. Vorteil dieses Mal war aber auf jeden Fall der geräumte Fußweg, sodass ich gut voran kam.

Nach einer kurzen ersten Pause hinter Großröhrsdorf lag nun eine weitere Strecke über freies Feld vor mir. Radeberg ist von hier aus nicht mehr so weit weg, jedoch pfiff mir der eisige Wind genau ins Gesicht. Stetig merkte ich, wie ich trotz des Laufens immer weiter auskühlte. Dickere Handschuhe wären jetzt mehr als angebracht gewesen. Da aber keine verfügbar waren, kämpfte ich mich bis zu einem Imbiss in Radeberg. Dort musste ich die schon etwas steifen Finger erst erwärmen, bevor ich essen konnte. Das tat sehr gut, aber auch dass die Beine endlich eine Pause bekamen. Es waren zwar erst 24 Kilometer, aber die Oberschenkel meldeten sich bereits etwas. Zirka 16 Kilometer lagen noch vor mir.

Frisch gestärkt und aufgewärmt ging es kurze Zeit später weiter. Der Rest der Strecke sollte jetzt großteils durch die Dresdner Heide gehen. Dazu musste ich nur noch den richtigen Einstieg finden. Die Beschilderung war mager oder besser garnicht vorhanden. Mein Android Smartphone leistete mir in dem Moment wirklich gute Dienste und der C-Flügel war schnell gefunden. Der Weg wurde auch gleich deutlich schlechter begehbar. Glücklicherweise gab es jedoch eine Loipe inmitten des Weges, die bereits von anderen Fußgängern begangen wurde. Ich nahm mich ihr also gleich an. Nach etwa 3 Kilometern kam ich dann doch zu meiner Überraschung auf geräumte Waldwege. Grund waren die anhaltenden Forstarbeiten in dem Gebiet. Meine Oberschenkel fingen jetzt an, bei jedem Schritt zu schmerzen. Ich wusste nicht, ob ich all die restlichen Kilometer noch laufen kann. Ich nahm es mir jedoch stark vor. Kilometer für Kilometer zog sich hin und bei den vielen geraden Wegen spürt man auch kein wirkliches Vorankommen. Zähne zusammenbeißen, Henrik!

Als endlich irgendwann Spaziergänger auftauchten atmete ich auf. Jetzt kann es nicht mehr weit sein! Zumindest ging es bergab. Ein Zeichen, dass man ins Elbtal kommt. Doch es zog und zog sich. Die Beine schmerzten mittlerweile höllisch. Vor Allem das Stauchen in den Knien und eins-zwei leichte Durchsacker machten mir klar, dass ich mein Tempo drosseln und besser auf den Weg achten musste. Werde ich es noch schaffen? Schließlich sind es noch weitere 4.5km durch die Stadt.

Verkehrsgeräusche ließen mich endlich aufhorchen und gaben mir zusätzlich Kraft. Ein paar Minuten später stand ich auf der Stauffenberger Allee. Dichter Verkehr und Abgase machten sich breit. Eine doch krasse Veränderung zu all den letzten Stunden. Ich wäre gern wieder umgekehrt. :)

Ein Bus kam. Hm, die Nummer, die genau bis zu meinem Haus fährt. Fahre ich mit? Ich kann wirklich nicht mehr. NEIN! Keineswegs, du läufst weiter. Zähneknirschend überwandt ich den inneren Schweinehund und lief weiter. Vorbei an all den im Stau steckenden Autos. Wenn die Insassen wüssten, was ich schon hinter mir habe… Auf den restlichen 3km kamen weitere 3 Busse. Jedes Mal musste ich mehr dagegen ankämpfen, nicht schwach zu werden. Der innere Wille blieb stärker. Zum Glück, denn als ich endlich angekommen war, standen fast genau 40km auf meiner Uhr. Wow, wenn das nicht gut geschätzt war. Nur die benötigte Zeit war mit 7h länger als vorher gedacht. Das ist für mich kein Problem wenn man die Witterung und Bodenbeschaffenheit betrachtet.

Ich bin überaus glücklich, alles gelaufen zu sein und ein Gefühl bekommen zu haben, was eine Marathonstrecke ist. Unglaublich! Ich weiß nicht, ob ich das jemals laufen werden kann. Aber ein Ziel für die Zukunft hab ich jetzt vor Augen! Irgendwann werde ich die Kondition haben, einen Marathon laufen zu können und dann muss diese Strecke wieder daran glauben!

Jetzt heißt es erstmal zwei Tage pausieren, und am Sonntag geht es dann weiter mit dem ersten offiziellen 10km City-Lauf hier in Dresden.

Sport frei!

Henrik Skupin on March 21st, 2013

It feels like a decade since I have posted the last item on my blog. I will try to change this and post more stuff again. By doing that I decided to not only post in English but also write blog posts in my mother tongue which is German. Those will mostly be related to my hobbies like sports and photography. Any Mozilla related topic will still be written in English.

I hope you will like that change.

Henrik Skupin on September 5th, 2012

Woot!!1! MozCamp EU 2012 is approaching really fast. Only two days left until a couple of hundred supporters of Mozilla will meet in Warsaw to plan and work on the future of the open web. It’s exciting to be part of it and to see you all again!

My task together with Rob Wood – we both are from the Automation Development team – will be a hacking session about WebAPI test automation. WebAPI’s are a crucial part of the Firefox OS (B2G) initiative, Mozilla is putting a lot of work in to bring the open web even to mobile devices.

If you are interested in raising your skills in automation and want to help us to strengthen the quality of Firefox OS please join us on Saturday at 3:05pm in B2G room 1. We still have a couple of seats left. :) To be best prepared please read through our session details and try to setup your machine before you leave for MozCamp. We have setup links to get all necessary tools and the prepared Ubuntu VM. If you aren’t able to do that, don’t worry, we will have USB thumb drives available for you to grab all the data you will need.

As a sneak-peak we will also give you a link to our introduction slides so that you can change your mind if you are unsure about your attendance:

We are looking forward and can’t await to meet-up with you all. So see you @MozCamp on Saturday!

Update: We are planning to send out prizes for the best hand-crafted test(s) some days after MozCamp when we have reviewed all the written tests. So please be aware of code correctness, coverage, and style while implementing the tests.

Tags: , , , , , ,

Henrik Skupin on September 4th, 2012

It’s was clearly a wow! The way how our first “Ask an Expert” session went was promising. I haven’t thought that we would be able to fill a complete hour with discussions right away – but finally we ended up with additional 15 minutes to get the next steps set for Mike Kaply’s last question how to run automated tests for autoconf.

So what is that amazing on such a session? Given that in the past we as team were mostly working on Bugzilla to get a plan how to solve a specific problem, a live discussion is indeed a lot more helpful. Every attendee can directly participate, ask if there are unclear steps or if there are better ways to accomplish the wanted goal. The discussion is ongoing until you really met your expectation, or the time is up. That’s the difference to threaded conversations via email, where you should expect delays in the turnaround. You will lose valuable time which is even harder when you already have a strong timeline to finish up a feature.

The Automation Development team strongly believes that we all can work together to improve the Test Automation area at Mozilla even more. To achieve that goal we will continue in having live discussions each week and to help others in increasing their skills in automation.

And as a hint for all MozCamp attendees: If you are around keep an eye out for our “Make Sure Your Code Works” hacking session on Saturday at 3:05pm. I will post details about it before MozCamp but just as a heads-up so you can mark it in your calendar.

Tags: , , , ,

Henrik Skupin on August 29th, 2012

As you might have noticed in the last couple of months a group of people inside the Automation and Tools Team (A-Team) have been formed to help in making the automation expertise better at Mozilla. We are known as the Automation Development team and currently consists of Dave Hunt, Rob Wood, and myself. If you haven’t met us yet or even never heard our names, please check our team member section where we offer some more information about us and nice pictures. Better now? :)

At Mozilla we have dozen of test frameworks in use; like Mochitests, Selenium, Mozmill; which mostly dependents on the product under test. With this large matrix it’s sometimes not that easy to figure out when a test can be automated and which framework is best to use for. Even there can be overlaps because multiple frameworks would fit for a particular test. Confusion is pre-programmed.

So the Automation Development team wants to bring some light into the darkness by offering help for those questions. Therefore we will start to host office hour like sessions each week on Thursday at 12:00pm UTC. This will be done via our Vidyo infrastructure and you will only have to install the Vidyo desktop client as suggested when trying to enter the room the first time. For details and up-2-date information please visit our meeting page.

Given that we don’t exist that long yet and are 3 people only, we will start with the Mozmill, Selenium, and B2G testing frameworks. We will extend our coverage to other frameworks once we have the knowledge and man power, and know that sessions like those are helpful and accepted by others. Also please note that the current time has been chosen to start improving our relationship with community members in Europe first – here most of them are located for the above mentioned frameworks. In the future we are planning to have another session for US folks.

We are kinda excited about this opportunity and we would like to invite everyone who has interest to join and actively participate in the discussion.

Tags: , , ,

Given the importance of automation in QA the Automation Development team had a discussion lately how to improve tracking of QA covered automated testcases in Bugzilla. In the past we haven’t had a way to mark code in bugs for new features or regression fixes as being covered by Mozmill automation.

As we have agreed on it is important to scale our visibility and make it easier for both developers and QA to determine if a feature has automated tests, whether in the tree, in the Mozmill tests repository, or any other framework we would have to create in the future. A whiteboard entry didn’t make much sense for us, and to better align with the existent ‘in-testsuite’ flag, we decided on the ‘in-qa-testsuite‘ flag.

So if you think that a feature needs coverage by Mozmill, make sure to set this flag and assign myself (use “:whimboo” as name). I will then ensure the request will be handled appropriately and the test gets implemented.

Further documentation on automation frameworks and this flag will be available soon. I will blog about once it is ready.

Tags: , , ,

Henrik Skupin on June 11th, 2012

A crucial part of test automation is the fact that you can install and uninstall the application under test. While the installer part for Gecko based applications was already included in MozInstall we missed the uninstaller feature. I have added this feature now for the 1.0 release. On Windows it will first try to run the Firefox uninstaller in silent mode to remove any trace even from the registry. If files remain or if you are on another platform the specified folder will just be wiped out.

This work is part of our overall code rewrite of the Mozmill Automation scripts for Mozmill 2.0, whereby a lot of useful code will be merged with existing mozbase packages, or new packages like the mozdownload one will be created.

Keep in mind that this release changes the API of several functions. We are aware of that and hope that everyone of you will be able to adapt to it easily. It was necessary before more and more projects rely on this package. For any details please see the appropriate README file. Otherwise here some examples:

CLI:

$ cd /Volumes/mozilla/builds/
$ mozinstall firefox-13.0-en-US.dmg
/Volumes/mozilla/builds/FirefoxAurora.app/Contents/MacOS/firefox
$ mozuninstall firefox/

With those two commands the specified DMG image of Firefox 13 will be installed into a sub folder of the current working directory and removed right after. The installer will print the location of the actual binary to stdout.

API:

import mozinstall
path = mozinstall.install('firefox-13.0-en-US.exe)
print mozinstall.get_binary(path, 'firefox')
mozinstall.uninstall(path)

This code is the equivalent to the CLI example above. It installs Firefox into a sub folder of the current working directory, and returns the path. With the call to get_binary and by specifying the type of application, the actual binary will be returned. Replace ‘firefox’ with ‘thunderbird’ if you want to install a Thunderbird build. Finally the uninstaller expects the path Firefox has been installed into, and removes the application.

Tags: , , , ,

Henrik Skupin on May 31st, 2012

Some days ago we noticed that with the Mozmill 1.5.12 release we accidentally dropped the support for Firefox 3.6 or the Gecko 1.9.2 platform. It has been introduced with the fix for the global per compartment issue on bug 751424, especially with the addition of the ‘outer-window-destroyed’ observer notification listener.

Given the EOL of Firefox 3.6 and the Gecko 3.6 platform we do not intent to push another hotfix release for Mozmill 1.5 at this time. If you have to test applications which are based on Gecko 1.9.2 you should use Mozmill 1.5.11.

If you feel that this doesn’t solve your problem and we should re-add support for Firefox 3.6, please get in contact with us and together we can figure out what will be the best strategy for you.

Tags: , , ,

Henrik Skupin on May 10th, 2012

As you have probably already read we had some changes to our team. With the transition over into the Automation and Tools Engineering team we can now focus even more on test harnesses, the APIs, and the test creation process while educating others how to write automated tests. Given that new responsibility I want to announce a change in how we will manage Mozmill tests from now on. All that is done with the idea of having a faster pace in getting tests automated and fixed.

  1. We have to do reviews faster. Right now I see a lot of time wasted because the reviewer of tests is in a different timezone and cannot react immediately to requests. That means that patches which have been put up for review will not get reviewed before the evening in Europe. Revising the patch has to happen the next day. Normally we have at least two iterations on a patch so it takes about 2 or 3 days until the patch is ready for check-in. I would like to reduce this time to 1 or at maximum 2 days by promoting at least us (Dave Hunt and me) as reviewers. This applies to new and broken tests. Please split up review requests between us.
  2. We have to ensure that the test covers the appropriate manual test on Litmus. Not sure how close we are at this right now because I never did those reviews since they moved over to Anthony Hughes. If we were good in that area lets keep up that work, otherwise we have to improve. That said we will split up the process in a review and feedback section. While the reviewer takes care about the actual code implementation, the person for feedback checks the test
    for completeness. Only if both areas are fulfilled the test can be checked in. While Dave and myself will take care about reviews, Anthony is the one who knows the most of the current Firefox development and should act as the feedback person for now. Both can happen independently and should not be canceled if the other request gets denied.
  3. We have to fix broken tests and do not only skip them. In the past few months a couple of tests were failing and have been marked as skipped. It has happened a couple of times so that we now end-up with a lot of skipped tests. That doesn’t really help us and we have to get better. So before we create and work on new tests we have to make sure to really fix the broken tests. There should be used a round robin method between all of us (Automation Development and Desktop Automation) so that we will not have any skipped tests due to failures for each of the branches. I think that should be doable.
  4. We have to start the education. Learning from the experience of users while giving reviews will train Dave and me to see where the problems are located. That means that we can make sure to get more and better documentation up for those areas. If we wouldn’t work on reviews we would simply miss those parts. As result everyone who wants to contribute will benefit from and become a writer for automated tests in a shorter time.

I’m sure that with all those changes we can drastically improve the code quality and coverage of automated functional tests with Mozmill.