As I wrote in various articles, organization is one of the 3 key requisites for successful automated testing, the other two being test design and automation architecture.
A question coming up quite commonly in larger corporations and organizations is whether to centralize the test automation, either at division or corporate level, or whether to decentralize: distribute over the various groups and projects.
The question centralize/decentralize is probably one of the most common in organizational science, and numerous publications can be found on the topic. In my own experience as management I found that there is not one “good” solution. Both centralizing and decentralizing have advantages and disadvantages. The arguments for centralization are leveraging of knowledge, tools and environments. A strong central group can acquire the tools and equipment, and allocate them efficiently to various projects. They can also specialize in the various technical and non-technical aspect of testing and test automation, building knowledge, like testing and automation techniques, and create common libraries and in-house tools for various needs.
A decentralized organization of testing brings it closer to the project and the subject matter. The project manager will generally have a better grip on the activities, quality, timelines and costs involved. And it will generally be easier to leverage subject matter expertise when the testing are organized locally, even in some cases have the subject matter experts involved in test creation. However, it is more challenging to reach the same professional level, in particular for the automation part, and automation efforts can go lost after a project has finished, either by ineffective automation strategies, or simply because nobody is left to take care of the developed test-ware.
For automated testing however, I feel there is a good hybrid solution, which I like to nick-name “concentralize”. It would typically look something like this:
In this solution a core group concerns with activities like:
- know how, methods and techniques
- technology, tools (both acquired and in-house)
- common libraries, actions and interface definitions
- environments, like server racks, virtual machines, etc
- retaining and preserving developed testware
The core group supports testing teams that are local, meaning inside or close to projects and departments. Within the test teams there is distinct:
- test development, that includes:
- high level test design, and test development planning
- design development of test modules
- project level automation, as much as possible distinct from the test development. It will typically entail activities like project level actions, interface handling, and scripting (see the Action Based Testing method for more details how this can work)
The testing teams in turn work with, and answer to, the various stakeholders, for input and assessment of developed test modules and their execution results.
In addition to the formal organization I recommend to have at least some form of informal “networking”. This could take the form of “special interest groups” for fields like test design and automation techniques. These groups periodically gather, on a voluntary basis, to discuss the profession. Typically at each meeting one of the members will present a topic, like a project experience, a research item, etc. It can also make sense to invite outside speakers. Each group has a chairperson and a secretary. The organization should stimulate with facilities, food, cost coverage of external speakers etc. This is a very cost-friendly way to build the testing and test automation profession, thus benefiting all projects involved.
