System, method, and computer program for software testing project design and execution utilizing a mockup

A system, method, and computer program product are provided for software testing project design and execution utilizing a mockup. In use, at least one software testing project to design is identified. Additionally, at least one mockup of the at least one software testing project is generated. Further, one or more testable items associated with the at least one mockup are defined. In addition, one or more test cases associated with the at least one mockup are generated. Furthermore, the one or more test cases are linked to the one or more testable items. Moreover, the at least one mockup including the one or more test cases linked to the one or more testable items is displayed. In one embodiment, a status of the one or more test cases may be updated according to a test execution within the at least one software testing project. Furthermore, at least one defect may be linked to every mockup that showed one or more errors within and/or outside a defined testable item.

FIELD OF THE INVENTION

The present invention relates to visual test design and execution.

BACKGROUND

Current test methodologies are free text driven. Such test methodologies require the test designer to describe, in text, the tests expected to be run by the test executer. The test designer is left with a constant conflict of how long to make text descriptions associated with the test. If the text is too short, the test may not be clear enough. If the text is too long the executer might not read all the important parts of the text. As a result, text executers never manage to have all the right data or only the data truly needed.

Additionally, because the current test methodologies are text driven, such methodologies are limited to describe only the exact function being tested. However, test executers often find issues outside the planned tests.

Furthermore, because the current test methodologies are text driven, such methodologies face extreme difficulties when trying to link tests to defects. Thus, test executers may never have a clear view of the issues that were previously reported in a test flow.

SUMMARY

A system, method, and computer program product are provided for software testing project design and execution utilizing a mockup. In use, at least one software testing project to design is identified. Additionally, at least one mockup of the at least one software testing project is generated. Further, one or more testable items associated with the at least one mockup are defined. In addition, one or more test cases associated with the at least one mockup are generated. Furthermore, the one or more test cases are linked to the one or more testable items. Moreover, the at least one mockup including the one or more test cases linked to the one or more testable items is displayed. In one embodiment, a status of the one or more test cases may be updated according to a test execution within the at least one software testing project. Furthermore, at least one defect may be linked to every mockup that showed one or more errors within and/or outside a defined testable item.

DETAILED DESCRIPTION

FIG. 1illustrates a method100for software testing project design and execution utilizing a mockup, in accordance with one embodiment.

As shown, at least one software testing project to design is identified. See operation102. The software testing project may include any type of software testing project. For example, in one embodiment, the software testing project may be associated with a telecommunication service provider. Of course, the software testing project may be associated with a variety of industries and/or organizations.

Additionally, at least one mockup of the at least one software testing project is generated. See operation104. In the context of the present description, a mockup refers to any prototype or model that provides at least part of the functionality of a system or computer code (e.g. software, etc.) associated with a testing project that enables testing of a design. The prototype may be imported to and/or designed within the system's computer program.

In one embodiment, the mockup may include a mockup of a graphical user interface associated with the at least one software testing project and/or supporting test tools. In various embodiments, the mockup may include one screen or a plurality of screens.

Further, one or more testable items associated with the at least one mockup are defined. See operation106. The testable items may include any aspect of a system or software that is capable of being tested. For example, the testable items may include functionality with a plurality of possible input parameters, etc.

In addition, one or more test cases associated with the at least one mockup are generated. See operation108. Furthermore, the one or more test cases are linked to the one or more testable items. See operation110.

Moreover, the at least one mockup including the one or more test cases linked to the one or more testable items is displayed. See operation112. The mockup may identify a testing flow of the one or more testable items. For example, the mockup may show steps to execute as part of a testing flow.

As shown further inFIG. 1, a status of the one or more test cases may be updated according to a test execution within the at least one software testing project. See operation114. Furthermore, at least one defect may be linked to every mockup that showed one or more errors within and/or outside a defined testable item. See operation116.

In one embodiment, the test cases may be capable of being tracked in a quality center associated with the testing process. Additionally, the test cases may be capable of being immediately updated (e.g. in response to defects, issues, etc.).

Further, the test cases may include text associated with one or more actions associated with the test cases. The text will be short enough so that the text is not too detailed, but detailed enough to convey important aspects of the test.

The mockup may be utilized for directing a test execution of the software testing project. For example, the mockup may describe a test flow for the test execution of the software testing project. In this case, the test flow may include steps for testing the one or more testable items.

In one embodiment, the mockup may be capable of being annotated with a status associated with the test execution (e.g. by the test executer, etc.). Additionally, in one embodiment, the mockup may be capable of being annotated with defect information associated with the test execution. In this case, the defect information may be viewable by a test group including a plurality of users such that the users may see where any issues have been reported.

In one embodiment, the defect information may be automatically reported to a quality center. Of course, any information associated with the test execution may be automatically reported to the quality center (e.g. information associated with the test cases, etc.).

Utilizing the method100, a mockup based test designer will be able to focus on presenting efficient information for design to a test executer, without the use of long descriptive sentences. The mockup based test executer will be able to have a clear view of the tests expected to be run, with additional clarity on the details of the test.

FIG. 2illustrates a flow diagram200for software testing project design and execution utilizing a mockup, in accordance with one embodiment. As an option, the flow diagram200may be implemented in the context of the details ofFIG. 1. Of course, however, the flow diagram200may be implemented in the context of any desired environment. Further, the aforementioned definitions may equally apply to the description below.

The flow diagram200shows a methodology for allowing a visual testing design and execution. This methodology shifts the focus in testing effort from long descriptions to an intuitive mockup based validation.

In operation, a dedicated visual oriented tool may be utilized to generate a design. See operation202. In this case, a test designer may create a mockup using a dedicated design mockup tool.

Utilizing the tool, the test designer is able to define testable items on the mockups. Moreover, reviewers have a clear mockup of the system showing tested flows on system lookalike screens, for intuitive and easy review.

Additionally, the tool may support test case generation in a quality center for tracking purposes. For example, the test designer may be able to automatically generate and link test cases to the testable items. See operation204. The text in the test cases will not be too detailed as execution may not be performed using these entities. The text may be used for tracking and counting purposes.

Further, test execution may be accomplished with a clear view. See operation206. For example, the tester running the execution (i.e. the test executer) may keep both the system and the testing flow side by side. The test executer may then test based on the mockup flow of testable items, marking any status on the testable items within the mockup.

Additionally, the link to the quality center may allow immediate update of the test cases. In this case, when facing defects, even out of the predefined testable items, the test executer can indicate where the defect is seen on the mockup so all other testers who reach the screen may see that the issue was reported.

Furthermore, the tool may support current reporting mechanisms. See operation208. For example, the use of quality center test cases and quality center defects allows any of the current reporting mechanisms to still be supported so communications to development and customer groups are not impacted.

FIG. 3illustrates a mockup300for software testing project design and execution, in accordance with one embodiment. As an option, the mockup300may be implemented in the context of the details of the previous figures. Of course, however, the mockup300may be implemented in the context of any desired environment. Further, the aforementioned definitions may equally apply to the description below.

The mockup300may be generated using a mockup generation tool, thus allowing a visual testing design and execution. As shown, the mockup300may identify a testing flow of testable items (e.g. see steps1-4).

As shown, mockup screens will always show more than the tested area (each testable item may be defined by a section of the screen). Thus, if something happens other than the planned test, the test executer will notice.

Furthermore, marking the exact place the defect occurred on the mockup will allow all who reach the same screen to see the open defects on it and their status.

In practice, utilizing the techniques and tools described herein to implement various test designs has shown a 28% reduction in overall test design effort and 32% reduction in test execution effort and test execution time.

FIG. 4illustrates a network architecture400, in accordance with one possible embodiment. As shown, at least one network402is provided. In the context of the present network architecture400, the network402may take any form including, but not limited to a telecommunications network, a local area network (LAN), a wireless network, a wide area network (WAN) such as the Internet, peer-to-peer network, cable network, etc. While only one network is shown, it should be understood that two or more similar or different networks402may be provided.

Coupled to the network402is a plurality of devices. For example, a server computer404and an end user computer406may be coupled to the network402for communication purposes. Such end user computer406may include a desktop computer, lap-top computer, and/or any other type of logic. Still yet, various other devices may be coupled to the network402including a personal digital assistant (PDA) device408, a mobile phone device410, a television412, etc.

FIG. 5illustrates an exemplary system500, in accordance with one embodiment. As an option, the system500may be implemented in the context of any of the devices of the network architecture400ofFIG. 4. Of course, the system500may be implemented in any desired environment.

As shown, a system500is provided including at least one central processor501which is connected to a communication bus502. The system500also includes main memory504[e.g. random access memory (RAM), etc.]. The system500also includes a graphics processor506and a display508.

The system500may also include a secondary storage510. The secondary storage510includes, for example, a hard disk drive and/or a removable storage drive, representing a floppy disk drive, a magnetic tape drive, a compact disk drive, etc. The removable storage drive reads from and/or writes to a removable storage unit in a well known manner.

Computer programs, or computer control logic algorithms, may be stored in the main memory504, the secondary storage510, and/or any other memory, for that matter. Such computer programs, when executed, enable the system500to perform various functions (as set forth above, for example). Memory504, storage510and/or any other storage are possible examples of tangible computer-readable media.