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.
He is a pioneer of the keyword approach for software testing organizations, and he assists clients in strategic implementation of the Action Based Testing™ method throughout their testing organizations. Hans is also the original architect of LogiGear’s TestArchitect™, the modular keyword-driven toolset for software test design, automation and management. Hans is an internationally recognized expert on test automation, test development and testing technology management. He is coauthor of Integrated Test Design and Automation (Addison Wesley, 2001), and speaks frequently at international testing conferences.
This is kind of a no-brained. I have always run my teams with a strong center of expertise which develops automation solutions (harness, or test runner and framework, or interaction layer) with testers on each team responsible for automation. The interaction is heavy and the teams develop each other. Success rates have been high, as well.
No indication how you wrote this post..it would almost certainly take me days. Well worth it though, I’d imagine. Have you considered selling advertising space on your blog?
im super sick of my battery on my android going down so fast, it annoys the crap out of me, see what happens, find a good site and BAM my battery is dead, so yeah, i luckily had enough battery to read this and post the comment haha, i have no life. yay me!
Thank you, I’ve recently been looking for info about this subject for ages and yours is the best I’ve discovered till now. But, what about the conclusion? Are you sure about the source?
It’s really a cool and useful piece of info. I’m glad that you shared this useful information with us. Please keep us up to date like this. Thanks for sharing.
I would like to say thank you for the soul you put in to creating this page. I’m hoping for the same high quality page from you again sometime soon…? In fact your informative writing skill has inspired me to create my very own info website yesterday.