Manual
 

TopTable of contentsNext Page: 30.4.2 Behavior-Driven Testing (BDT) from business perspectiveNext Chapter: 30.4.2 Behavior-Driven Testing (BDT) from business perspectiveChapter Overview: 30.4 Behavior-driven testing (BDT)PDF versionQF-Test
Version 8.0.1
Behavior-Driven Testing (BDT) from technical perspective

Describing a test case from a technical perspective using Behavior-Driven Testing (BDT) uses more or less elementary actions for designing a test case. You can find a sample test suite at qftest-8.0.1/demo/keywords/behaviordriven/BehaviorDrivenTesting.qft. The respective test-plan can be found at qftest-8.0.1/demo/keywords/behaviordriven/createvehicle.xlsx. Please take care to copy the demo folder to a project-related folder first and modify them there.

The "Create vehicle" test case looks like this if it's described in the BDT manner from a technical view:

  1. Given SUT is running
  2. Given vehicles dialog is opened
  3. When vehicle name is set to <name>
  4. And vehicle price is set to <price>
  5. And button new clicked
  6. And button ok clicked
  7. Then row with <name> and <formatted-price> appears in table
  8. And column model has value <name>
  9. And column price has value <formatted-price>

BDT requires to use the terms Given, When, And and Then at the beginning of any sentence. You will find more information about this approach in the testing literature.

QF-Test requires matching procedures for above test steps, so we need to build respective procedures again. It's an established method to divide the BDT-keywords in separate packages. The provided test suite therefore contains the packages Given, When_And and Then.

Figure 30.6:  Test suite Behavior-driven testing technical

The provided sample test suite contains all procedures in the respective packages, e.g. a procedure vehicles dialog opened inside the package Given. In order to prevent annoying typos a Server-script read test steps and fix typos formats any steps to lower case and tries to replace multiple blanks by one. This script is called directly before the procedure call of $(teststep).

In order to run the test case on multiple test data the sample was extended.

Of course you can apply the concept of generic component recognition as described in the previous section (see section 30.3). To that end you would need to specify a very exact description or implement a script filtering the target components from the test step itself.

TopTable of contentsNext Page: 30.4.2 Behavior-Driven Testing (BDT) from business perspectiveNext Chapter: 30.4.2 Behavior-Driven Testing (BDT) from business perspectiveChapter Overview: 30.4 Behavior-driven testing (BDT)PDF versionLast update: 9/10/2024
Copyright © 1999-2024 Quality First Software GmbH

We use "Matomo" cookies to anonymously evaluate your visit to our website. For this we need your consent, which is valid for twelve months. A revocation, so-called opt-out, is possible at any time on our privacy page.

ACCEPT
CONFIGURE
DECLINE
Cookie configuration

1. Functional cookies

We use functional cookies to ensure the basic functionality of the website.

2. Performance and statistic cookies

We use Matomo for analyzing and optimizing our website. Cookies permit an anonymous collection of information that help us offering you a clear and user-friendly visit of our web pages.

Confirm selection

Cookie details