Feature File Validation Tool

Figure 1 illustrates a system 100 for software development testing. As illustrated in Figure 1, system 100 may include one more device(s) 102, a network 106, a database 108, and a feature file validation tool 110. In particular embodiments, system 100 reduces the number of errors in computer software code. 

Device(s) 102 may be any devices that operate and/or communicate with other components of system 100. In general, device(s) 102request and receive processed data. For example, device(s) 102 may communicate a request to validate software code to feature file validation tool 110 or any other suitable component of system 100. In some embodiments, device(s) 102 may be associated with an enterprise or a business unit within an enterprise. 

This disclosure contemplates device(s) 102 being any appropriate device for sending and receiving communications over network 106. As an example and not by way of limitation, device(s) 102 may be a computer, a laptop, a wireless or cellular telephone, an electronic notebook, a personal digital assistant, a tablet, or any other device capable of receiving, processing, storing, and/or communicating information with other components of system 100. Device(s) 102 may also include a user interface, such as a display, a microphone, keypad, or other appropriate terminal equipment usable by user 104. In some embodiments, an application executed by device(s) 102 may perform the functions described herein. 

Network 106 facilitates communication between and amongst the various components of system 100. This disclosure contemplates network 106 being any suitable network operable to facilitate communication between the components of system 100. Network 106 may include any interconnecting system capable of transmitting audio, video, signals, data, messages, or any combination of the preceding. Network 106 may include all or a portion of a public switched telephone network (PSTN), a public or private data network, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a local, regional, or global communication or computer network, such as the internet, a wireline or wireless network, an enterprise intranet, or any other suitable communication link, including combinations thereof, operable to facilitate communication between the components. 

In some embodiments, system 100 includes database 108. System 100 may include a single database 108 or any number of databases 108. Databases 108 may store software code that is in the software development process cycle. In some embodiments, database 108storestest casecase files for testing features of the software code. This disclosure does not limit the databases 108 to storing only software code and test casecase files. This disclosure contemplates databases 108 storing any suitable data type. For example, databases 108 may store any type of data to be processed. 

Feature file validation tool 110 generates test case details files for testing the functionality of software code stored in database 108. As illustrated in Figure 1, feature file validation tool 110 includes a processor(s) 110 and a memory 112. This disclosure contemplates processor(s) 110 and memory 112 being configured to perform any of the operations of feature file validation tool 110 described herein. In particular embodiments, feature file validation tool 110 reduces the number of errors in computer software code. 

Processor(s) 110 is any electronic circuitry, including, but not limited to microprocessors, application specific integrated circuits (ASIC), application specific instruction set processor (ASIP), and/or state machines, that communicatively couples to memory 112 and controls the operation of feature file validation tool 110. Processor(s) 110 may be 8-bit, 16-bit, 32-bit, 64-bit or of any other suitable architecture. Processor(s) 110 may include an arithmetic logic unit (ALU) for performing arithmetic and logic operations, processor registers that supply operands to the ALU and store the results of ALU operations, and a control unit that fetches instructions from memory 112 and executes them by directing the coordinated operations of the ALU, registers and other components. Processor(s) 110 may include other hardware and software that operates to control and process information. Processor(s) 110 executes software stored on memory 112 to perform any of the functions described herein. Processor(s) 110 controls the operation and administration of feature file validation tool 110 by processinginformation received from network 106, device(s) 102, and memory 112. Processor(s) 110 may be a programmable logic device, a microcontroller, a microprocessor, any suitable processing device, or any suitable combination of the preceding. Processor(s) 110 is not limited to a single processing device and may encompass multiple processing devices. 

Memory 112 may store, either permanently or temporarily, data, operational software, or other information for processor(s) 110. Memory 112 may include any one or a combination of volatile or non-volatile local or remote devices suitable for storing information. For example, memory 112 may include random access memory (RAM), read only memory (ROM), magnetic storage devices, optical storage devices, or any other suitable information storage device or a combination of these devices. The software represents any suitable set of instructions, logic, or code embodied in a computer-readable storage medium. For example, the software may be embodied in memory 112, a disk, a CD, or a flash drive. In particular embodiments, the software may include an application executable by processor(s) 110 to perform one or more of the functions described herein. In some embodiments, memory 112stores a step definition file 114. Step definition file 114 generally includes a catalog of predetermine valid steps, as discussed in more detail in relation to feature file validation tool 110. This disclosure contemplates memory 112 storing any of the elements stored in databases 108 and/or by feature file validation tool 110. 

In an exemplary embodiment, feature file validation tool 110 receives a request 116. In some embodiments, request 116 is a request to configure a test case file(s) 124. As previously discussed, test case file(s) 124 may include one or more tests for determining whether a functionality of a computer software application is functioning properly. In some embodiments, a test includes a plurality of steps, as previously discussed. In some embodiments, test case file(s) 124 is an XML file written in gherkin language. Test case file(s) 124 may not be compatible with certain software tools. For example, test case file(s) 124 may not include fields required for one or more software tools. Request 116 may be a request to configure test case file(s) 124 to include information required to utilize one or more software tools with test case file(s) 124. In some embodiments, user 104 uses device(s) 102 to generate request 116. User 104 may utilize a graphical user interface to enter information to generate request 116. In some embodiments, the graphical user interface is included in a standalone tool that is system agnostic. In some embodiments, the standalone is designed in a generic way that may be used on a plurality of projects and a plurality of test case file(s) 124. 

Feature file validation tool 110 may analyze request 116 to determine a test case file(s) 124, field name(s) 118, and field value(s) 120. In some embodiments, request 116 may include a description of test case file(s) 124. Feature file validation tool 110 may retrieve test case file(s) 124 from database 108. Field name(s) 118 generally facilitates identifying test case file(s) 124 and/or information within test case file(s) 124. For example, field name(s) 118 may include an application field name(s) 118, a project field name(s) 118, a type field name(s) 118, and/or test field name(s) 118. In some embodiments, each field name(s) 118 corresponds to a field value(s) 120. Field value(s) 120 generally provides information for test case file(s) 124. For example, field value(s) 120 may include the name of the application that test case file(s) 124 is testing (corresponding to application field name(s) 118), a project field value(s) 120 (corresponding to project namefield 120), and any other suitable field value(s) 120 that corresponds to a field name(s) 118. In some embodiments, test case file(s) 124 may not include field name(s) 118 and/or field value(s) 120. In some embodiments, test case file(s) 124 must include field name(s) 118 and/or field value(s) 120 to be compatible with certain software tools. 

In some embodiments, feature file validation tool 110 generates first test case details file 122 using test case file(s) 124, field name(s) 118, and field value(s) 120. For example, feature file validation tool 110 may transform test case file(s) 124 to include field name(s) 118 and their corresponding field value(s) 120. Field name(s) 118 and field value(s) 120 may apply to test case file(s) 124 as a whole, to one or more tests within test case file(s) 124, and/or to one or more steps of the one or more tests within test case file(s) 124. 

In some embodiments, feature file validation tool 110 performs validation 126 on first test case details file 122. Validation 126 may determine whether first test case details file 122 includes computer language errors. In some embodiments, first test case details file 122 includes gherkin language. Gherkin computer language, as with any computer language, requires that code be written in a particular format. Feature file validation tool 110 may determine that first test case details file 122complies with gherkin language formatting. For example, feature file validation tool 110 may apply computer language rules to first test case details file 122. Computer language rules may be rules that include requirements of the computer language. As another example, feature file validation tool 110 may determine whether first test case details file 122 includes errors such as typos. This disclosure contemplates first test case details file 122 written in any suitable computer language and feature file validation tool 110 determining whether first test case details file 122conforms to requirements for the computer language. 

Feature file validation tool 110 may validate steps in first test case details file 122. As previously discussed, first test case details file 122 may include a plurality of tests to determine whether a software application is functioning properly given certain inputs and/or commands. Each test may include a plurality of steps. For example, a test may determine whether a calculator functionality for a software application is functioning properly. A step may include a command to launch the calculator functionality of the software application. Another step may provide inputs to the calculator software application. For example, the inputs may be 1 and 2. A step may include a command to multiply the inputs. A test may include an expected output. In this example, the expected output may be 2. In some embodiments, a test facilitates determining whether a software application is functioning properly by comparing an output of the software application to an expected output. In some embodiments, a software tool may accept only predefined steps. These predefined steps may be stored in step definition file 114. Step definition file 114 includes a catalog of predetermined valid steps, in some embodiments. Feature file validation tool 110 may compare steps in first test case details file 122 to predetermined steps to perform validation 126. 

Feature file validation tool 110 completes transformation 128 to transform first test case details file 122 to second test case details file 130, in some embodiments. As discussed, a software development and testing team may utilize a plurality of software tools to facilitate testing software application features in a design phase of a software application. For example, a software development and testing team may use a first software tool to generate and execute test case files. As another example, a software development and testing team may utilize a second software tool to manage the development lifecycle process. In this example, the second software tool may store a summary of errors identified by executing test case files. As another example, the second software tool may store information for development progress and/or any other software application development cycle management information. Two of more of the software tools may require test case file(s) 124 to be in a different format. First test case details file 122 may be compatible with a first software tool. For example, first test case details file 122 may be in an XML format. Second test case details file 130 may be compatible with a second software tool. For example, second test case details file 130 may be in an excel format. 

In some embodiments, feature file validation tool 110 generates test identification (“IDs”) 134 for the second test case details file 130. In some embodiments, a test ID(s) 132 may identify a test in second test case details file 130. In some embodiments, test ID(s) 132 may identify a step of a test in second test case details 132. Test ID(s) 132 may include an alphabetical indicator, a numerical indicator, a special character indicator, and/or any other suitable type of indicator. Feature file validation tool 110 may revise second test case details file 130 to include test ID(s) 132. A software development and test team may utilize test ID(s) 132 to uniquely identify a test and/or a step within, e.g., second test case details file 130. As discussed in more detail below, test ID(s) 132 may facilitate linking first test case details file 122 and second test case details file 130. 

In some embodiments, feature file validation tool 110 completes synchronization 134 using first test case details file 122 and test ID(s) 132. A test case ID 134 is a unique identifier for a test and/or a step. As discussed, first test case details file 122 and second test case details file 130 may include the same or substantially the same tests and steps. Thus, if a test and/or a step in second test case details file 130 receives a test ID(s) 132, feature file validation tool 110 revises first test case details file 122 so that the corresponding test and/or step in first test case details file 122 receives the same or substantially the same test ID(s) 132. This allows tests and/or steps in first test case details file 122 and second test case details file 130 to be linked. This facilitates the software development cycle by allowing information for a test and/or step to be updated between test case details file. 

Modifications, additions, or omissions may be made to system 100 without departing from the scope of the invention. For example, system 100 may include any number of processor(s) 110, memory 112, device(s) 102, and/or databases 108. While discussed as generating first test case details file 122 and second test case details file 130, this disclosure contemplates generating any suitable number of test case details files. Furthermore, the components of system 100 may be integrated or separated. For example, in particular implementations, memory 112 may be separated into multiple memory 112 to store the data descried herein. 

Figure 2 illustrates the feature file validation tool 110 of the system 100 of Figure 1. As illustrated in Figure 2, feature file validation tool 110 includes a retrieval engine 202, a configuration engine 204, a validation engine 206, a transformation engine 208, and a synchronization engine 210. In particular embodiments, feature file validation tool 110 reduces errors in computer software by facilitating software application feature testing. 

Retrieval engine 202 receives request 116 and test case file(s) 124, in some embodiments. In particular embodiments, retrieval engine 202 receives request 116 from one or more device(s) 102. For example, user 104 may generate request 116 using a graphical user interface of device(s) 102. In some embodiments, request 116 is a request to configure test case file(s) 124. As previously, discussed, test case file(s) 124 may include a plurality of tests and each test may include a plurality of steps. In some embodiments, each test determines whether a functionality of a software application is operating properly. In some embodiments, retrieval engine 202 receives test case file(s) 124 from database 108. An example algorithm for retrieval engine 200 is as follows: wait for request 116; receive request 116 from one or more device(s) 102; in response to receiving request 116, retrieve test case file(s) 124 from database 108; receive test case file(s) 124; and communicate request 116 and test case file(s) 124 to configuration engine 204. 

Configuration engine 204 determines field name(s) 118 and field value(s) 120 and generates first test case details file 122 using test case file(s) 124, field name(s) 118, and field value(s) 120, in some embodiments. Configuration engine 204 may extract field name(s) 118 and field value(s) 120 from request 116 in some embodiments. In some embodiments field names 122 include an application field name(s) 118 and a project field name 122. In this example, field value(s) 120 may include a field value(s) 120 for the application field name that indicates the software application being tested. Field value(s) 120 may include a field value(s) 120 for the project field name that indicates a software development project. User 104 may enter field name(s) 118 and field value(s) 120 using a graphical user interface of device(s) 102. Configuration engine 204 may use field name(s) 118 and field value(s) 120 to generate first test case details file 122. In some embodiments, configuration engine 204 revises test case file(s) 124 to include field name(s) 118 and field value(s) 120 to generate test case details file 124. Configuration engine 204 may communicate first test case details file 122 to validation engine 206, transformation engine 208, and/or synchronization engine 210. An example algorithm for configuration engine 204 generating first test case details file 122 is as follows: receive request 116  test case file(s) 124; analyze request 116 to determinefield name(s) 118 and field value(s) 120; generate first test case details file 122 using test case file(s) 124, field name(s) 118, and field value(s) 120; and communicate first test case details file 122 to validation engine 206. 

Validation engine 206performs validation 126, in some embodiments. As previously discussed, validation 126 may include a two-part validation. For example, validation 126 may determine whether the computer language of test case file(s) 124conforms to the rules associated with the computer language. In this example, feature validation engine 206 may apply computer language rules to all or a part of first test case details file 122 to determine whether it conforms to the computer language. Computer language rules may include rules for the computer language requirements. As another example, validation engine 206 determines whether each step in the first test case details file 122 is valid by comparing the steps to one or more steps in step definition file 114. Step definition file 114 may include a catalog of predetermine valid steps. Validation engine 206 may retrieve step definition file 114 from database 108, memory 112, and/or any other suitable component of system 100. In some embodiments, database 108 communicates step definition file 114 to feature file validation tool 110 where it is stored in memory 112. In some embodiments, user 104 generates step definition file 114. If validation engine 206 determines that first test case details file 122 does not conform to computer language rules and/or that a step is not valid, validation engine 206 may generate a warning to user 104, in some embodiments. An example algorithm for validation engine 206 to perform validation 126 is as follows: receive first test case details file 122 from configuration engine 204; determine whether computer language in first test case details file 122conforms to rules for the computer language; and determine whether each step in first test case details file 122 is valid. 

Transformation engine 208performstransformation 128 to generate second test case details file 130 in some embodiments. Transformation engine 208 may transform first test case details file 122 from a first file format to a second file format to perform transformation 128. In some embodiments, second test case details file 130 includes the plurality of tests, the plurality of field name(s) 118, and the plurality of field value(s) 120 from first test case details file 122. In some embodiments, first test case details file 122 is an XML file format and transformation engine 208performstransformation 128 to generate second test case details file 130 in an excel file format. An example algorithm for transformation engine 208 to perform transformation 128 to generate second test case details file 130 is as follows: receive first test case details file 122; perform transformation 128 to generate first test case details file 122 to second test case details file 130; communicate second test case details file 130 to synchronization engine 210. 

Synchronization engine 210 generates test ID(s) 132 for each of the one or more of the tests and/or steps in second test case details file 130and performs synchronization 134, in some embodiments. As previously discussed, test ID(s) 132 are unique identifiers for a test and/or step in second test case details file 130. Synchronization engine 210 may perform synchronization 134 in some embodiments. For example, synchronization engine 210 may revise first test case details file 122 to include test ID(s) 132. In some embodiments, first test case details file 122 and/or second test case details file 130 include the same or substantially the same tests and/or steps. If a test and/or a step in second test case details file 130 is linked to a test ID(s) 132, synchronization engine 210 revises first test case details file 122 such that the corresponding test and/or step in first test case details file 122 is linked to the same test ID(s) 132, in some embodiments. An example algorithm for synchronization engine 210 is as follows: receive second test case details file 130; generate test ID(s) 132 for tests and/or steps in second test case details file 130; perform synchronization 134 to revise first test case details file 122 to include test ID(s) 132. 

Modifications, additions, or omissions may be made to feature file validation tool 110 without departing from the scope of the invention. For example, while discussed as retrieval engine 202 receiving a single test case file(s) 124, retrieval engine 202 may receive any number of test case file(s) 124. Feature file validation tool 110 may generate a single first test case details file 122 from a plurality of test case file(s) 124. As another example, feature file validation tool 110 may generate a first test case details file 122 for each received test case file(s) 124. In some embodiments, user 104 may instruct feature file validation tool 110 to determine a single first test case details file 122 from a plurality of test case file(s) 124 using a graphical user interface of device(s) 102. As another example, validation engine 206 may perform validation 126 on test case file(s) 124, first test case details file 122, and/or second test case details file 130. 

Figure 3 is a flowchart illustrating an examplemethod 300 for software development testing and management using the system of Figure 1. In particular embodiments, feature file validation tool 110 performs  method 300. By performing method 300, feature file validation tool 110 reduces the number of errors in computer software application development. 

In some embodiments, feature file validation tool 110 begins by receiving request 116 to configure test case file(s) 124 in step 302. In step 304, feature file validation tool 110 may retrieve test case file(s) 124 in response to request 116. Feature file validation tool 110 receives field name(s) 118 and field value(s) 120 in step 306, in some embodiments. For example, feature file validation tool 110 may extract field name(s) 118 and/or field value(s) 120 from request 116. Feature file validation tool 110 generates first test case details file 122 using test case file(s) 124, field name(s) 118, and field value(s) 120 in step 308, in some embodiments. 

Feature file validation tool 110 may determine whether the steps in first test case details file 122conform with step rules in step 310. For example, feature file validation tool 110 may compare each step in first test case details file 122 to a catalog of predetermined valid steps. If the steps do not conform to predetermined valid steps in step 310, feature file validation tool 110 may generate a warning in step 312 before returning to step 310. If the steps do conform to predetermined valid steps in step 310, the method proceeds to step 314 where feature file validation tool 110 determines whether the computer language in first test case details file 122conforms to a computer language by applying computer language rules. If the computer language does not conform, the method proceeds to step 316 where feature file validation tool 110 generates a warning before proceeding to step 314, in some embodiments. 

If the computer language does conform, the method proceeds to step 318 where feature file validation tool 110 generates second test case details file 130, in some embodiments. Feature file validation tool 110 may generate test ID(s) 132 at step 320 and perform synchronization 134 at step 322. For example, feature file validation tool 110 may transform first test case details file 122 to include test ID(s) 132 as previously discussed. 

Modifications, additions, or omissions may be made to method 300 depicted in Figure 3. Method 300 may include more, fewer, or other steps. For example, steps may be performed in parallel or in any suitable order. While discussed as feature file validation tool 110 performing the steps, any suitable component of system 100, such as device(s) 102 for example, may perform one or more steps of the method. 

Herein, a computer-readable non-transitory storage medium or media may include one or more semiconductor-based or other integrated circuits (ICs) (such, as for example, field-programmable gate arrays (FPGAs) or application-specific ICs (ASICs)), hard disk drives (HDDs), hybrid hard drives (HHDs), optical discs, optical disc drives (ODDS), magneto-optical discs, magneto-optical drives, floppy diskettes, floppy disk drives (FDDs), magnetic tapes, solid-state drives (SSDs), RAM-drives, SECURE DIGITAL cards or drives, any other suitable computer-readable non-transitory storage media, or any suitable combination of two or more of these, where appropriate. A computer-readable non-transitory storage medium may be volatile, non-volatile, or a combination of volatile and non-volatile, where appropriate. 

Herein, “or” is inclusive and not exclusive, unless expressly indicated otherwise or indicated otherwise by context. Therefore, herein, “A or B” means “A, B, or both,” unless expressly indicated otherwise or indicated otherwise by context. Moreover, “and” is both joint and several, unless expressly indicated otherwise or indicated otherwise by context. Therefore, herein, “A and B” means “A and B, jointly or severally,” unless expressly indicated otherwise or indicated otherwise by context.