![]() |
![]() | http://www.contentmanager.net/magazine/article_244_testing_in_content_management_projects.html |
Professional testing inspects the quality of implementation of a content management system and ensures that it corresponds to the agreed criteria. Early quality controls imply higher safety for the development team and above all for the customer, who receives a high-quality product by this.
Efficient testing means:
On the following pages the initiation of an efficient test process and the avoidance of frequent mistakes during the individual project stages is explained. An overview of different kinds of tests rounds this contribution off.
The project stages
Generally a CMS-project consists of the following stages:
Analogous to this are the test stages
The following diagram gives an overview of the project stages and the assigned test stages.

An overlapping or postponement of the individual stages and the individual teams is possible and differently required depending on the project. For example, the test specification can be carried out without any problems during the implementation stage until the final beginning of the tProfessional testing inspects the quality of implementation of a content management system and ensures that it corresponds to the agreed criteria. Early quality controls imply higher safety for the development team and above all for the customer, who receives a high-quality product by this. ests. And also the team members can change between the test team and the development team.
Preparation and project start
More and more often the experiences of testers are also in demand during the quotation stage if the definition of tests and approval criteria in contracts are to be examined. Also the recommendation of tools and their cost estimation should be considered when drawing up the quotation. As early as in the project planning sufficient time and budget should be scheduled for the tests. If tools are used for the implementation of tests, the licence fees, which are often quite high, and possible training costs have to be considered. Test teams also consist of highly qualified database specialists, developers, web designers or hardware architects, in order to be able to fulfil the varied requirements in a better way. Process specialists in the test team check the tests with regard to the underlying business processes. In case of multi-lingual websites attention has to be paid to the fact that enough members of the test team have the corresponding language knowledge. Furthermore respective national differences in the meaning of terms, in the use of the character set, in the colour and form language have to be taken into consideration at international sites. Therefore, the composition of the test team should be carried out particularly carefully. Finally as soon as in the run-up the implementation of the test environment is to be planned. This should be an image of the productive environment. Environment means in this context the applied hard- and software as well as possibly connected internal and external systems and data sources.
Fine specification
"A good planning is half the work!" This principle is especially valid in this stage of the project, because here the foundation for an efficient success control is built.
Parallel to the elaboration of the fine specification through the development team the test team defines a test strategy, which contains the following items:
The test strategy is an excellent aid for the preparation of the tests if it is drawn up exactly and conscientiously. Its elaboration is required by good quality management systems.
The following diagram shows a possible course of the individual test stages from the module tests to the approval and presents an overview of the individual kinds of tests in the individual test stages. In this, the kinds of tests have to be exactly adapted to the respective project in order to be able to set better priorities for the tests.

Apart from the above mentioned kinds of tests, which are typical for the CMS-project, of course, some other tests can be defined, which, for example, check the safety of the network. At the end of the fine specification the planning of the tests is more and more specified and replaced by the test plan after the end of this stage. This represents a refinement of the test strategy and is used to describe the procedure and processes in detail. The exact knowledge and inspection of the fine specification is a prerequisite for drawing up the test strategy. At the same time the test team begins to draw up the test cases.
A continuous and exact coordination with the employees of the customer, who are responsible for the approval of the CMS, is indispensable in this and of course also in the following project stages. The editors as final users of the system are also important contacts and have to be integratecm_net_magazin_0244_02.gifd at any case. This essentially contributes to an increased acceptance of the content management system and accelerates the process of approval.
Implementation
Due to the increasing time pressure in a growing number of projects an exact and continuous agreement between the members of the test team and the developers is indispensable during this stage.
The test team draws up the test cases on the basis of the documents produced in the fine specification. Thus, the test cases represent an examination of the work of the development team against the fine specification. In this, frequently the mistake is made to consider the work of the developer as basis for the tests. This leads to the fact that misinterpretations of the specification through individual developers are not recorded by the tests and the supplied system does not fulfil the agreed requirements in these aspects. This kind of examination places great demands on the test team and requires a conscientious analysis of the specification. The drawing up of the test procedures has to be supervised as exactly as possible to be able to start with the tests on time.
Each individual test procedure contains the following information:
An important component is the identification of the hard- and software technological resources, which are necessary for the respective test, as well as the required test data. The following questions have to be answered:
If these questions cannot be clarified sufficiently, this will lead to essential obstructions in the test procedure.
The drawn up test procedures have to lead to comprehensible results and should describe the test case in such a way that it can be carried out by each member of the test team. By this, in case of a bottleneck the test cases can be divided more easily. The developer who is responsible for the respective component has to be able to understand the error at any time in case of an error report on the basis of the individual test steps in order to discover and remove the reason for this.
During the implementation stage each developer carries out so-called module tests, in which completed reports are tested on code basis. The module tests are documented and thus represent the basis for the transfer of the individual components to the test team, which now begins itself with the implementation of the previously defined tests.
The application of a suitable software for the error reporting and the bug tracking is an important prerequisite for an efficient communication between the developers and the testers. Each error message is passed on by a member of the development team to the corresponding developer. This way, a central contact is available to the test team, so that the work of the test team is made easier at least in this aspect. In addition to this, the questions are channelled to the developer.
At this place some words with regard to the selection and utilization of tools.
Tools which support tests of hardware and software are offered in abundance. From open source tools which are free of charge to products which cost several thousands of Euro. A complete enumeration would go far beyond the scope of this contribution and is not possible.
![]()
At the selection of the suitable tool the following questions should be asked:
Here it always has to be considered that tools are no end in itself but only a means to an end!
The question still remains what is to be tested on which scale. It is the aim to identify those areas of implementation at which there is the highest probability of an error on the one hand as well as the highest priority of the respective area on the other hand.
The following diagram shows an example for a risk clustering:

The result of the evaluation, which has to be implemented individually for each product can be different - depending on the CMS which has to be implemented and the customer requirements. With this examination also those areas at which the test expenditure is the highest or most of the test cases are to be carried out can be identified in a better way. After having drawn up the test cases, having clarified the questions concerning the test data and having selected the right test tools, now the question for the place of test has to be asked. This predominantly depends on the required infrastructure.
Approval stage
The success of the project team during this stage largely depends on the work in the previous project stages. Only if the communication with the customer was sufficient, the requirements were specified and implemented in detail and also sufficiently tested, a critical customer will approve the product.
Here the test team can offer an essential support through its systematic preliminary work by identifying a large part of the criteria as soon as in the run-up and helping to avoid a high number of errors by means of sufficient tests.
An exact definition of the criteria which are essential for the approval is made before this process. The criteria of acceptance should be defined in detail as early as during the stage of quotation in order to not obstruct the process of approval unnecessarily. The criteria of acceptance are guidelines which have to be fulfilled by the system that is to be implemented. These can either be guidelines for the functionality of the system or guidelines for the hardware, but also guidelines for the documentation and training of the employees.
A possible further precise determination of the acceptance criteria during the fine specification stage can only be carried out through a permanent coordination between the individual areas in the project team and with the respective contacts of the customer. Drawing up a compliance matrix has proved to be helpful for the approval process in practice, which lists the individual approval criteria in detail and assigns priorities to them. The individual items can now be forgotten and thus the approval process can be objectified, if possible. "Forgetting" important criteria is not possible any more and prevents a "rude (and expensive!) awakening" for both partners after the termination of the project. With the successful completion of the approval stage the Content Management System can finally be inserted "live". Shortly after that it will be shown how favourable the tests were for a faultless, smooth course.
Result
Efficient tests are an important instrument for quality assurance in content management projects. The test stages run parallel to the individual project stages in order to facilitate a better control. A good planning in the fine specification stage as well as the careful selection of the members of the test team is indispensable in this. Perfectly planned tests from the beginning help to reduce the costs, to avoid a bad image and to make the user more satisfied.
Published: 03/2004
Author: Georg Amm
© 1999-2008 | |