| |||
| | | |
| |
Testing in content management projects
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.  Illustration 1 - Project stages and 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.  Illustration 2 - Kinds of tests in the individual test stages
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.
03/2004, Georg Amm
| | | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| © 1999-2008 FEiG & PARTNER | Disclaimer | | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |  |  | |  | |  | |  | |  | |  | |  | |  | |   |
|
| ||
| know how news events | |
| ||
| ||
| ||
| ||
|
