Posted on

Painful Selenium Testing – Part 2 – Confusions

Firstly, here is the structure we are using right now:

Selenium IDE + Selenium RC HTML + Jenkins + Selenium Reporter + Groovy Script + Twilio Alert

This is how it works now:

  1. Most long-term projects have automated HTML UI tests (e.g. open URL, click, type in, submit, etc..) run every night

  2. It will check sites, as well as server healthiness.

  3. If it's success, a blue light will appear in Jenkins.

  4. If it's failed, a red line will appear.

  5. If it's a critical suite (e.g. site failed to be opened), and it continuously failed for 5 attempts, the system will send SMS to alert the developer.

Read more Painful Selenium Testing – Part 2 – Confusions

Posted on

Painful Selenium Testing – Part 1 – Intro

I restarted this blog to mark down the painful days working with selenium.

In the world of agile, scrum and test driven development, everyone agrees that automated testing is important. In fact, it is one of the few required items for practices, they are even not optional.

However, when we step into this field a few years ago, we are surprised to find that there are so few companies actually did the genuine automated tests, for both web and mobile apps. Some companies did the unit tests, but very few companies worked out the legitimate functional tests (or UI tests) with automation.

We attempt to tackle the website automated testing with selenium, which is one of the few popular tools in this area. Yet it is still so painful.

Read more Painful Selenium Testing – Part 1 – Intro