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.
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?
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:
- The desired functionality is defined in the form of tests.
- The tests run and fail.
- Only now is the actual functionality implemented. The tests are run again with each change.
- 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
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 existThe 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.
