Skip navigation.

exploreopera

| Help

Sign up | Help

REST ASSURED

Quality rants by Opera QA

avatar

Continuous Integration: Team Testing

By zoso. Friday, 18. July 2008, 12:10:41

, , , ...

As you know, Continuous Integration is a set of simple practices that reduces software integration time and problems. It also improves general software quality with little overhead. Just having a testrun per every commit is quite handy for two reasons: early regression finding and easier debugging.

One of the most important virtues of CI is giving the tests a "social dimension". Martin Fowler's "Everyone can see what's happening" is actually one of the most powerful, yet subtle virtues of Continuous Integration. Letting everyone know about the status of the tests is not about assigning blame when something fails, it's about making the tests part of the development process. We wholeheartedly agree with the vision of automated tests that are incorporated upstream into the development process and run on a continuous basis.

What happens when you make the tests part of the process? Several interesting things:

  • The team focuses on avoiding and fixing regressions due to clear and quick feedback - less "getting out of the door quickly" with more stability.
  • The team has confidence in the code - more refactoring or rewriting of suboptimal modules.
  • Certain processes like deployment are streamlined - easier, clearer and more reliable.


We feel that these benefits make Continuous Integration a natural extension to automated tests for development teams, a bit like "the version control system of tests". Here at Opera we are using Continuous Integration for selected server-side projects, notably the Opera Link server and My Opera. It has had a huge and positive impact on both of these projects, providing a crucial role when refactoring and improving code.

If you are not using Continuous Integration in your project yet, you should start now!

6 Comments

avatar

Welcome to Rest Assured

By Snorre. Wednesday, 4. June 2008, 13:29:20

, , , ...

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.

3 Comments