A Practical Approach of Web System Testing

APractical Approach of Web System Testing Javier Jesus Gutierrez, Maria Jose Escalona, Manuel Mejias and Jesus Torres Department of Computer Languages and Systems. University of Seville, Spain. (javierj, escalona, risoto, jtorres)@lsi.us.es Introduction The process of testing software system is gaining more importance every day [6]. Software applications are growing in size and complexity quickly. It makes more necessary to dispose techniques to assure quality of the systems and that the result satisfied initial specifications [l]. Assure the quality of the system is very important in web engineering. First web systems, at the beginning of nineties, had a simple design based on static HTML pages. Nowadays, web systems are built applying heterogeneous technologies like client-side scripting languages included into HTML, client-side components like Java applets, server-side scripting languages like PHP or PERL, server-side components like Java Servlets, web services, databases servers, etc. All these heterogeneous technologies have to work together, in order to obtain a multi-user and multi-platform application. The design, maintenance and test of the modem web applications have many challenges to developers and software engineers [7][13]. Internet and web systems also bring to developers a new and innovative way to build software. Internet allows millions of users to access to an application [7]. Thus, problems in a web application can affect to millions of users, cause many costs to the business [13] and destroy a commercial image. For all these reasons, quality assurance and software testing acquire a vital importance in the web system development. This work introduces theory and practice about the generation and implementation of system test cases in web applications. This work presents a complete vision of system testing showing how to put in practice the ideas exposed. Section 2 defines the process of software testing and studies in depth system testing process and how it can be applied to web development. Section 3 shows a practical case of generation and implementation of system test cases. Finally, section 4 resumes conclusions and future works. System Testing over Web Systems This section describes the process of software testing, studies the process of system testing in depth, from the point of view of web engineering and, finally, describes briefly a proposal to generate system test cases in a sys tematic way. This approach will be applied in the practica! case described in section 3. An Overview of Software Testing Process The process of software testing cannot be done at the end of the construc tion of the system, neither expecting to test the whole system ant one time [2]. The process of software testing has to be divided into sub-process. Every sub-process indicates which elements must be tested and the mo ment to perform every test. The sub-process might be applied when first elements under test are available. One possible division in sub-process widely accepted is showed in figure 1 [9]. System requlrements Verlfles Acceptance testlng Verifles 1 1 �re-q!_r!_ t=_n_ts� ••----------1 System testlng / ¡ Components lnteractlon Components In lsolatlon Verlfles q -;; lntegratlon � testlng Unlttestlng Fig. 1. Software testing process Unit testing is done during building of software system [8]. Their objec tives are the verification of the design and the functionality of every com ponent in the system. Integration testing is done during the building of software system. Their objectives are the verification of the union among system components through their interfaces and their functionality. System testing is done after building of software system. System testing answer the question: is the entire system working to deliver the user goals? [17]. Acceptance testing is done after software system implantation. Their ob jectives are the verification that system covers all requirements expected and satisfies the needs of the users. In figure 1 another kind of testing, regression testing, is lost. It was not included because they are not perf ormed during the development of the system. Regression testing are applied during the maintenance of the sys tem to accurate that the changes <loes not introduces unexpected errors in unmodified elements. Testing process described in figure 1 might be applied to all types of software system: desktop applications, client-server applications, mobile applications, etc. In the specific case of web systems, it is needed to ar range specific techniques, like separate client-side and server-side compo nents, and specific tools, like HTML validation tool, to web applications that allows to apply this process. Next section describes in depth the process of the software system test ing and how it must be applied in web projects. System Test Process Unit and integration testing guarantees an error-free code, or, at least, that the code has not the most important or common errors, due of the fact that it is impossible to test the whole code in depth [2]. However, unit and inte gration testing are not enough to assure the quality of the system. It is pos sible to have an error-free code that <loes not satisfy the expectative or the needed of the system final users. This one makes necessary a system test phase. This phase will be performed after unit and integration test phases, and when first system requirements are completely implemented. An important rule that can be applied in all phases of software testing process is that testing must begin as soon as possible [12]. Due the cost of time and resources needed to correct an error increases at same time than time between the apparition and the detection of that error, it is vital to de tect all errors as soon as possible. In system test cases, system is verified like a black box. Thus, system tester have to wait until the system is built, or, at least, until sorne requirements are fully implemented. An imple mented requirement means that all elements needed to perf orm that re quirements from the user point of view, like user interfaces, persistent lay ers, databases, etc, are implemented. However it is possible to advance definition and design of system test cases to early development phases. In [4] a group of representative proposals of early testing are described, analyzed and compared. The process of generation of system test cases from functional require ments consists in build a use model of the system from its requirements, and, later, to generate a set of input values, a set of events or interactions among system and users or actors, and the expected results [5]. The evolu tion of methodological proposals to drive this process has been focused in how to build and represent the use model. There are works, like [ 11 ], that propose new kinds of requirements spe cific for web development, like actors' requirements, adaptability require ments or navigational requirements. However, functional requirements are still playing a very important role in web systems, but must be comple mented with other types of requirements like navigational or information requirements. Functional requirements should be independent ofthe implemented plat form or the architecture of the system in early development phases. Thus functional requirements must not include any reference to any platform, like web or standalone platform. Due this fact, methodologies to generate system test cases from requirements are also applied in web systems. An example of integration of a process to generate system cases into a web development methodology can be found in [9]. Test cases are, also, inde pendence of the complexity ofweb interfaces. Next section describes a possible approach to generate automatically system test cases. This process is applied in the practica! example in sec tion 3. A Proposal to Generate System Test Cases from Requirements Descriptions of functional requirements are the main artifact to the design of system test cases [ 5]. N owadays, there are a big number of proposals to systematize this process. A complete survey about these proposals is pre sented in [4]. This section introduces briefly the fundaments of a systematic proposal to generation of system test cases from use cases. This proposal has been development from the conclusions of comparative studios and analyzes of several existing proposals, like [ 4]. The generation of test cases is showed in figure 2 with an activity diagram [14]. It starts with the enumeration and the description of the observable results. An observable result is anything that can be automatically or manual checked, like a system screen, a new stored, modified or deleted record, a received message by other computer or server, etc. In conclusion, In second step, all possible execution paths are identified. An execu tion path is a description ofthe interactions among system and one or more actors to obtain one of the results identified in previous activity. After identifying all the execution paths, all needed values for each path must be identified. A valid value is a data or precondition that applied to an execution path allows obtaining the expected result. In the last step, all redundant execution paths must be removed. An execution path is redundant when there is other equal path or when it is in cluded into other path, with the same values, and the same results are ob tained. ldentify observable results ldentify execution paths Assign a set of values to each path Erase redundan! paths Fig. 2. Activity diagram to generate system test cases This proposal can be applied in parallel with identification and defini tion of requirements. In the next section, we are going to put in practise this proposal in order to generate a set of system test cases for a simple ex ample. A Case Study In order to explain in a detail way the approach presented in the previous section, in this section we are going to apply it in a real project. System Description This section describes a simplified web application that we use like a sim ple example in next sections to apply the presented approach. The objec tive of this web system is to manage the information about customers in a business. Concretely, the selected example is the functional requirement: ''System must allow that one registered user inserts new customers into customers database". It indicates that the system has to allow to add new costumers. This requirement is too basic and ambiguous to be directly imple mented. Thus, the requirement has been refined and splitters in two use cases. The first use case describes the process to access into the system and the second one offers the way to insert a new customer. Both use cases are graphically showed in the UML use case diagram [14) in figure 3 and de scribed textually in table 2 and 3. Customer management Fig. 3. Use cases to insert new customers In order to describe deeply each requirements. We will use a pattems, that is a special template, described by the proposals NDT (Navigational Development Techniques) [11]. NDT is a methodological proposal to drive the requirements and analysis phases in a web system development. NDT also includes a support tool called NDT-Tool [10]. For instance, the pattem for the firs use cases is presented in table 2. Using a similar pattem for the other use case, the requirements can be implemented in a web application. In our wor, Technologies used in the implementation were HTML and JavaScript, to define the user interfaces, and PHP to define the business logic and data access. This web application is composed of two main forms: the first one controls the access to the sys tem, and the other one inserts new customers. Figures 4 shows the first one. Table l. Textual description for the use case "Access to the system" FR-0 I Access to the system Description The system has to manage the access to the system and verify the identity of each doctor. For that, it has to play like it is describe in this use case. Normal execution Step Action Post-condition Exceptions User login screen I An user tries to access to the system 2 System asks for identifier and password. 3 User gives the system this information. 4 If this information is correct, the system allows the user the access, and its continue with use case FR02. None Step Action 3 If identifies does not exist and the number of attempts is less than 3, system shows a message telling that user name does not exists and asks it again. 3 If password does not match with the user password and the number of attempts is less than 3, system shows a message telling that password is invalid and asks it again. 3 If identifier does not exist or password does not match and the number of attempts is 3 or bigger, system shows a message and denied aecess to the s stem. Valid user name and password Fig. 4. Access to system screens Unit and integration testing have already been successfully performed. Next section shows how to generate a set of test cases from the require ments of this application. System Test Cases Generation Previous section has showed a proposal to generate system test case from functional requirements expressed like use cases. In this section, that pro posal will be applied to generate test cases from use cases described. These test cases will verify the success implementation of the requirement de scribed in table 1 into the web application. ··-·- , __ Attemp) 1 I.Attempt_2_JAttemptJ.__ [1] + A , [11 A ¡ A -Access anowed. A �--�=�5s��:��d .;_,ith invalid name IN IN 121 IN -D message. [31 IP _ 0 IP -Login screen with invalid 1 dA password message. IP \.LÁ IN -D [1] -Valid name and f ¡1¡ IP -D password. A -Ei1¡ [2] -!nvalid name. 131 A [3] -[nvalid password. IP IN 21 IN-O 11P�::�: j �IP-D Fig. 5. Execution paths from "Access to system" use case The simplest way to find execution paths is to explore all combinations among steps described in a use case. Figures 5, for instance, shows execu tion paths that cover all combinations of steps. They include the normal execution sequence and the altemative execution sequences. From the "Access to system" use case, twenty-one execution paths are generated. It is more difficult to study the number of possible combinations in the "Insert customer" use case. In theory, an infinite number of executions paths are possible, for instance, "do not writing a mandatory field". In our cxample, we are going to suppose that this scenario can appear just one time, in order words, a mandatory field could be empty just the first time. Applying this supposition, from the "Insert customer" use case, , seven execution paths are generated. Calculating all possible combinations between both use cases, 21 x 7 = 147 execution paths are generated. This number is too high in order to im plement one test from each possible execution path. We will choose a rep resentative subset of paths only to be implemented as system test cases. lt is out of the scope ofthis work to show the criterions to select the adequate paths to be implemented as test cases. Several algorithms for select paths can be found in [15] and [16]. Sorne heuristics and guides can be applied in order to sure the quality of the election. Next paragraphs describe the chosen paths. The objective of system test cases is to verify the success insertion of a new customer. The only way to access to insertion customer form is from user login screen. So, the entire test includes a valid login, in other words, a success path through the use case in table 2. Table 3. Executions paths Execution path description Write a valid name and password. Write a valid customer. Observable result. Customer inserted screen. 2 Write a valid name and password. Customer inserted screen. Write a valid customer without a mandatory field. Write the mandatory field. 3 Write a valid name and password. Customer error screen. Write an existing customer. Path l 2, 3 1, 3 2 Values set Valid login. Valid customer. Valid customer without a mandatory field. Table 4. Test values Concrete values. Name: validname Password: validpassword. Customer : customer name Activity : customer _ activity Address : customer address City : customer _ city Postal code : customer _postalcode T elephone : customer _ telephone Customer : customer name Activity : customer _ activity Address : <empty> City: customer_city Postal code : customer _postalcode Telephone : customer telephone