|
http://ubuntutesting.wordpress.com/page/2/ As announced on their testing blog, and on the Google Maps developers blog, the Google Maps API team have open sourced their Selenium test suite. Why should we care at Ubuntu? Openness is always good news but I think having these tests publicly available is great news for the testing community. It is not that common that software companies open their test suites. Even more, there are many projects that being FOSS, have their tests closed. It is just a matter of culture, people keep thinking that testing should be something that a developer or a tester do behind the scene. We do need to change our minds, testing is just another step in the software development process and should be as open as software code. Also, we could learn a lot from these tests about how to structure a Selenium suite and we could use this knowledge to test our own web applications, like Launchpad, or the ISO testing tracker. Yesterday, in the Asia & Oceania regional board meeting I was approved as an Ubuntu Member. I would like to thank the Asia & Oceania and EMEA boards, for approving my candidature. Let me introduce myself a
bit. My name is Ara Pulido and I live in Málaga (Spain). I am part of
the Ubuntu QA team,
where my main focus is automated testing for the desktop. My blog talks
about software testing in general, Ubuntu testing in particular. You
can read the old posts, if you’re interested in these topics We are pleased to announce the first Ubuntu Testing Day, that will be next Monday, September 22nd. The Ubuntu Testing day is a special day where the Ubuntu Community comes together with a shared goal of testing an specific set of ISO images (Alpha, Beta, RC, Gold or Point releases). Taking the idea from the Ubuntu Bug Day, we want to apply the same concepts to ISO testing. Who can join the
Testing Day? Where to join the
Testing Day? Normal testing activity takes place in #ubuntu-testing at other times also. Which release we will
be testing? Update: It is there!
Here’s the email from the Ubuntu Installer:
Thanks to the LDTP team
and Kartik Mistry for making this possible.
Congratulations Nagappan
and the rest of the LDTP team! Next week we will be having an Ubuntu Developer Week. Ubuntu Developer Week is a series of online workshops where you can:
Though the schedule is not yet closed, you can still check it out at https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep As you can see I will be giving a session about automated testing for Ubuntu. Please, feel free to drop by and learn how to run the already existing tests as well as creating your own tests easily. In the previous post we talked about the difficulties when trying to recognize widgets through its accessibility information. If normally is a pain, it can certainly be worse when dealing with labels. Labels text does not only change their text when the language is changed, but they can change their text in different states of the application work flow. Let’s imagine that an application uses the same label to show error messages to the user (very common scenario). If the label does not have correctly set its ‘name’ in the accessibility information (very very common scenario), then the name of the label will be the current text of the label, and our test script won’t be able to gather errors or any other information from these labels. If the text of the label has some kind of structure, though, some of this information can be retrieved, using regular expressions to search for common patterns, for example, if error messages always start with the text ‘Error:’ we could get the rest of the text of the label to obtain the error message. For Ubuntu we are using some of these “pattern” labels to get some useful information from the applications. In the update-manager a label with the pattern “You can install nn is the number of available updates. The method number_udpates, part of the Ubuntu testing library, scans the available labels for that pattern and returns the number of available updates. Anyone wanting to write a test for update-manager can use this and any other available method in his or her test script. updates.”, is shown every time at least one update is available, where One of the main issues when getting information from the AT-SPI layer is that most of the accessibility information is missing. Names are almost never set, therefore, objects take the name of the current text. This is something generally painful, as tests will need to be localized for each language. Let’s imagine that we have a form called “Update Manager”, then the object would be frmUpdatemanager. If we change the target system language, let’s say, to Spanish, then the window will be named “Gestor de Actualizaciones”, and the accessibility information in this case would be frmGestordeactualizaciones. As I wrote in my previous post, we are trying to separate as much as possible this kind of information from the scripts code. Apart from having classes for the common activities with applications, the text in windows, buttons, etc. is maintained in a separate file, ubuntu_constants.py that will be, eventually, the only file to be changed when porting the tests to a different language. When scripting desktop tests is a common practice to rely too much on script recorders, that will script automatically your test, based on mouse and keyboard activity. The main problem with the resulting scripts is that they are too coupled with the desktop interface and, therefore, difficult to maintain. One of the main objectives that we are persuading when creating a testing framework for Ubuntu desktop is to avoid scripts to know anything about the objects behind them. Definitively, these objects will still require to be maintained, but the logic of the scripts will remain the same. One example. Let’s imagine that we had a regression test suite for Gedit that will edit, modify, open and save several files. Many. About a hundred. If any of the Gedit features changes its UI, only the Gedit class will be modified. All the scripts will still be valid. Decoupling scripts and test objects will also keep the door opened to Model-based Testing. To create our automated tests for the Desktop at Ubuntu we are using LDTP (Linux Desktop Testing Project), a framework that relies on the Accesibility layer to manipulate the desktop objects. LDTP comes with a python wrapper to be able to create tests in python. One of the tests that we wrote was Gedit Chains that tries to open Gedit, writes a string chain, saves it, and compares the resulting file with an already saved oracle file. We have two test cases for this test. The first one wrote an ASCII string, “This is a very basic string”, and it was successfully run against Intrepid Alpha3. The second one tried to write a string with Japanese characters, to test UTF-8 with Gedit. This test failed. The problem root was that python-ldtp communicates with LDTP server with XML, and the necessary encoding was not being done properly. Therefore, each time I tried to run this test I got the following error:
I posted the error on the LDTP mailing list and 24 hours later Nagappan, one of the main LDTP developers, checked the patch into their GIT repository (Thanks!!). I tried again my script with the LDTP GIT version and this time it run smoothly. I think it is a very important fix, as UTF-8 characters are likely to give errors in text editors, terminals or browsers. I have created PPA packages for Intrepid that include this fix so that anyone can try this test. Intrepid packages are available at https://launchpad.net/~apulido/+archive. |
