Test AutomationMethods

Use test automation in the project

Those who automate chaos get automated chaos. So that it doesn't get that far, it is important to consider the use of tools and pipelines in the context of the projects. How do requirements develop into good, automated test cases?

Icon
Test-Driven Development

Test-Driven Development (TDD) is a method that is particularly suitable for unit tests. Instead of starting by implementing a solution and then testing it, this approach is reversed.

Icon
Behaviour-Driven Development

Behavior-Driven Development (BDD) is an agile software development approach that revolves around collaboration in a team and the guidance of development work through executable and easily understandable specifications.

Contact

Test-Driven Development

Test-Driven Development (TDD) is a method that is particularly suitable for unit tests. Instead of starting by implementing a solution and then testing it, this approach is reversed:

  1. The desired functionality is defined in the form of tests.
  2. The tests run and fail.
  3. Only now is the actual functionality implemented. The tests are run again with each change.
  4. The implementation ends as soon as all tests have been passed successfully.

This approach can work very well in reality if the developers are supported by experienced staff when implementing the tests. Otherwise there is a risk that only “good” test cases will be created and marginal cases will not be considered.

Do you need test know-how in your project in order to introduce or implement TDD? Then don't hesitate and contact us!

Behaviour-Driven development stellt die Anforderungen der Anwender in leicht verständlicher Sprache in den Vordergrund

Behaviour-Driven Development

At its core, Behavior-Driven Development (BDD) is an agile software development approach that emerged from the test-driven development approach, but adds an important aspect to it. Everything revolves around the collaboration in the team and the guidance of the development work through executable and easily understandable specifications.

To put it more simply, at BDD, at the beginning of a development cycle, there is always the joint analysis of requirements in the entire team. In order to build a collective understanding of which feature should be developed next, the collection and formulation of short, focused scenarios from the user's point of view is dedicated to. Gradually, all the criteria of a feature requirement are described on the basis of understandable application examples and this is recorded in a so-called "feature file" in formalized syntax.

In a simplified example it can look like this:

Feature: Delete User Account
As a customer of the onlineshop
I want to be able to delete my user account
in order to have full control over my data

Background:
Given "Larissa" is a registered customer
And "Larissa" is logged in

Scenario: Account deletion successful
When "Larissa" requests an account deletion
And "Larissa" confirms the deletion
Then "Larissa" should be logged out automatically
And account data for "Larissa" should be deleted

Scenario: Account deletion canceled
When "Larissa" requests an account deletion
But "Larissa" does not confirm the deletion
Then "Larissa" should still be logged in
And account data for "Larissa" should still exist

The advantage here is that the feature specifications are described in a non-technical, natural language in order to be understandable not only for developers, but also for the entire team and stakeholders.

Finally, test code is written for each step to prepare the feature file for execution. Developers then have a clearly described document at hand that they can execute as often as they want during the development phase in order to check whether the application code developed meets the requirements.

Test data and project environment

In addition to the pure execution of the tests using tools, two subject areas must be considered:

  • The project environment: which quality goals are to be achieved and how? How much time and budget is available? Which development model (waterfall, Scrum) is used? Are the necessary infrastructures in place?
  • Test data: Without suitable test data, the best test automation solution is often useless. Is the data available in the correct format at the right time? Does the data have to be anonymized if necessary? Can the test data be changed by automation?

It would be annoying if a real order was placed in the shipping department as part of the tests in a web shop.

Any questions?

We are happy to provide you with know-how, specific support services and associated license and support offers.

Background Image Mobile Version