Patent Application
20150161029
Some enterprises provide an embedded environment for customers or vendors to provide integrated content, tools and methodologies required to implement, support, operate and monitor enterprise applications. Such an embedded environment offers features and functionalities that support various phases of the application management life cycle. Phases of the application management life cycle include requirements, design, build, test, deploy, operate, optimize, etc. In such an embedded environment, one phase of the application management life cycle provides a test landscape, where a test plan and associated tests can be generated. These tests are based on business processes. The tests are typically displayed in a hierarchy under the test plan. Specific tests may be executed in corresponding test systems. While a tester works on these tests, individual tests are required to be opened, and manually a connection is required to be established with the corresponding test systems. Thus it is challenging to manually connect with the test systems for executing individual tests.
The claims set forth the embodiments with particularity. The embodiments are illustrated by way of examples and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. Various embodiments, together with their advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings.
Embodiments of techniques for guided business process testing are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of the embodiments. A person of ordinary skill in the relevant art will recognize, however, that the embodiments can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In some instances, well-known structures, materials, or operations are not shown or described in detail.
Reference throughout this specification to “one embodiment”, “this embodiment” and similar phrases, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one of the one or more embodiments. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
Enterprise applications support various business processes, and individual business process is associated with a set of test plans. In a test phase of the application management life cycle, such business processes can be tested by generating test plans. Testing is performed to validate proper functioning of business processes in the enterprise application. Test plans include test steps, test steps include test activities, and test activities are associated with test cases. A test case is a set of instructions or steps used by a tester to determine if an application or system under test performs as expected. Test steps may be manual test steps or automated test steps. A tester can be a manual test user executing the test steps or a software application or software code that automatically executes the test steps. In an enterprise application, a guided test procedure is used to guide testers to test business processes. In guided test procedures, test plans associated with the business process are provided to the testers in a step by step manner.
Test steps can be added to the guided test procedure ‘Test O2C’.
In one embodiment, guided test procedures can be generated automatically from existing business processes including business steps. For example, when a guided test procedure is generated for a business process ‘create invoice’, name of the business process gets added as the name of the guided test procedure. Individual steps within the business process ‘create invoice’ such as ‘purchase order’, ‘account information’, etc., will be added as test steps within the guided procedure ‘create invoice’ as ‘purchase order’, ‘account information’, etc. Within the individual test step ‘create invoice’, an activity ‘create invoice’ with the same name as the test step is added. In the activity ‘create invoice’, any associated uniform resource locators for navigation and documentation are added automatically. In case the step ‘create invoice’ includes automatic tests, the automated tests are added to the activity in the ‘create invoice’ step. This automatically generated guided procedure ‘create invoice’ can be manually edited if required to add or edit information.
In
The next step is to assign testers to test activities in a test step.
Once testers are assigned to test activities, testers can view the test activities assigned to them as tasks in their task inbox.
During the execution of test activity ‘create quotation’ 615, tester2 can click on the uniform resource location specified in navigation ‘open URL’ 640, and tester2 will automatically be directed or navigated to the corresponding test system ‘test system2’ 655 which is linked to the navigation ‘open URL’640. The tester can automatically login to the ‘test system2’ 655 based on a set of pre-configured login details. During the execution of the test activity ‘create quotation’ 615, document specified in documentation ‘test.doc’ 645 can be used or referred to. Using the ‘create notification’ 660 option ‘tester2’ can notify the completion of test activity to the next tester ‘tester3’. Using ‘my overdue tasks’ 665 option, ‘tester2’ can view the overdue tasks assigned to ‘tester2’ which are past the due date. Similarly, ‘tester2’ can view the completed tasks using ‘my completed tasks’ 670 option. Upon completion of test activity, ‘tester2’ can set or alter the status of test activity ‘create quotation’ 615 from ‘not performed’ 635 to ‘performed’. Test activities can be exported using the ‘export’ 680 option.
The status of a test step depends on the status of test activities within the test step.
The status of test step ‘quotation’ 840 is based on the status of all the test activities with the test step ‘quotation’. For example, when the status of test activities ‘create quotation’ and ‘verify quotation’ are performed then the status of test step ‘quotation’ can be marked as ‘performed’ 855. In case of an automated test step including automated test activities, the execution of the test activities is automatic, and the result of test execution is logged in the log window 870. If the status of the automated test activities is ‘performed’, then the status of the automated test step is automatically set to ‘performed’. Based on the status of test step, progress of a test can be monitored. In one embodiment, an application programming interface (API) may be implemented to automatically read test related information generated by the test systems, and use it for further processing such as reporting purposes.
The various embodiments described above have a number of advantages. Guided business process testing enables users to work on the test steps and transact with the individual test systems using an automatic login in feature. This reduces the manual effort required to login to individual test systems. The log information and test data enables subsequent testers to continue with the testing process at ease. Testers can view the test activities assigned to them in task inbox. Testers can also keep track of the tests performed by them in task inbox. Upon completion of execution of a test activity, subsequent a tester is sent an automatic notification. This helps testers to start their tests in a timely manner. Guided test procedures also provide a functionality of adding both manual and automated test steps providing convenience to test designers. Using guided test procedures, overall manual effort by testers is significantly reduced and productivity is increased.
Some embodiments may include the above-described methods being written as one or more software components. These components, and the functionality associated with each, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as, functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components may be implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.
The above-illustrated software components are tangibly stored on a computer readable storage medium as instructions. The term “computer readable storage medium” should be taken to include a single medium or multiple media that stores one or more sets of instructions. The term “computer readable storage medium” should be taken to include any physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform any of the methods or process steps described, represented, or illustrated herein. Examples of computer readable storage media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs) and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment may be implemented using Java, C++, or other object-oriented programming language and development tools. Another embodiment may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions.
A data source is an information resource. Data sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as, relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like. Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as, Open Data Base Connectivity (ODBC), produced by an underlying software system (e.g., ERP system), and the like. Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources can include associated data foundations, semantic layers, management systems, security systems and so on.
In the above description, numerous specific details are set forth to provide a thorough understanding of embodiments. One skilled in the relevant art will recognize, however that the embodiments can be practiced without one or more of the specific details or with other methods, components, techniques, etc. In other instances, well-known operations or structures are not shown or described in detail.
Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments are not limited by the illustrated ordering of steps, as some steps may occur in different orders, some concurrently with other steps apart from that shown and described herein. In addition, not all illustrated steps may be required to implement a methodology in accordance with the one or more embodiments. Moreover, it will be appreciated that the processes may be implemented in association with the apparatus and systems illustrated and described herein as well as in association with other systems not illustrated.
The above descriptions and illustrations of embodiments, including what is described in the Abstract, is not intended to be exhaustive or to limit the one or more embodiments to the precise forms disclosed. While specific embodiments of, and examples for, the one or more embodiments are described herein for illustrative purposes, various equivalent modifications are possible within the scope, as those skilled in the relevant art will recognize. These modifications can be made in light of the above detailed description. Rather, the scope is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.
