Ubuntu Global Jam is just a few short weeks away. I trust you've seen the posts announcing and asking you to plan your events. Maybe you are confused about what type of session to plan or how the event could go. I will echo my friend Daniel Holbach in saying just do it! Grab a buddy (even an online one!) and plan to jam together. If your confused about what to jam with, check out the testing page.
It's got everything you need to run a session, and the documentation has all been done for you. Folks can choose what they are interested in testing (packages, images, or hardware), or even do some hacking on testcases. No need to be a programmer, manual tests can be written by anyone! Participants don't need anything besides there laptop and an image of ubuntu on a cd or usb stick (assuming of course they aren't already running ubuntu raring :-) ).
If your curious about wanting to host a testing event, checkout the testing page on the global jam site. Feel free to get in touch with me as well if you wish to share your stories or ask questions. Let's jam, quality style!
Tuesday, February 19, 2013
Thursday, February 14, 2013
A thank you to some quality rockstars
The quality team has completed a series of classroom sessions held over the last two months. None of these would have been possible without the help from these wonderful instructors:
phillw, gema, noskcaj, smartboyhw, primes2h, letozaf, sergiomeneses
Thank you!
Thank you as well to pleia2, JoseeAntonioR and the other classroom team members who helped us schedule and run the sessions.
phillw, gema, noskcaj, smartboyhw, primes2h, letozaf, sergiomeneses
Thank you!
Thank you as well to pleia2, JoseeAntonioR and the other classroom team members who helped us schedule and run the sessions.
 |
You all rock!
Some quality resources
A couple posts ago, I mentioned the ubuntu quality team was looking for people to join the team and help out in the testing efforts we undertake. Thanks to those of you who've already answered the call and our now joining our testing ranks. We love sharing the joys of testing with others!
We're serious about wanting to make sure you are able to contribute and join the community as easily as possible. So for the last couple months, as a team we've been writing tutorials, giving classroom sessions, and hosting testing events. We really do want you as part of the team. Check out some of the resources available to you and consider becoming a part of the team!
Classroom Sessions
Video Tutorials
Written Walkthroughs
We're serious about wanting to make sure you are able to contribute and join the community as easily as possible. So for the last couple months, as a team we've been writing tutorials, giving classroom sessions, and hosting testing events. We really do want you as part of the team. Check out some of the resources available to you and consider becoming a part of the team!
Classroom Sessions
Video Tutorials
Written Walkthroughs
- Contributing Cadence Testing results
- Contributing Image Testing results
- Contributing Call for Testing results
- Setting up Launchpad
- Contributing Manual Tests
- Contributing Autopkg Tests
- Contributing Autopilot Tests
Friday, February 8, 2013
Cadence Weeks, Quality, and You!
Starting tomorrow February 9th, 2013 (heh, some of you reading this might already be in tomorrow), the quality community team will start testing for cadence week #6. During this week, we as a team try and help test specific packages looking for regressions, doing new feature or hardware testing, and making sure our images are in good shape. If your still confused, there's a nice wiki page that lays out what "cadence" means in a bit more detail.
So what does this mean for you, dear reader? Well, we as a team would like you to be involved in helping us test! Everyone has unique ways of interacting with software, and naturally no two computer setups are exactly the same between us. Now, I know what your thinking -- how can I help? I'm no tester, and I don't run development versions of ubuntu!
That's ok! You can still help test without needing to compromise your system. If you don't want to install the development version on your machine, you can use a virtual machine installation instead. If you are unable to run virtual machines, or are confused at the idea, you can still help test by simply running a live session and executing tests there. It's not too hard for you! Check out this walk-through for participating using only an image of the development version of ubuntu and your computer.
To help demonstrate how you can participate, I'll be hosting two live events this next week where I'll be on-hand running through the cadence week tests along with others from the quality team. There will even be a livestream, so if your a visual person (like me!), you can see for yourself how you might be able to contribute. Here's the dates you need to know:
Monday Feb 11th, 1800-1900 UTC in #ubuntu-quality. I'll also be streaming live my participation in executing the tests .
Thursday Feb 14th, 1400-1500 UTC in #ubuntu-quality. No stream, but we'll be hanging out answering questions, and working on submitting test results.
Please consider attending a session or watching the video of the stream afterwards. If you can download an image and boot your computer, you can help test. You want to be a part of ubuntu; let us help you contribute!
So what does this mean for you, dear reader? Well, we as a team would like you to be involved in helping us test! Everyone has unique ways of interacting with software, and naturally no two computer setups are exactly the same between us. Now, I know what your thinking -- how can I help? I'm no tester, and I don't run development versions of ubuntu!
That's ok! You can still help test without needing to compromise your system. If you don't want to install the development version on your machine, you can use a virtual machine installation instead. If you are unable to run virtual machines, or are confused at the idea, you can still help test by simply running a live session and executing tests there. It's not too hard for you! Check out this walk-through for participating using only an image of the development version of ubuntu and your computer.
To help demonstrate how you can participate, I'll be hosting two live events this next week where I'll be on-hand running through the cadence week tests along with others from the quality team. There will even be a livestream, so if your a visual person (like me!), you can see for yourself how you might be able to contribute. Here's the dates you need to know:
Monday Feb 11th, 1800-1900 UTC in #ubuntu-quality. I'll also be streaming live my participation in executing the tests .
Thursday Feb 14th, 1400-1500 UTC in #ubuntu-quality. No stream, but we'll be hanging out answering questions, and working on submitting test results.
Please consider attending a session or watching the video of the stream afterwards. If you can download an image and boot your computer, you can help test. You want to be a part of ubuntu; let us help you contribute!
Labels:
opportunity,
quality,
testing,
ubuntu
Tuesday, February 5, 2013
PSA: Ubuntu Quality wants you!
NOTICE: To whom it may concern, the ubuntu quality team is seeking those with a desire to help ubuntu to contribute to the quality and testing efforts. With a little time and a willingness to learn, you too can unlock the tester within you!
Interested? Please inquire below!
If that text didn't get you, I hope the picture did. Seriously though, if you are here reading this page, I want to offer you an opportunity to help out. We as a team have expanded our activities and projects this cycle and we want to extend an offer for you to come along and learn with us. We're exploring automated testing with autopilot and autopkg, manual testing of images, and the virtues of testing in a regular cadence.
But we can't do it alone, nor do we wish to! We'd love to hear from you. Please have a look at our getting involved page (but do excuse the theme dust!) and get in touch. I offered a challenge to this community in the past, and I was blown away by the emails that flooded my inbox. Send me an email, tell me your interests, and ask me how you can help. Let me help get you started. Flood my inbox again1. Let's make ubuntu better, together!
1. If anyone is counting, I believe the record is ~100 emails in one 24 hour period :-p
Labels:
opportunity,
quality,
ubuntu
Thursday, January 24, 2013
Introspecting with Autopilot
If you remember our post from last time, we had gone through writing our first testcase for firefox, converting a simple manual testcase to utilize autopilot instead. In this post I'd like to talk about how introspection can be used to perform some more complicated automated testcases.
First of all, let's briefly define what we mean by introspection. Specifically, we're talking about introspecting the dbus session for an application on our screen. Trust me, it sounds worse than it is. I'll let you do your own googling if you are curious to learn more. For the rest of us, let's just have a look visually at what we're talking about :-)
If you've got autopilot installed (check out the previous post; install autopilot ppa, sudo apt-get install python-autopilot), you should be able to launch the visualization tool.
autopilot vis
A window should launch, and allow you to select a connection. This allows you to select which application you wish to introspect. Go ahead and select 'Unity'. If the bareness of the tool scares you, remember it's a development aid, not your browser ;-)
Ok, under the Tree node, you should find a giant list of of nodes and properties for Unity. It may come as a surprise that your desktop is providing this much data about what's going on right now. For instance, have a look under PanelController->Indicators. There's entries for each indicator you are running, along with properties about each one. Ok, so what if your not running Unity? Or, for our purposes, you wish to write a test about an application on our desktop?
Never fear, we can use another feature of autopilot to help launch and introspect an application using the same tool. Go ahead and close the visualization window and enter the following.
autopilot launch gedit
autopilot vis
Notice now we have a new connection called 'Root'. Select it and you'll see the node tree for the gedit window you just launched. The amount of nodes spawned is a bit overwhelming, but you can now use this data to make assertions about what's going on when you interact with the application.
As a quick example, let's say I wanted to know the size of the current gedit window. I we look under 'GeditWindow->globalRect' we can see the current position, and infer the size of the window as well. We can also see things like the title, is_active, and other 'xwindow typish' properties.
In addition, I can find out what buttons are present on the gedit toolbar of the current gedit window. I we look under 'GeditWindow->GtkToolbar' we can see several GtkToolButton nodes. Each has a set of properties, including a name and label.
So, let's put it all together for a quick example.
bzr branch lp:ubuntu-autopilot-tests
Inside the resulting directory you'll notice a geditintrospection folder.
cd ubuntu_autopilot_tests
autopilot run geditintrospection
A gedit window should spawn and disappear -- and hopefully the one testcase should pass. Open up the file geditintrospection/test_geditintrospection.py. Inside you'll notice we're using some of the properties we found while introspecting to show off how we can utilize them to test gedit. Let's cover some of the new functions briefly. You can use the autopilot documentation for more information on what you see.
def select_single(self, type_name='*', **kwargs):
"""Get a single node from the introspection tree, with type equal to
*type_name* and (optionally) matching the keyword filters present in
*kwargs*.
def select_many(self, type_name='*', **kwargs):
"""Get a list of nodes from the introspection tree, with type equal to
*type_name* and (optionally) matching the keyword filters present in
*kwargs*.
These two functions allow us to get back the nodes that match our query. For example, you can see the first step of the testcase is to check for a New File button, which is on the gedit toolbar. After asserting it exists, we then click it. Load up gedit for yourself and use the vis tool to confirm. You'll find the node under GeditWindow->GtkBox->GtkToolbar->GtkToolButton. Each button is represented, in this case we pulled the one with label=_New, representing the new file button.
Later we actually interact with gedit by turning on overwrite mode. Normally we would be unable to verify if this indeed worked or not, but you'll notice we once again check for the GtkLabel change from INS to OVR. Again, you can see this under GeditWindow->GtkBox->GeditStatusbar->GtkLabel.
Finally, you'll notice some slight differences from our non-introspection testcase. We now use GtkIntrospectionTestMixin, and launch our application via the launch_test_application function, rather than using AutopilotTestCase. I've shown gtk based examples here, but introspection works with Qt too (using QtIntrospectionTestMixin), so don't be afraid to try it out on any application you are interested in.
You may also have noticed you branched from a project; ubuntu-autopilot-tests. I'm happy to announce this is the master repository for all the autopilot testcases we'll be writing as a community. Interested in helping contribute? Come join us and get involved! We're tracking work items, including proposed tests for you to work on. In addition, the tests themselves will soon be running on jenkins for everyone in the community to benefit.
Now introspection is still new, and we as a Quality Community team are excited about adopting and utilizing the tool. There might be some bugs and feature requests (wink, wink autopilot team!) to work out, but we are excited to build a repository of automated tests together.
NOTE: Due to an error during build, it appears the autopilot online documentation is absent or missing pieces. If this occurs, please use the local documentation installed on your machine as part of the autopilot package. You'll find a copy you can browse at /usr/share/doc/python-autopilot/html/index.html.
First of all, let's briefly define what we mean by introspection. Specifically, we're talking about introspecting the dbus session for an application on our screen. Trust me, it sounds worse than it is. I'll let you do your own googling if you are curious to learn more. For the rest of us, let's just have a look visually at what we're talking about :-)
If you've got autopilot installed (check out the previous post; install autopilot ppa, sudo apt-get install python-autopilot), you should be able to launch the visualization tool.
autopilot vis
A window should launch, and allow you to select a connection. This allows you to select which application you wish to introspect. Go ahead and select 'Unity'. If the bareness of the tool scares you, remember it's a development aid, not your browser ;-)
Ok, under the Tree node, you should find a giant list of of nodes and properties for Unity. It may come as a surprise that your desktop is providing this much data about what's going on right now. For instance, have a look under PanelController->Indicators. There's entries for each indicator you are running, along with properties about each one. Ok, so what if your not running Unity? Or, for our purposes, you wish to write a test about an application on our desktop?
Never fear, we can use another feature of autopilot to help launch and introspect an application using the same tool. Go ahead and close the visualization window and enter the following.
autopilot launch gedit
autopilot vis
Notice now we have a new connection called 'Root'. Select it and you'll see the node tree for the gedit window you just launched. The amount of nodes spawned is a bit overwhelming, but you can now use this data to make assertions about what's going on when you interact with the application.
As a quick example, let's say I wanted to know the size of the current gedit window. I we look under 'GeditWindow->globalRect' we can see the current position, and infer the size of the window as well. We can also see things like the title, is_active, and other 'xwindow typish' properties.
In addition, I can find out what buttons are present on the gedit toolbar of the current gedit window. I we look under 'GeditWindow->GtkToolbar' we can see several GtkToolButton nodes. Each has a set of properties, including a name and label.
So, let's put it all together for a quick example.
bzr branch lp:ubuntu-autopilot-tests
Inside the resulting directory you'll notice a geditintrospection folder.
cd ubuntu_autopilot_tests
autopilot run geditintrospection
A gedit window should spawn and disappear -- and hopefully the one testcase should pass. Open up the file geditintrospection/test_geditintrospection.py. Inside you'll notice we're using some of the properties we found while introspecting to show off how we can utilize them to test gedit. Let's cover some of the new functions briefly. You can use the autopilot documentation for more information on what you see.
def select_single(self, type_name='*', **kwargs):
"""Get a single node from the introspection tree, with type equal to
*type_name* and (optionally) matching the keyword filters present in
*kwargs*.
def select_many(self, type_name='*', **kwargs):
"""Get a list of nodes from the introspection tree, with type equal to
*type_name* and (optionally) matching the keyword filters present in
*kwargs*.
These two functions allow us to get back the nodes that match our query. For example, you can see the first step of the testcase is to check for a New File button, which is on the gedit toolbar. After asserting it exists, we then click it. Load up gedit for yourself and use the vis tool to confirm. You'll find the node under GeditWindow->GtkBox->GtkToolbar->GtkToolButton. Each button is represented, in this case we pulled the one with label=_New, representing the new file button.
Later we actually interact with gedit by turning on overwrite mode. Normally we would be unable to verify if this indeed worked or not, but you'll notice we once again check for the GtkLabel change from INS to OVR. Again, you can see this under GeditWindow->GtkBox->GeditStatusbar->GtkLabel.
Finally, you'll notice some slight differences from our non-introspection testcase. We now use GtkIntrospectionTestMixin, and launch our application via the launch_test_application function, rather than using AutopilotTestCase. I've shown gtk based examples here, but introspection works with Qt too (using QtIntrospectionTestMixin), so don't be afraid to try it out on any application you are interested in.
You may also have noticed you branched from a project; ubuntu-autopilot-tests. I'm happy to announce this is the master repository for all the autopilot testcases we'll be writing as a community. Interested in helping contribute? Come join us and get involved! We're tracking work items, including proposed tests for you to work on. In addition, the tests themselves will soon be running on jenkins for everyone in the community to benefit.
Now introspection is still new, and we as a Quality Community team are excited about adopting and utilizing the tool. There might be some bugs and feature requests (wink, wink autopilot team!) to work out, but we are excited to build a repository of automated tests together.
NOTE: Due to an error during build, it appears the autopilot online documentation is absent or missing pieces. If this occurs, please use the local documentation installed on your machine as part of the autopilot package. You'll find a copy you can browse at /usr/share/doc/python-autopilot/html/index.html.
Thursday, December 13, 2012
Jamming Thursday's!
Right now as I type we have two jams going on! Last week Jono posted about enhancing the ubuntu.com/community page. If your a part of the community, join in raising the banner for your specific focus area. The fun is happening now on #ubuntu-docs. For the full details, see Jono's post. For us quality folks, the pad is here: http://pad.ubuntu.com/communitywebsite-contribute-quality. Feel free to type and edit away!
In addition, as Daniel Holbach mentioned, there is a hackathon for automated testing. Come hang out with us on #ubuntu-quality, learn, ask and write some tests. Again, the full details can be found on Daniel's post.
Come join us!
In addition, as Daniel Holbach mentioned, there is a hackathon for automated testing. Come hang out with us on #ubuntu-quality, learn, ask and write some tests. Again, the full details can be found on Daniel's post.
Come join us!
Labels:
opportunity,
quality,
ubuntu
Subscribe to:
Posts (Atom)