The proposed novel methodology assumes that a service provider has an SCE in his environment to enable the service developers to rapidly create new value-added services and bring them to market. Figure 4.1 presents an example SCE published by (Eichelmann
et al., 2010) and (Lehmann et al., 2009). Permission to reproduce Figure 4.1 has been
granted by the copyright owners of the referenced publication.
Figure 4.1: TeamCom service development (adapted from (Eichelmann et al., 2010))
First, the service customer writes a non-technical, informal and natural language-based description of the service. The description should contain the idea of what the service should deliver. Based on this information, the service developer creates a formal service
Informal
Requirements Build BPEL process Service Developer
Generate
service code Deploy service
Application Server
Service Creation Environment
4.2 Overall Methodology for Testing Value-Added Services
description (here a Business Process Execution Language (BPEL) process) (OASIS, 2007) which is used as basis to generate the service implementation code. Finally, the service is deployed on an Application Server.
In order to integrate functional testing on top of the described service development methodology, a separate test development path is proposed (see Figure 4.2).
Figure 4.2: Methodology with both service and test development
The service development path in this approach was abstracted. Here, the methodology assumes that any given SCE applied by a service developer can be integrated in the process if it deploys the service on the Application Server at the end. The new test development path includes a so-called Test Creation Framework (TCF) which has to be used by the test developer. Just as the service developer, the test developer also initially receives an informal description of a value-added service’s functionality. Based on this information, he can use the tools provided in the TCF in order to create tests that can be
Informal Requirements Service Creation Environment Application Server Service Developer
Service Customer Test Creation
Framework Test Developer
delivered to the Test Execution Environment (TEE) where they can be executed against the SUT, the deployed service running on the Application Server.
Independent of the TCF functionality, which will be introduced in section 4.3 and thoroughly described in the upcoming chapters 5, 6 and 7, the methodology illustrated in Figure 4.2 has some major drawbacks. First, the interpretation of the informal requirements by both the service developer and the test developer will definitely show a high probability to be different. This leads to the fact that the generated tests will most likely never pass because they will not match with the deployed service. Furthermore, the methodology is strictly based on a test-last approach. The testing of the service can only be done when the service is completely developed by the service developer. Hereby, a lot of project time is wasted because the test developer can only start with the test case execution at the end of the project.
In order to solve these issues, the methodology requires another new role, the service analyst. As mentioned before in section 4.1, the service analyst is the communication link between the service customer, the service developers and test developers. When a service customer commissions a service provider to develop a new value-added service for him, he will first get in contact with the service analyst who is working for the service provider. The service customer will tell the service analyst about his service idea and the requirements. Based on the informal information, the service analyst will create a document that contains all the relevant requirements in a structured way. In the best case, the document will consist of textual use cases. Throughout this thesis, this document will be referred to as “Structured Requirements”. Intentionally, no example guideline will be
4.2 Overall Methodology for Testing Value-Added Services
specified for the compilation of the “Structured Requirements” document, however, it has to fulfil the following requirements:
1. Each use case specified in the “Structured Requirements” document shall have a unique identifier or name. Additionally, all use cases shall be numbered (such as “Req01” for the initial specified use case).
2. If there are any dependencies between use cases they shall be specified.
3. For each use case, the actors shall be named and it shall be clear how the actors interact with the service to be specified.
4. The use case specification shall include successful scenarios as well as exceptions or alternative courses of actions.
An example specification language that fulfils all of these requirements is discussed in 5.1.2 and an example is illustrated in Table 5.3. There are many other possible related approaches that can be applied. A well-known and recognised approach is documented in (Cockburn, 2000).
Coming back to the methodology, as soon as the service analyst finalised the “Structured Requirements” document, it has to be accepted by the service customer and subsequently distributed to the service developer and to the test developer. Based on the specified use cases, both developers can start defining either the test process or the service process. A further positive aspect of the “Structured Requirements” document is that all stakeholders can rely on this document. It also enables an agile approach. Based on the requirements, both test developer and service developer can, for example, develop the service and test in order to fulfill the requirements for “Req01”. They should have an opportunity (e.g.
tool support) to notice each other’s progress based on the defined requirements. So, they are able to test parts of a service even if it has not been implemented completely.
In section 4.3, it will be discussed that due to the structure of the tools and components in the TCF, it is indeed possible to actually “synchronise” the processes of both service developer and test developer. In Figure 4.3, the proposed methodology is illustrated incorporating the “Structured Requirements” and the so-called “Service Quality Group” (SQG).
Figure 4.3: Proposed overall methodology
The concept behind the SQG is to handle the occurrence of errors due to the testing process. Of course, the members of the SQG are informed about the results (“Test Report”) of the testing process by the TEE as soon as the test case execution has terminated. Theoretically, occurring errors within the “Test Report” can have many reasons. The first possibility is that the test developer and the service developer have a different understanding of a certain aspect of the “Structured Requirements” document. This might need clarification. As the service analyst, the test developer and the service
Informal Requirements Service Creation Environment Application Server Service Developer Service Customer Test Creation Framework Test Developer
Test Execution Environment
Structured Requirements
Service Analyst
Test Developer Service Developer Service Quality Group
Test Report
4.2 Overall Methodology for Testing Value-Added Services
developer are members of the SQG, especially the service analyst can discover the misunderstanding. If even he is not capable of clarifying the problem, the service customer has to be consulted. Minor misunderstanding can be clarified by direct contact (for instance by Email or telephone call). More serious issues have to be solved during a project meeting with the participating members of the SQG and the service customer. Actually, consulting the customer to clarify issues is a positive aspect of the methodology. Although there is an accepted requirements document still misunderstandings can arise. In a case like this, it is very important that the problems are discussed in an early stage and that the service customer is involved. Another reason for an occurring error can be that either the test developer or the service developer did something wrong in their development or missed a step during the process. This can also easily be clarified by the SQG. Obviously, it is not always required to arrange meetings where every member of the SQG is present, but agreements between two parties at least have to be documented in short. This also complies with methods of agile development.
The tasks the stakeholders have to perform were discussed. The following UML use case diagram (see Figure 4.4) illustrates the relevant activities they have to perform, either on their own or together with the other stakeholders. As shown in the use case diagram, the final project meeting is defined as a separate meeting where the project is validated. The service customer will have the change to attend a demonstration of the functionality of the service performed by the service developer as well as a demonstration of the test case execution and the results of the tests performed by the test developer.
Figure 4.4: Use case diagram containing the tasks of the stakeholders
To sum up, the demonstrated methodology and concepts are oriented towards agile development. One of the highest priorities is that the service customer is satisfied, e.g. by continuously and early provisioning of usable services. Theoretically, the presented approach supports rapid prototyping. Such a prototype can claim to just support a selection of requirements specified in the “Structured Requirements” document. As the test developer and the service developer can synchronise their processes, the provided prototype can even be tested before. This aspect will be further analysed in section 7.4.