Skip navigation.

Log in | Sign up

REST ASSURED

Quality rants by Opera QA

Posts tagged with "testing"

Testing My Opera

, , , ...

Here at Opera, we make more things than the desktop browser. Apart from the browser for all the other platforms and Opera Mini, we make some internal systems, some server-side support for the browser, and some public sites. Probably the most well known, non-browser Opera product is My Opera (yes, this very site!). Being such an important product, it's in the hands of very smart people (and me), and it goes through extensive automated testing to catch as many problems as possible, as early as possible.

The automated testing for My Opera is based on three things:

  1. A functional test suite.
  2. A unit test suite.
  3. Our beloved continuous integration server, that executes the test suite at every commit and shows the results to the whole team.


The functional test suite is built with Test::WWW::Mechanize and uses special My Opera testing installations, each one connected to its own private database. That way, we can recreate the database before each test and ensure a stable and reliable environment for the test execution. This is currently the biggest and most mature one, and it has helped a lot in avoiding regressions when refactoring code and fixing bugs.

The unit test suite is a standard Perl test suite that covers the most important modules of My Opera. Again, we use private databases for the tests that do need them, so we ensure a reliable testing environment.

Last, but not least, we have everything hooked up in continuous integration so we have testrun information for every commit. When any test suite catches errors, we are automatically notified, and we can track which changes produced which errors.

All in all, we are quite happy with the automated tests for My Opera, as they give us freedom to work with the code without fear of breaking things without noticing. There is, of course a lot of room for improvement, and we are always tweaking and enhancing it.

Welcome to Rest Assured

, , , ...

Welcome to "Rest Assured", quality rants by Opera's Quality Assurance department.

My name is Snorre M. Grimsby, and I am the head of Opera's QA department. We would like to tell the world more about what testers and QA engineers at Opera do, and also discuss more general quality assurance issues. Therefore, posts on this blog will relate less to specific Opera products and technologies (and/or the testing of them). In other words, this is not the place to report bugs.

So, who are we?

Today, we have people in seven of Opera's offices, organized in five sub-departments to align with our development lifecycle. We are responsible for testing and assuring the quality of all Opera deliveries and technologies, from Core versions to end-user and business products.

What is testing?

Internally, we use this definition of testing:

Testing
Activities, including development of test-supporting tools and systems, that directly or indirectly examine, observe, or evaluate (without access to the source code) the state (for example quality, usability, operability, compatibility, accessibility) of features and functions in the Opera browser.

Activities that fall under the definition would be

  • Planning and managing testing of products
  • Writing, reviewing, and running test suites
  • Web compatibility and interoperability verification
  • Tracking, analysis, and assignment of all reported defects

We also develop, deploy, maintain, and administrate testing infrastructures, tools, and systems.

Beyond testing

We often say that [t]he object of good testing is to find as many bugs as possible, and that [t]he object of good quality assurance is to find as few bugs as possible. What we mean by that, of course, is that testing is about detection and that quality assurance is about prevention. Work on process improvements (SPI), therefore, also falls under our QA department.

But our responsibilities actually go beyond testing and quality assurance:

  • Reading, reviewing, and writing specifications
  • Setting up non-testing infrastructures and systems (e.g. guidelines)
  • Internal, customer, and public technical and non-technical documentation
  • End-user and customer support and community interaction
  • Product localization

If you have an interest in Web technologies, software testing, and/or quality assurance, we hope that you will find this a blog worth subscribing to.