---

When trying to automate Acceptance tests which were written by a tester in natural language, the following should be done:

• First, code should be written to execute each step in the test scenario
• Second, code should be written to bind the test scenario written in natural language and the code that executes it.

Of course, someone has to write all these mentioned codes. This someone should have a good programming knowledge and experience.
So to automate your tests -as a business owner- you should hire a senior tester who can write these codes and pay him a lot of money, or you can assign this task to one of your developers and bother him with this extra code that he should take care of beside his original task which is developing the functionalities of the system (This also includes extra money  being paid).

In Testicide, we tried to solve this problem by providing a Toolbox which contains steps that you will drag and drop to form your test scenario. You will not have to code anything to run your test.

In ATDD test scenarios, you specify some actions to be done on some controls to see the result on other controls.
As Testicide is designed to test web applications, these actions, controls and results will be in HTML format.
By inspecting common html input and output controls we could define the most popular events of different input and output controls and form a dictionary of them.

Examples for the events on input controls:

• Click on a button
• Click on a link
• Fill in a text field or textarea
• Choose one of radio buttons options
• Check some checkboxes
• Choose an option from a drop down list

And the expected output will be seen as following:

• Redirect to another page
• Display a message on the same page

Using the dictionary we formed, we were able to write all the code needed in advance and provide the human readable form of these steps to the tester in the toolbox. For example, the tester drags and drops the step (Click on the button ‘value’) into his scenario then he will modify the ‘value’ to the text displayed on the button. He could also change this so that the value will represent the id or the class of the button or any other attribute that he will specify.

Furthermore, there are common scenarios that are executed in every single web application by the same way. By examining different web applications, we could define these well-known scenarios, form a dictionary of them and add them directly to the toolbox.
For example the Login scenario is one of the most well-known scenarios to be executed in every web application where the user writes in the username and password text fields then click the Login button, the user should be redirected to a page that will display his name in some part of it like “Hello Admin!”. This scenario was added to the toolbox as one step as following:
Login with username ‘value’ and password ‘value’