Efficient exploratory testing with as much automation as possible. Have you ever felt the need to give your QA, business people as well as developers a mechanism to test your application(s) from the outside? Although you might have test automation in place, there is little visibility in the automated test suites that live somewhere in the CI server? Do you want to efficiently execute exploratory testing with as much automated help as possible?
Testery is a tool which allows you to exactly this. It enables business people as well as QA engineers to concentrate on the important stuff while doing exploratory testing instead of dealing with technical details.
- your business people can create test cases with the business abstractions they know
- the execution of the test cases is done automatically via automation created by developers
- the verification phase is optimized towards your QA & business people to quickly identify the correct outcome of a testcase
Testery can be used in two different scenarios: standalone or as a library in your customized testery-app.
The first option to use testery is by just running it as is without customizations. In this case you can follow the instructions in order to run the testery application. It has the following properties:
- testing scripts can be expressed as groovy scripts at runtime
- test step inputs are defined through the generic JSON input UI
- test step results are constrained by the existing result formats (JSON or Table)
In the second option, testery is used as an programming library in your customized testery-app. In this scenario, you have the possiblity to extend the generic limits of the standalone testery application by:
- testing scripts can be regular classes in your testery-app
- test step inputs can be a custom data model with full DB & custom UI support
- test step results can be any kind of data and UI
Below you can see the generic UI that is part of the standalone application of testery. Every screen can be customized in case of using testery as a library.
One option to define a teststep automation is to create a Testscript via the UI. The script is a groovy script. Within the groovy script it is possible to get access to the teststep input as well as a lot of Spring beans and variables, that allow several automation mechanisms.
In the sub directory example-testscripts there are a lot of examples on what is possible to do within a groovy testscript. One example of such a script is the HTTP communication with the API of the system that is under test:
class Person {
String name
}
def json = http.post{
request.uri = "http://httpbin.org/post"
request.contentType = 'application/json'
request.body = new Person(name: "Max Tester")
}
jsonResult(
summary: "worked",
expected: [name: "Max Testster"],
actual: json
)
The second option is only possible when testery is used as a library within a customized testery-app. In this case, the developer has to create a Spring bean and implement the Interface TeststepActionExecutor in the core module of the testery-app.
Example teststep class:
@Component
public class CreateCustomerTeststepExecutor implements TeststepActionExecutor {
@Inject
CustomerService customerService
@Override
void execute(Teststep teststep, TeststepInput teststepInput, TeststepResult teststepResult) {
Customer customer = customerService.createCustomer(teststep, teststepInput, teststepResult);
}
@Override
boolean supports(Testaction testaction) {
testaction.getCode() == "CREATE_CUSTOMER"
}
@Override
String getResultType() {
'testery$SingleValueTeststepResult'
}
}