Home Home > Tag > openQA automated testing
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Posts Tagged ‘openQA automated testing’

openQA is testing for you

January 20th, 2011 by

You might have read the announcement of the factory-tested repo (or not, because it did not go on planet.o.o). There have been many additions to the testing during the last eight weeks.

openQA.o.o is a machine running automated software tests all the time to decide if factory-tested can be updated. If you think, this was boring, you might find out that it is not, since every testrun generates a video of approx 4 minutes that can be conveniently viewed in firefox.

You can view those test results on the openQA page.

And those are the updates:

  • I have added testing of development repos, so that it is now possible to detect bugs before they even get into Factory (most of those tests have “devel” at the end of their name). In fact, this has already found two such bugs.
  • The test system’s hardware was upgraded with a sponsored SSD and the software adapted to allow running multiple tests in parallel (using make -j3)
  • I have updated the web-interface to use the nice Bento theme
  • And I found yet another cool use-case for automated testing: it allows to bisect bugs. I did a binary search in old results for a live-installer bug which made it really easy to find the causing commit. However, seeing how long such a bug went unnoticed, made me think, that it would be nice if more people would check the results for anomalies, since not all of those can easily be auto-detected. As this just needs a firefox and little time, this is pretty easy to do. Much easier than to actually setup a test-system in any case.
  • An IRC notification bot was added, keeping #opensuse-openqa updated with new test results
  • Then, I am looking for additional automatic test-scripts, that also work standalone on an openSUSE install. It is especially important to test high-impact things. Things that break often or block many users if they break. And it would be nice to have a small result range such as OK|fail|unknown or it should at least be mappable to such.
  • Jürgen Weigert has packaged sikuli, so it is easy to create GUI tests with it, that could then be included in the test-suite.

Then there are still some things on the ToDo list…

  • Hermes integration to get email alerts and RDF feeds for newsreaders
  • Have more test variants auto-scheduled (-live and -dup)
  • Find a way to have Add-On-Repos with custom priority (otherwise Factory packages might be used, as happened for kernel-default-2.6.37-rc7) – using linuxrc’s driverupdate feature could be one way.

your input is highly appreciated