Backeround to the Invention

[0001] This invention relates to a method of testing a web-based process, such as a web page function located on the World Wide Web or on a server only accessible by a defined network.

[0002] A web page can be designed by a traditional, linear Waterfall model, or by a more adaptable model. In either case, a non-technical user will wish to test the functionality. Conventionally, the user provides a natural language document, describing one or more functions that the web page is to perform, to a test engineer. The engineer writes a script which is used to test the application.

[0003] A problem with existing scripts defining automated processes for testing functionality is that their meaning is not apparent to users unfamiliar with the language of the script.

[0004] This problem has been addressed by the providers of the Cucumber ® testing tool, which runs automated acceptance tests written in a behavior-driven development (BDD) style. A user can specify a behaviour to be tested using a plain language parser called Gherkin, which is readable by persons unfamiliar with programming languages.

[0005] Whilst Gherkin allows a user to specify a test in standard manner, it still requires a human test engineer to interpret the Gherkin specification, and write a script for Cucumber, which uses the Ruby programming language, this script again being unintelligible to the lay user.

[0006] If a "record and play" approach is used, a script for testing a web-based application is recorded and run, and the results of the test are played to the lay user. However, since the user does not read the script, he or she cannot verify the exact nature of the test. [0007] Figure 1 is a flow chart showing a typical web page development process. After specifying its requirements, the user, which may be a business, submits these to a developer, who develops an initial version of the page. At the same time, a test engineer writes and records a test script, and a user acceptance test (UAT) script, used for a second, manual level of testing, is also written and recorded.

[0008] The developer codes the page, using, for example, html (hypertext mark up language), and submits the code to the test engineer, who adds elements of the code, such as path expressions for html objects, and test data, to the test script. The test script is run, and if errors are found, the developer corrects them and the test script is re-run. Finally the UAT script is followed, possibly by the lay user, as a final check for errors.

Summary of the Invention

[0009] One aspect of the present invention provides an automated method of testing a web-based process, comprising the steps of:

- receiving a set of instructions from a human, the instructions comprising: a plurality of natural language operational tags, each defining an operation to be performed; and a plurality of natural language objects, each defining an element of a document presented for interaction, each operational tag being associated with one of the objects;

- extracting said operational tags and said objects from the instructions;

- performing the operations defined by the operational tags on the elements defined by the objects that are respectively associated with the operational tags, and

returning a result of at least one of the operations defined by the operational tags. [0010] The operations defined by the natural language operational tags may include one or more of: navigating, selecting, actuating (e.g. by simulating clicking a mouse button), or verifying the presence of a document element.

[0011] The elements defined by the objects may include one or more of: an address of a document, which may be a web page; a hyperlink; a button; a text input box; data generated by the operation defined by the operational tag associated with the object in question; or data generated by a previous operation.

[0012] The document may by a web page, for example available on the World Wide Web.

[0013] The instructions may include test data, for entry into the document, and/or comprising an expected result of an operation. The test data may be presented as one or more data tags within the set of instructions, a test data file being provided to interpret the one or more data tags.

[0014] A second aspect of the invention provides a computer program including: a plurality of natural language operational tags, each defining an operation to be performed; and a plurality of natural language objects, each defining an element of a document presented for interaction, each operational tag being associated with one of the objects; such that when the operations defined by the operational tags are performed on the elements defined by the objects that are respectively associated with the operational tags, a result of at least one of the operations defined by the operational tags is returned.

[0015] The program may include test data, for entry into the document, and/ or comprising an expected result of an operation. The test data may be presented as one or more data tags, the program also including a test data file providing definitions of the one or more data tags.

[0016] A third aspect of the invention provides a method of developing and testing a web-based process, comprising the steps of: - receiving at least one set of instructions from a human, the instructions comprising: a plurality of natural language operational tags, each defining an operation to be performed; and a plurality of natural language objects, each defining an element of a document to be presented for interaction, each operational tag being associated with one of the objects;

- creating the web-based process including the operations to be performed and the document to be presented;

- creating an object repository file, containing the objects with their associated elements of the document;

- causing an engine to execute the at least one set of instructions directly by: extracting said operational tags and said objects from the instructions, retrieving the defined operation for each operational tag from the memory, retrieving the defined document element for each object from the object repository file, and performing the operations in the at least one set of instructions on the respective associated objects, and returning a result of at least one of the operations defined by the operational tags.

[0017] A fourth aspect of the invention provides an automated method of testing a web-based process, comprising the steps of:

- receiving a set of instructions, the instructions comprising: a plurality of natural language operational tags, each defining an operation to be performed; and a plurality of natural language objects, each defining an element of a document presented for interaction, each operational tag being associated with one of the objects;

- extracting said operational tags and said objects from the instructions; - performing the operations defined by the operational tags on the elements defined by the objects that are respectively associated with the operational tags, and

- returning a result of at least one of the operations defined by the operational tags.

[0018] In the third and fourth aspects of the invention, the operations, elements and test data may be as described above.

Brief Description of the Drawings

[0019] The invention will be described in more detail, by way of example only, with reference to the accompanying drawings, in which;

[0020] Figure 1 shows the known method of developing web pages described above;

[0021] Figure 2 shows a method of developing web pages according to an embodiment of the invention; and

[0022] Figure 3 shows the development and testing in more detail.

Detailed Description of Preferred Embodiments

[0023] The invention provides a natural language instruction set for a non technical user to specify procedures that a web based process must perform.

[0024] The instruction set includes operational tags that define commands or operations, and objects that define elements of a web page, such as its URL (universal resource locator), buttons, hyperlinks, data entry fields, and data generated or located by an operation. Each operational tag is followed by an object on which the operation is to be performed.

[0025] Examples given below show how a web site providing a database of companies could be developed and tested. An first example of a script that could be written by a non-technical user is: Scenario: Start finding a registered company from company website

ScenariolterationCount: 1

Given User @navigate _websiteURL as <companyhouseurl>

When user @clicks button _FindCompanylnformation

And user @clicks button _StartNow

Then user @verifies search box _CompanyName available to key in company name

EndFeature

[0026] In the examples presented, a word preceded by "@" is an operational tag, a word preceded by an underscore is an object, and a word between pointy brackets is a data tag. Thus "@navigate _websiteURL as <companyhouseurl> " is a command to navigate, by entering into a URL field of a browser, an certain URL, which is identified here as "<companyhouseurl>". The actual URL can be defined in a separate test data file.

[0027] After having navigated to the page in question, the script commands clicking a button "_FindCompanyInformation" followed by clicking a further button "_StartNow". Finally there is a verification step that a search box "_CompanyName" is available.

[0028] Note that the words in the script other than the operational tags, objects and data tags are for information and are not read when the script is run.

[0029] A developer creates a web-based process, in this case a web page, to embody the document elements and perform the operations defined by each of the objects and operational tags respectively. The objects are stored in an object repository file provided by the developer, to allow the engine (described below) to locate the objects within an html document. This file is updated after implementing each scenario. Such a file for the exemplary scenarios above, using the XPath syntax, could appear as follows:

FindCompanylnformation=//a[text()="Find company information"]

StartNow=//a[@class="gem-c-button govuk-button govuk-button-start"] CompanyName=//input[@id="site-search-text"]

SearchForCompany=//button[@id="search-submit"]

Com pa n iesRetu rned=//*

CompanylD=//*[@id="results"]//*

BusinessAddress=//*[@id="results"]//*

CompaniesReturnedlist=//*[@id="results"]//li//h3//a

[0030] The example could continue by presenting further scenarios:

Scenario: Check when company name entered and searched, a list or no list is returned ScenariolterationCount:2

When user @clears text box _CompanyName data

And user @enters _CompanyName as <companyNameToSearch>

And user @clicks _SearchForCompany button

Then workflow @verifiesbytext _CompaniesReturned from the returned results <companyListReturned>

EndFeature

Scenario: Check when a valid list is returned the exact company is found in the list ScenariolterationCount:3

When user @clears _CompanyName data

And user @enters _CompanyName as <companyNameToSearch>

And user @clicks _SearchForCompany

Then workflow @verifiesbytext from _CompaniesReturnedlist if <companyName> available in the result list

And workflow @verifiesbyexactext _CompanylD as <companylD> in the same list

And workflow @verifiesbyexacttext _BusinessAddress as <businessAddress> in the same list

End Feature [0031] The second scenario above specifies that a search for a company name will return data, provided that company name exists in the database. The third scenario specifies that if the exact company name searched for exists, it is returned together with the address of the company.

[0032] Test data is specified for the data tags in the test scenarios. For the above examples, the test data could be stored as follows:

#StartOFScenario1 = -

Scenario1_companyhouseurl =

htps://www.qov.uk/aovernment/oraanisations/companies-hous e:

#StartOFScenario2 = -

Scenario2_companyNameToSearch = Q-WAY LTD;QWays;

Scenario2_companyListReturned = Q-WAY LTD;No results found for "QWays";

#StartOFScenario3 = -

Scenario3_companyNameToSearch = Q-Way LTD;Q-Way LTS;Q-Way LTD;

Scenario3_companyName = Q-WAY LTD;Q-WAY LTS;Q-WAY LTD;

Scenario3_companylD = 11588232;11588233;11588232;

Scenario3_businessAddress = 4th Floor Radius House, 51 Clarendon

Road, Watford, Hertfordshire, England, WD17 1HP;;4th Floor Radius House, 51 Clarendon Road, Watford, Hertfordshire, England, WD17 1H0;4th Floor Radius House, 51 Clarendon Road, Watford, Hertfordshire, England, WD17 1HP;

[0033] The invention provides an engine that can parse each script and perform the test desired by the user. Returning to the example above, the engine causes a browser to open the page at the URL identified by <companyhouseurl>. Next, the engine simulates mouse clicks on the buttons "_FindCompanyInformation" and "_StartNow". Finally the engine verifies that a search box is made available for typing a company name for which the user wishes to search.

[0034] Using this test data, if a search is performed for the company "Q-Way Ltd" which is known to exist in the database, the test will confirm whether or not details relating to that company are retrieved. The correct expected results are provided in the test data file by the data tags "companyname" "companylD" and "business Address". Of course, the same scripted scenarios could be used with a different test data file to test different search criteria. Referring to scenario 1, using a different definition for the data tag "<companyhouseurl>", the test could be run on a different web page.

[0035] Figure 2 shows how the invention is performed as part of the development of a web-based process. Comparing this with Figure 1, it will be seen that the test engineer is no longer required. The non-technical user composes one or more scripts of the type exemplified above, runs them directly on the engine of the invention and receives the results. The invention therefore provides faster and more efficient testing of web-based processes.