Don Brown has a nice piece on the history of Struts 2. Check it out!
The last two episodes haven’t been uploaded to iTunes – anyone know if FOX and Apple have suddenly decided to stop their partnership?
I am a big Apple fan, but I have to admit that it’s pretty lame that I can’t even find a place for help on this particular question inside of iTunes. Not the most customer-friendly site
Today I’m pleased to announced that the OpenQA jobs board is now live. As OpenQA, and the great projects that make up the community, have grown over the last year, a rich community of developers and users has sprouted up around it. Part of that growing process involves needs for commercial support, training, and technical expertise around the opensource tools at OpenQA.
That is where jobs.openqa.org comes in. It is a place where people looking for developers with deep knowledge of OpenQA can go to look for work, as well as a place where people can offer services around OpenQA-related technologies.
As OpenQA continues to grow, we hope to keep adding features like this to help strengthen the bond between opensource QA and commercial companies.
And of course, a small personal note about this for full disclosure: my company, Autoriginate, is one of the first companies offering support and training for Selenium, an OpenQA project. The creation of the Jobs Board certainly helps my company, but it can also be used by any other company offering similar services without exception. We believe this is required to take OpenQA as a community to the next level of growth.
As of a couple days ago, I added HTTPS support to Selenium RC. This is a major addition, as it has been pretty much the only large feature missing from Selenium products. The result is that you can now remotely drive web browsers on sites that use HTTP or HTTPS protocols. Just as Selenium Remote Control was, this code was originally created as part of our HostedQA product.
Using this feature
To get started with testing on HTTPS, you have to use the custom browser launcher for now (we’ll add support for it for the specific browser launchers as time goes on). The reason for this is that you need to import a Certificate Authority in to the main browser profile. Look in the advanced/security settings in Firefox/IE for this option.
You can find the CA at http://dangerous-certificate-authority.openqa.org/
Once you have the CA imported to the browser and have changed your tests to use the custom browser launcher, you can begin testing against HTTPS. Everything should just work.
How it works
Unlike other similar web testing tools, this solution doesn’t require you to prepare the web browser for each domain you want to test. Rather, you only need to prepare the browser once by importing the CA.
What happens behind the schenes is that as each HTTPS connection is opened to a unique server/host combination, a mini-instance of Jetty is spawned off and used to tunnel SSL connections to the server. However, that Jetty instance needs a keystore that is signed by a trusted CA and is associated with the domain in question.
That keystore could be generated through a series of keytool and openssl commands, but we didn’t want you to have to install these locally, since that can be a pain, especially for openssl. So instead, we created a web service at the dangerous-certificate-authority.openqa.org domain that generates the keystore for you.
The downside to this approach is that you must be online for HTTPS support to work. In the future we may offer a fallback that issues the keytool/openssl commands if the online service can’t be accessed.
Give it a shot
The latest SNAPSHOT builds at maven.openqa.org should have SSL support available. Give it a shot, or wait for Selenium RC 0.8.2 to come out.
Or, alternative, sign up for HostedQA and start using these features (plus a ton more) today.
A really cool feature we recently added to HostedQA was the ability to pre-load virtual machines in order to optimize automated testing. At first, I wasn’t sure if this was going to have any real user experience impact. But after having built it, I wish I’d done it sooner.
It turns out, if you have the RAM and you’re using VMs for automated testing, you should really think about pre-loading your VMs ahead of time. Then instead of waiting several minutes to kick off your automated tests, they can begin right away.
Now granted that if your test suite takes 10 hours, then a 3 minute gain isn’t that important. But that’s not the use case that this is designed to optimize. Instead, this feature, and the general concept of pre-loading VMs, is all based around the use case of creating new tests.
Why creating? Often when someone writes a complex test case that depends on the entire system being deployed and working properly, they don’t want to go too far without verifying they are on the right track. They do this by running the test. Now your 10 second test actually takes 10 seconds to run, instead of 3 minutes and 10 seconds. Suddenly, the environment is much more hospitable for test creators.