Abstract: The present subject matter relates to computer implemented systems and methods related to test design automation. In one embodiment, a method of test design automation comprises receiving business requirements. The business requirements comprise at least a process flow diagram (128). Based on the business requirements, a plurality of test scenarios (130-1) is created. Based on the plurality of test scenarios (130-1), a plurality of test cases (132-1) is generated.
FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10, rule 13)
1. Title of the invention: TEST DESIGN AUTOMATION
2. Applicant(s)
NAME NATIONALITY ADDRESS
TATA CONSULTANCY Indian Nirmal Building, 9th Floor, Nariman Point,
SERVICES LIMITED Mumbai-400021, Maharashtra, India
3. Preamble to the description
COMPLETE SPECIFICATION
The following specification particularly describes the invention and the manner in which it
is to be performed.
TECHNICAL FIELD
[0001] The present subject matter, in general, relates to software testing automation,
and in particular, to systems and methods of test design automation.
BACKGROUND
[0002] Software testing is an important phase of the software development process.
Software testing is the process of interacting with software with the aim of revealing errors. Software testing is necessary in order to ensure that the software actually performs what it is supposed to do, and does so correctly. The complete software testing process, generally referred to as testing lifecycle, includes a series of testing activities that may be iterative in nature.
[0003] With an increase in complexity of software as well as stringent quality
requirements to be fulfilled by them, the need for effective testing has increased and, furthermore, the testing lifecycle has become very exhaustive, thereby consuming immense resources of the software organization. It is estimated that almost half of the total effort in the software development process is dedicated to testing and debugging of the software. Moreover, the efficiency and profitability of a software organization depends highly on its testing capabilities. In the recent times, several approaches have been followed to automate one or more of the phases or activities in software testing. However, test design, which consumes around 30%-40% of the total testing efforts, largely remains a manual activity.
SUMMARY
[0004] This summary is provided to introduce concepts related to test design
automation. These concepts are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
[0005] Computer implemented systems and methods related to test design automation
are described. In one embodiment, a method of test design automation comprises receiving business requirements. The business requirements comprise at least a process flow diagram.
Based on the business requirements, a plurality of test scenarios is created. Based on the plurality of test scenarios, a plurality of test cases is generated.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] The detailed description is described with reference to the accompanying
figure(s). In the figure(s), the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the figure(s) to reference like features and components. Some embodiments of system and/or methods in accordance with embodiments of the present subject matter are now described, by way of example only, and with reference to the accompanying figure(s), in which:
[0007] Fig. 1(a) illustrates a network environment implementing a test design
automation system, in accordance with an embodiment of the present subject matter.
[0008] Fig. 1 (b) illustrates a process flow diagram, in accordance with an embodiment
of the present subject.
[0009] Fig. 2 illustrates a method of test design automation, in accordance with an
embodiment of the present subject matter.
DETAILED DESCRIPTION
[0010] A software testing life cycle involves a series of phases, such as test planning,
test designing, and test execution. Conventionally, several approaches have been followed to automate one or more of the phases or activities in the software testing life cycle. For example, there are several automation tools available presently for automating test management and test execution. However, test design, which consumes 30%-40% of the total testing effort, largely remains a manual activity, thereby lacking efficiency. The professionals involved in software testing create test cases manually. Thus, a large amount of testing effort is spent on identifying combinational data, generate test combinations, etc. It is to be understood that such manual generation of the test cases are also prone to errors, and full test coverage of the business requirements may not be achieved.
[0011] In accordance with the present subject matter, systems and methods for test
design automation are described. The systems and methods enable automatic generation of
test scenarios and test cases, thereby saving time and efforts of users, such as test analysts. Further, the test scenarios and test cases are optimized to generate optimal number of test scenarios and test cases that can be utilized for testing the functionality of the software.
[0012] In one implementation, a test automation system (hereinafter referred to as a
system) receives business requirements as inputs. Such business requirements may be in the form of process flow diagrams either created within the system or imported into the system from external sources. For example, the process flow diagrams may be preexisting or may be prepared using any conventional tool/system and provided as an input to the system.
[0013] The system analyzes the business requirements or the business process flow
diagrams to generate a set of test scenarios. Further, the system performs an optimization process on the test scenarios to generate a set of optimized test scenarios. As a part of the optimization process, the system identifies and eliminates duplicated or redundant test scenarios, if any.
[0014] Subsequent to generation of the optimized test scenarios, the system may
generate test cases for each of the optimized test scenarios along with a set of parameters values. Further, the system performs the optimization process on the test cases to generate a set of optimized test cases. The optimization process removes any duplication in the test cases.
[0015] Thus, the systems and method in accordance with the present subject matter
automatically generates optimized test scenarios and optimized test cases by taking business process flow diagrams as input. Thus, testing resources, i.e. time and efforts of a testing analyst, involved in designing test scenarios and test cases is significantly reduced, as the test analyst need not spend much time in generation of the test scenarios/test cases. Such optimized test scenarios and test cases may be displayed or provided to a user in a human-readable format, for example, in an MS Excel sheet.
[0016] The manner in which the test design automation takes place shall be explained
in detail with respect to the Figs. 1-2. While aspects of systems and methods can be implemented in any number of different computing systems environments, and/or configurations, the embodiments are described in the context of the following exemplary system architecture(s). Furthermore, the present description has been provided with
implementations that are specific to certain business functions or certain businesses. It would be appreciated that other implementations are also covered without deviating from the scope of the present subject matter.
[0017] Fig. 1(a) illustrates a network environment 100 implementing a test design
automation system 102, in accordance with an embodiment of the present subject matter. In one implementation, the network environment 100 can be a public network environment, including thousands of personal computers, laptops, various servers, such as blade servers, and other computing devices. In another implementation, the network environment 100 can be a private network environment with a limited number of personal computers, servers, laptops and other computing devices.
[0018] The test design automation system 102 (hereinafter referred to as system 102) is
communicatively connected to a plurality of user devices 104-1, 104-2,... 104-N, collectively referred to as the user devices 104 and individually referred to as a user device 104, through a network 106. In one implementation, a plurality of users, such as test analysts and subject matter experts (SMEs) may use the user devices 104 to communicate with the system 102 for test design automation.
[0019] The system 102 and the user devices 104 may be implemented as any of a
variety of conventional computing devices, including, servers, a desktop personal computer, a notebook or portable computer, a workstation, a mainframe computer, and a laptop. Further, in one implementation, the system 102 may itself be a distributed or centralized network system in which different computing devices may host one or more of the hardware or software components of the system 102. In another implementation, the various components of the system 102 may be implemented as a part of the same computing device.
[0020] The system 102 is connected to the user devices 104 over the network 106
through one or more communication links. The communication links between the system 102 and the user devices 104 are enabled through a desired form of communication, for example, via dial-up modem connections, cable links, digital subscriber lines (DSL), wireless or satellite links, or any other suitable form of communication.
[0021] The network 106 may be a wireless network, a wired network, or a combination
thereof. The network 106 can also be an individual network or a collection of many such individual networks, interconnected with each other and functioning as a single large network, e.g., the Internet or an intranet. The network 106 can be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and such. The network 106 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), etc., to communicate with each other. Further, the network 106 may include network devices, such as network switches, hubs, routers, for providing a link between the system 102 and the user devices 104. The network devices within the network 106 may interact with the system 102 and the user devices 104 through the communication links.
[0022] In one implementation, the system 102 receives business requirements. The
business requirements may be in form of business process flow diagrams, such as UML based process flow diagrams and state transition diagrams. Subsequent to receiving the business requirements, the system 102 processes the received business requirements to generate optimized test scenarios and optimized test cases. For this purpose, the system 102 includes one or more processor(s) 108, a memory 112 coupled to the processor(s) 108, and interface(s) 110. The processor(s) 108 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor(s) 108 are configured to fetch and execute computer-readable instructions and data stored in the memory 112.
[0023] The interface(s) 110 may include a variety of software and hardware interfaces,
for example, interface for peripheral device(s) such as a keyboard, a mouse, an external memory, a printer, etc. Further, the interface(s) 110 may enable the system 102 to communicate over the network 106, and may include one or more ports for connecting the system 102 with other computing devices, such as web servers and external databases. The interface(s) 110 may facilitate multiple communications within a wide variety of protocols
and networks, such as a network, including wired networks, e.g., LAN, cable, etc., and wireless networks, e.g., WLAN, cellular, satellite, etc.
[0024] The memory 112 may include any computer-readable medium known in the art
including, for example, volatile memory such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. The memory 112 also includes modules 114 and data 116.
[0025] The modules 114 include routines, programs, objects, components, data
structures, etc., which perform particular tasks or implement particular abstract data types. The modules 114 further include a modeler 118, a test scenario generation module 120, a test case generation module 122, and other module(s) 124. The other module(s) 124 may include programs or coded instructions that supplement applications and functions on the system 102, for example, programs in the operating system.
[0026] The data 116, amongst other things, serves as a repository for storing data
processed, received, and generated by one or more of the modules 114. The data 116 includes process flow diagram 128, optimized test scenarios 130, optimized test cases 132, and other data 134. The other data 134 may include data generated as a result of the execution of one or more modules in the other module(s) 124.
[0027] In operation, the system 102 receives business requirements. The business
requirements may be in form of the process flow diagram 128, such as an UML based process flow diagram, and state transition diagram. In one implementation, the process flow diagram 128 may be imported into the system 102 from various sources. For example, a user may create process flow diagram using conventionally available modeling tools on a user device, say, the user device 104-1, and import the process flow diagram from the user device 104-1 into the system 102. In another implementation, the user may create or draw the process flow diagram 128 using the modeler 118, which is a conventionally known process flow diagram modeling tool, integrated within the system 102.
[0028] The test scenario generation module 120 within the system 102 receives the
process flow diagram 128 as input to generate a set of test scenarios 130-1. For the purpose of
the generation the test scenarios 130-1, the test scenario generation module 120 determines all the possible paths from a start state to an end state in the process flow diagram 128. These paths may be indicative of series of actions that are performed when moving from one state to another state in the process flow diagram 128. Such series of actions corresponds to a test scenario. Thus, a plurality of test scenarios 130-1 are generated covering every possible path in the process flow diagram 128 from the start state to the end state.
[0029] Once the test scenarios 130-1 are generated, the test scenario generation module
120 eliminates duplicated scenarios from the generated test scenarios, if any, to generate a set of optimized test scenarios 130-2. The duplicated scenarios may be understood as the test scenarios that are covered within one or more other test scenarios.
[0030] Once the test scenarios 103 are generated, the test case generation module 122
within the system 102 generates a plurality of test cases 132-1 for each of the optimized test scenarios 130-2. For generating the test cases 132-1, the test case generation module 122 performs pair-wise testing for each of the states (also referred to as parameters) in the optimized test scenarios 130-2. In pair-wise testing, for each pair of parameters in the optimized test scenarios 130-2, the test case generation module 122 creates multiple pair-wise test sets that correspond to the plurality of test cases 132-1, for every combination of valid values of the parameters. Thereafter, the test case generation module 122 eliminates duplicated test cases or pair-wise test sets from the plurality of test cases 132-1 to generate a set of optimized test cases 132-2.
[0031] The generation of optimized test scenarios 130-2 and optimized test cases 132-2
is further described in details by way of an exemplary process flow diagram 128 illustrated in the Fig.l (b). In the Fig. 1(b), the depicted process flow diagram 128 is a state transition diagram containing a start state and end state, and a plurality of intermediate states A, B, Bl, C, D, E, and F in between the start state and the end state.
[0032] For generating the test scenarios 130-1, the test scenario generation module 120
determines all the possible paths in the process flow diagram 128 from the start state to the end state. As indicated previously, the paths may be indicative of series of actions that are performed when moving from one state to another state in the process flow diagram 128.
Such series of actions corresponds to a test scenario. Thus, a plurality of test scenarios is generated. Referring to the process flow diagram depicted in the fig. 1(b), the test scenario generation module 120 determines the paths represented in the table 1 below.
TABLE 1
Start A C D End
Start A C E End
Start A C F End
Start A C D E End
Start A C D E F End
Start A C E F End
Start A B C D End
Start A B C E End
Start A B c F End
Start A B c D E End
Start A B c D E F End
Start A B c E F End
Start B C D End
Start B C E End
Start B C F End
Start B C D E End
Start B C D E F End
Start B C E F End
Start B B1 C D End
Start B B1 C E End
Start B B1 c F End
Start B B1 c D E End
Start B B1 c D E F End
Start B B1 c E F End
Start A B B1 C D End
Start A B B1 C E End
Start A B B1 c F End
Start A B B1 c D E End
Start A B B1 c D E F End
Start A B B1 c E F End
[0033] The paths shown in various rows of the table 1 represents the test scenarios 130-
1. Thus, 30 test scenarios 130-1, each corresponding to a row and each row in turn
corresponding to a path of the process flow diagram, are generated Subsequent to generation of the test scenarios 130-1, the test scenario generation module 120 eliminates duplicated scenarios, thereby generating a set of optimized test scenarios 130-2. As mentioned previously, a duplicated scenario may be understood as the test scenarios that are covered within one or more other test scenarios. In said embodiment, the test scenario generation module 120 eliminates the duplicated test scenarios illustrated in the table 1 to generate a set of optimized test scenarios 130-2, which are illustrated in the table 2 below.
TABLE 2
Start A C F End
Start A C D E F End
Start A C E F End
Start A B C D End
Start A B C F End
Start A B c E F End
Start B C E F End
Start B B1 c E F End
Start A B B1 C D End
Start A B B1 C E End
Start A B B1 c F End
Start A B B1 c D E End
[0034] Thus, the test scenario generation module 120 generates 12 optimized test
scenarios 130-2 shown in the table 2. Subsequent to generation of the optimized test scenarios 130-2, the test case generation module 122 within the system 102 generates test cases 132-1 for each of the optimized test scenarios 130-1. For example, referring to the first scenario Start->A->C->F->End in the table 2, the test case generation module 122 creates pair-wise test sets for every combination of valid values of the parameters. These pair-wise test sets represents test cases 132-1. In said example, considering the parameter values for parameter A as A1 and A2, for parameter B as B1, B2, and B3, and for parameter F as F1, and F2, following are the pair-wise test sets that are generated by the test case generation module 122.
[0035] For Parameter A and B: {(A1, B1), (A1, B2), (A1, B3), (A2, B1), (A2, B2), (A2, B3)}
test cases are generated, and for Parameter A, B, and F: {(A1, B1, F1), (A1, B2, F1), (A1, B3, F1), (A2, B1, F1), (A2, B2, F1), (A2, B3, F1), (A1, B1, F2), (A1, B2, F2), (A1, B3, F2), (A2, B1, F2),
(A2, B2, F2), (A2, B3, F2)} test cases 132-1 are generated. Likewise, the test cases 132-1 for the remaining optimized test scenarios 130-2 shown in the table 2 are generated. Further, the test case generation module 122 eliminates duplicated test cases from the plurality of test cases 132-1 to generate a set of optimized test cases 132-2.
[0036] Thus, the system 102 generates optimized test scenarios 130-1 and optimized test
cases 132-1, based on the business requirements, thereby automating the test design phase of the software testing life cycle. In one implementation, the system 102 may provide the optimized test scenarios 130-1 and the optimized test cases 132-1 to a user in a human-readable format, for example, in an MS Excel sheet.
[0037] Fig. 2 illustrates a method 200 for test design automation, in accordance with an
embodiment of the present subject matter. The method may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. The method may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices.
[0038] The order in which the method is described is not intended to be construed as a
limitation, and any number of the described method blocks can be combined in any order to implement the method, or an alternative method. Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof.
[0039] At block 202, business requirements are received. In one implementation, the
system 102 receives the business requirements. The business requirements may be in form of process flow diagrams 128, such as UML based process flow diagrams and state transition diagrams. Such process flow diagrams 128 may either be imported into the system 102 from various external sources or can be modeled/created within the system 102. In one
implementation, the modeler 118 within the system 102 facilitates creation of the process flow diagrams 128.
[0040] At block 204, a plurality of test scenarios are created based on the business
requirements. In one implementation, the system 102 creates test scenarios 130-1 based on the business requirements. Subsequent to generation of the test scenarios 130-1, the system 102 eliminates duplicated test scenarios, if any, to generate a set of optimized test scenarios 130-2. The optimized test scenarios 130-2, thus generated can be displayed on a user interface of the user device 104 or provided to a user/tester in a human-readable format or a report format, for example, in form of an Excel sheet.
[0041] At block 206, a plurality of test cases is generated for each of the plurality of
test scenarios. In one implementation, the system 102 generates test cases 132-1 for each of the optimized test scenarios 130-2. Subsequent to generation of the test cases 132-1, an optimization process for optimizing the test cases 132-1 is performed. The optimization process, for example, identifies and eliminates the presence of any redundant test cases to generate optimized test cases 132-2. The generated test cases 130 can be displayed on a user interface of the system 102 or provided to a user/tester in a report format, for example, in form of an Excel sheet. In one implementation, the test scenarios 130 and test cases 132 may be provided in two separate readable documents to the user. In another implementation, both the test scenarios 130 and test cases 132 may be provided to the user in a single readable document.
[0042] Although embodiments for test design automation have been described in
language specific to structural features and/or methods, it is to be understood that the invention is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as exemplary implementations for the test design automation systems and methods.
I/We claim:
1. A test design automation system (102) comprising:
a processor (110); and
a memory (112) coupled to the processor (110), the memory (112) comprising: a test scenario generation module (122) configured to: receive a process flow diagram (128); and
create at least one optimized test scenario (130-2) based on the process flow diagram (128); and
a test case generation module (122) configured to generate at least one optimized test case (132-2) for each of the at least one optimized test scenario (130-2).
2. The test design automation system (102) as claimed in claim 1, wherein the test
scenario generation module (120) generates the at least one optimized test scenario (130-2) based on determination of a plurality of paths in the process flow diagram (128), and elimination of duplicate paths from the plurality of paths.
3. The test design automation system (102) as claimed in claim 1, wherein the test case
generation module (120) generates the at least one optimized test case (132-2) based on creation of a plurality of pair-wise test sets for every combination of valid values of parameters in the process flow diagram (128), and elimination of duplicated pair-wise test sets from the plurality of pair-wise test sets.
4. The test design automation system (102) as claimed in claim 1 further comprises a
modeler (118) for modeling the process flow diagram (128).
5. A computer implemented method of test design automation, the method comprising:
receiving business requirements, wherein the business requirements comprise at least a process flow diagram (128);
creating a plurality of test scenarios (130-1) based on the business requirements; and
generating a plurality of test cases (132-1) based on the plurality of test scenarios (130-1).
6. The method as claimed in claim 5, wherein the creating comprises determining a plurality of paths in the process flow diagram (128), wherein each of the plurality of paths corresponds to each of the plurality of test scenarios (130-1).
7. The method as claimed claim 5, wherein the creating further comprises eliminating duplicate test scenarios from the plurality of test scenarios (130-1) to generate at least one optimized test scenario (130-2).
8. The method as claimed in claim 5, the generating comprises identifying a plurality of pair-wise test sets for every combination of valid values of parameters in the process flow diagram (128), wherein each of the plurality of pair-wise test sets corresponds to each of the plurality of test cases (132-1).
9. The method as claimed claim 5, wherein the generating further comprises eliminating duplicate test cases from the plurality of test cases (132-1) to generate at least one optimized test case (132-2).
10. A computer-readable medium having embodied thereon a computer program for executing a method comprising:
receiving business requirements, wherein the business requirements comprise at least a process flow diagram (128);
creating a plurality of test scenarios (130-1) based on the business requirements; and
generating a plurality of test cases (132-1) for each of the plurality of test scenarios (130-1).
| # | Name | Date |
|---|---|---|
| 1 | ABSTRACT1.jpg | 2018-08-10 |
| 2 | 3689-MUM-2011-PETITION UNDER RULE-138(13-7-2012).pdf | 2018-08-10 |
| 3 | 3689-MUM-2011-FORM 26(23-2-2012).pdf | 2018-08-10 |
| 4 | 3689-MUM-2011-FORM 18(6-1-2012).pdf | 2018-08-10 |
| 5 | 3689-MUM-2011-FORM 1(13-7-2012).pdf | 2018-08-10 |
| 6 | 3689-MUM-2011-CORRESPONDENCE(6-1-2012).pdf | 2018-08-10 |
| 7 | 3689-MUM-2011-CORRESPONDENCE(23-2-2012).pdf | 2018-08-10 |
| 8 | 3689-MUM-2011-CORRESPONDENCE(13-7-2012).pdf | 2018-08-10 |
| 9 | 3689-MUM-2011-FORM 3.pdf | 2018-10-03 |
| 10 | 3689-MUM-2011-FORM 2.pdf | 2018-10-03 |
| 11 | 3689-MUM-2011-FER.pdf | 2018-10-24 |
| 12 | 3689-MUM-2011-OTHERS [22-04-2019(online)].pdf | 2019-04-22 |
| 13 | 3689-MUM-2011-FER_SER_REPLY [22-04-2019(online)].pdf | 2019-04-22 |
| 14 | 3689-MUM-2011-COMPLETE SPECIFICATION [22-04-2019(online)].pdf | 2019-04-22 |
| 15 | 3689-MUM-2011-CLAIMS [22-04-2019(online)].pdf | 2019-04-22 |
| 16 | 3689-MUM-2011-ABSTRACT [22-04-2019(online)].pdf | 2019-04-22 |
| 17 | 3689-MUM-2011-Correspondence to notify the Controller [05-10-2020(online)].pdf | 2020-10-05 |
| 18 | 3689-MUM-2011-Written submissions and relevant documents [21-10-2020(online)].pdf | 2020-10-21 |
| 19 | Form-3.pdf | 2021-10-03 |
| 20 | Form-1.pdf | 2021-10-03 |
| 21 | Drawings.pdf | 2021-10-03 |
| 22 | 3689-MUM-2011-US(14)-HearingNotice-(HearingDate-09-10-2020).pdf | 2021-10-03 |
| 1 | 3689mum2011_15-10-2018.pdf |