This project is read-only.

Supporting processes

Sometimes it is more efficient to organize certain aspects/support centrally than per project. This involves supporting processes for the following subjects: Test policy

The test policy describes how an organization deals with the people, resources and methods involved in the test process in the various situations. Since testing is one of the tools to ensure quality, the test policy will have to be in line with the other policy measures and initiatives in relation to quality management. We recommend making sure that the test policy is in line with the strategic, tactical and operational policy of the organization.

Test organization

Permanent test organization A permanent test organization, contrary to project-based testing, does not elaborate a specific element of the test process on a per project basis, but across all projects. Reasons to create such an organization are, among other things, the improved leverage of scarce expertise, standardization of test products, limiting the test project start-up time, continuous improvement of the test process, consolidation of experiences, and prior insight into the test costs and lead time.

Two common types of test organization Two types of test organization are common in actual practice. These are:
  • The permanent test organization as a test expertise centre (TEC)
  • The permanent test organization as a test factory (TF).

The two differ, among other things, in the services they offer and their responsibilities in this respect. The TEC is mainly a supplying and advisory organization that takes on an “obligation of effort” at most when providing services. For instance, it may outsource testers or test managers to a project. Or offer advice on a test approach or test tool to be used. The activities are always executed under the responsibility of the project.

However, the TF accepts an “obligation to deliver results” for many of its services. The process can be compared with a factory with permanent personnel (testers), machinery (infrastructure), standardized work procedures, etc. Different clients (departments, projects, systems) can outsource their complete test assignments to this type of test organization. The client takes his assignment to the test organization, the assignment is scheduled in the form of work assignments for the employees, the infrastructure is configured the right way, the assignment is executed, and the client can pick up the product (reports, advice and possible defects in the tested objects) at the agreed time.

Both test organizations make a distinction based on demand frequency in the test services. The test service is approached from a different perspective for incidental requests (“set up a test environment”) than for structural requests (“test releases”). Service levels are agreed on when structural questions are involved.

Test environments

A fitting test environment is necessary for dynamic testing of a test object (running software). A test environment is a system of components, such as hardware and software, interfaces, environmental data, management tools and processes, in which a test is executed. The degree to which it can be established in how far the test object complies with the requirements determines whether a test environment is successful. The setup and composition of a test environment therefore depend on the objective of the test. However, a series of generic requirements with which a test environment must comply to guarantee reliable test execution can be formulated. In addition to being representative, manageable and flexible, it must also guarantee the continuity of test execution.


With Microsoft Lab Manager test environments are managed for specific projects, the specific environments are managed by using Hyper-V and virtual machine templates.

Processes for maintaining test environments To prevent problems in test environments processes need to be in place for managing the setup and maintenance of the environments. These management processes are:
  • Configuration management
  • Change management
  • Release management
  • Incident management
  • Problem management
  • Data management

See Infrastructure processes in this guidance and in the master test plan section.

Test tools

To execute the tests efficiently, tools in the form of test tools are necessary. A test tool is an automated instrument that provides support to one or more test activities, such as planning and control, test specification, and test execution.

Types of test tools Test tools provide support in the execution of certain activities in the various TMap phases. There are different types of test tools, which can be classified in four groups:
  • Tools for planning and controlling the test Work item management with in Team Foundation Server and test case management in Test and Lab Manager
Cannot resolve image macro, invalid image name or id.
Example report for planning work.
  • Tools for designing the test Several different information is needed for the design of the test. For example information about the test basis and the used/recommended test technique, this information is available from the one of the clients used to connect to the Team Foundation repository, from UML diagram which described the test basis, proposed functionality till work items and documents.
Managing test settings
  • Tools for executing the test Test and Lab Manager is the place for the execution of the test, this tool helps the execution and gives possibilities to collect rich bug reports and automation.
execute test.png
Execution of test cases with test runner, left side
  • Tools for debugging and analyzing the code. With the connection of the different roles by Team Foundation server the analyzing of the bug reports and the possibility to reproduce the bug, even with snap shots of the environment, gives the developer and tester a way to get connected and make the testing effort a seamless experience.
debug info.png
Debug information in bug report

Last edited Nov 11, 2009 at 5:30 AM by ClemensReijnen, version 6


No comments yet.