SpecFlow Interview Questions & Answers (2026): 30+ BDD Questions for QA Engineers

Behaviour-Driven Development is a collaborative practice where business, dev and QA describe behaviour in plain English (Gherkin) before code is written. The same file becomes living documentation and an automated test.

SpecFlow is the open-source BDD framework for .NET. It parses Gherkin .feature files and binds each step to a C# method, then runs the scenarios through NUnit, xUnit or MSTest.

Cucumber is for Ruby/Java/JS; SpecFlow is the .NET port. Gherkin syntax is identical — only the step-definition language differs.

The original SpecFlow project is in maintenance. The active community fork is Reqnroll, which is API-compatible — your feature files and most step bindings work unchanged.

Feature, Background, Scenario, Scenario Outline, Examples, Given, When, Then, And, But.

Feature: Login
  As a registered user
  I want to sign in
  So that I can access my dashboard

  Scenario: Valid credentials
    Given I am on the login page
    When I sign in as "user@test.com" with password "Valid@123"
    Then I should land on the dashboard

A set of steps run before every scenario in a feature — typically navigation or setup. Keeps scenarios DRY.

A Scenario runs once. A Scenario Outline runs once per row in its Examples table — perfect for data-driven tests.

A C# method decorated with [Given], [When] or [Then] that maps to a Gherkin step.

[When(@"I sign in as ""(.*)"" with password ""(.*)""")]
public void WhenISignIn(string email, string pwd) =>
    _loginPage.SignIn(email, pwd);

It marks a class as containing step definitions so SpecFlow discovers it during test discovery.

SpecFlow supports both. Cucumber expressions ({string}, {int}) are easier to read; regex gives finer control.

Captured groups in the regex become method arguments, converted via built-in transforms or your own [StepArgumentTransformation].

Lifecycle attributes: [BeforeTestRun], [BeforeFeature], [BeforeScenario], [BeforeStep] and their After* counterparts.

TestRun → Feature → Scenario → Step (top-down for Before, bottom-up for After).

[BeforeScenario("@smoke")]
public void OnlySmoke() { … }

Given the following users exist
  | name  | role  |
  | Asha  | admin |
  | Ravi  | user  |

[Given(@"the following users exist")]
public void Given(Table table) {
  var users = table.CreateSet<User>();
}

Scenario Outline: Invalid login
  When I sign in as "<email>" with password "<pwd>"
  Then I should see "<error>"

  Examples:
    | email          | pwd     | error               |
    | bad@test.com   | wrong   | Invalid credentials |
    |                | x       | Email is required   |

Use ScenarioContext (key/value) or, preferred, constructor injection — SpecFlow's container resolves shared classes per scenario.

public class LoginSteps {
  private readonly TestContext _ctx;
  public LoginSteps(TestContext ctx) => _ctx = ctx;
}

ScenarioContext is reset per scenario; FeatureContext lives for the whole feature. Prefer DI over both.

Yes — SpecFlow.Autofac, SpecFlow.Microsoft.Extensions.DependencyInjection, etc.

NUnit, xUnit, MSTest and SpecFlow+ Runner (deprecated). Pick based on your existing .NET test stack.

Enable parallel execution at the assembly level ([assembly: Parallelizable(ParallelScope.Fixtures)] in NUnit). Ensure step definitions and POMs are scenario-scoped, not static.

dotnet test --filter "TestCategory=smoke"

SpecFlow+ LivingDoc generates HTML reports from TestExecution.json:

livingdoc test-assembly bin/Debug/Tests.dll -t TestExecution.json

Run dotnet test in GitHub Actions / Azure DevOps, publish TRX and LivingDoc artifacts, and gate the PR on green.

Make the binding public async Task:

[When(@"I load the dashboard")]
public async Task WhenLoad() => await _page.GotoAsync("/dashboard");

Install the Reqnroll NuGet packages, remove SpecFlow packages, update using SpecFlow.* to using Reqnroll.*, and re-generate code-behind files.

Inject HttpClient via DI and use it inside steps — the same pattern works for RestSharp, covered in our RestSharp guide.

Behavioural: "When I sign in as an admin". Imperative: "When I type X in field Y and click Z". Always prefer behavioural — interviewers test for this.

Tiny solo projects, throwaway scripts, or pure unit tests. The collaboration cost outweighs the value.