Business Driven Development (BDD) with Living Documentation

Most of you are working in Tech industry, you know that there is a gap between business and tech people. Why? It’s another story and a huge post.
The question is what we can do to connect those two worlds? As we discussed on a previous post, you can use 🍺 beer to do it but it not so efficient for your health.

BDD(Behavior Driven Development) is a process of requirement documenting, gathering and analysis. In simple words, business people write clear requirements in a specific way and those cases translated to code that executes automated tests.

The structure of those Feature files has main syntax of Given, When, Then:
1. Given is for the initial state.
2. When is for the actions take place.
3. Then is for the expected outcome.

Example of a Feature file:

Feature: Calculator
Simple calculator for adding **two** numbers

@Add
Scenario: Add two numbers
	Given the first number is 50
	And the second number is 70
	When the two numbers are added
	Then the result should be 120

Simple enough? So think about this is a documentation for a feature of our application, right?

With BDD you can execute your tests cases that you write based on this feature files and see the results to the pipeline.
To give you a little bit more context , each step is an executable code that do a setup/action/assertion behind the scenes as the scenario describes but this is another post also.

What if we can have feature files combined with test results in a report?

And guess what, you can have it with SpecFlow and Living doc extension. ( Cucumber has also a library called Cukedoctor )

What is Specflow? Specflow is a .NET BDD framework that allow us to integrate BDD style and tools on .NET related solutions. Its kind of the same to Cucumber that is more popular on BDD world but lets dive to the example itself.

Imagine that you have a .NET core api project and you want to write API test cases to cover the business cases.
You ask for the business people to write the feature files, then you implement the test cases but the business people take only an execution report as a result.

This is ok if you are starting now your BDD journey but you can enhance it by creating a living doc. How this living doc would look like?

Pretty cool, right? You have all the information you needed ( Feature, Scenario, Steps, Tags ) on a report connected with test case execution results in each step!

You can also add some images to your feature files and those will appear to report ( e.g mockups, designs etc )!

Lets see how we can implement that.
First of all we need to read the documentation . Don’t skip this step!
Then we need to add the extension to our Azure DevOps instance and see this tab:

Next is to configure our pipeline to collect the execution results and generate the report by adding the SpecFlow step :

After running the pipeline you should check the pipeline results and to Specflow & Living Doc tab you should see the HTML report that you can export it.
With this report you can always share the status of current feature coverage with test cases and do closer connection between business and tech.

NOTE that you can use it on whatever tests you need e.g Integration, API , E2E etc.
The structure will be the same and here is the Calculator example:

Feature: Calculator
![Calculator](https://specflow.org/wp-content/uploads/2020/09/calculator.png)
Simple calculator for adding **two** numbers

Link to a feature: [Calculator](SpecFlowCalculator.Specs/Features/Calculator.feature)
***Further read***: **[Learn more about how to generate Living Documentation](https://docs.specflow.org/projects/specflow-livingdoc/en/latest/LivingDocGenerator/Generating-Documentation.html)**

@Add
Scenario: Add two numbers
	Given the first number is 50
	And the second number is 70
	When the two numbers are added
	Then the result should be 120

@Subtract
Scenario: Subtract two numbers
	Given the first number is 50
	And the second number is 25
	When the two numbers are subtracted
	Then the result should be 25

@Divide
Scenario: Divide two numbers
	Given the first number is 100
	And the second number is 2
	When the two numbers are divided
	Then the result should be 50

@Divide
Scenario: Divide by 0 returns 0
	Given the first number is 0
	And the second number is 70
	When the two numbers are divided
	Then the result should be 0

@Multiply
Scenario: Multiply two numbers
	Given the first number is 5
	And the second number is 50
	When the two numbers are multiplied
	Then the result should be 250

The pipeline yaml:

pool:
  vmImage: 'windows-2022'

steps:    
- task: DotNetCoreCLI@2
  inputs:
    command: 'restore'
    projects: '.NET 6/ASP.NET Core API/ASP.NET Core API.sln'
    feedsToUse: 'select'
- task: DotNetCoreCLI@2
  inputs:
    command: 'build'
    projects: '.NET 6/ASP.NET Core API/ASP.NET Core API.sln'
- task: DotNetCoreCLI@2
  inputs:
    command: 'test'
    projects: '.NET 6/ASP.NET Core API/ASP.NET Core API.sln'
  continueOnError: true
- task: PublishPipelineArtifact@1
  inputs:
    targetPath: '$(Pipeline.Workspace)'
    publishLocation: 'pipeline'
- task: SpecFlowPlus@0
  inputs:
    generatorSource: 'TestAssembly'
    testAssemblyFilePath: '.NET 6/ASP.NET Core API/SpecFlowCalculator.Specs/bin/**/SpecFlowCalculator.Specs.dll'
    projectName: 'SpecFlowCalculator.Specs'
    testExecutionJson: '.NET 6/ASP.NET Core API/SpecFlowCalculator.Specs/**/TestExecution.json'

Specflow and Living Doc in Azure DevOps all test passed and green.

Html report with Images, steps, links, tags etc included.

I made a change to make the tests fail and this is the result :

As you see we get a full report with failed test cases for each scenario and the step they failed with the error message also.
So each time the pipeline runs, business and tech people will be aligned in whats going on in every feature of the application.

This is what we can describe as Business Driven Development.

Summary

Connect the business and tech world is a bit challenging. By doing small steps that can transform quality assurance activities into business value, you can evolve your career and overcome conflicts of unknown work that a QA guy does to his/her job. I will not say that is an easy work to do. Adopting BDD is a challenge itself, the whole organization should transform first and then get the test results combined with BDD feature files into a beautiful report.

Happy testing!

Do you want to do an exploration on this example together?

You can book some time with me to discuss your current situation and do exploratory testing of the sample of this post or any other kind of issue you met regarding Software Testing & Quality Engineering.