Forem: Emmanuel Salazar

Tutorial: Selenium WebDriver + Reqnroll

Emmanuel Salazar — Sat, 11 Oct 2025 22:52:06 +0000

Complete Step-by-Step Tutorial

This tutorial provides a complete, step-by-step guide to creating an
automated testing framework using Selenium, Gherkin (BDD), and
Reqnroll in Visual Studio 2022.

You'll learn how to set up your environment, configure dependencies, and
write your first executable feature file with readable test
scenarios that bridge the gap between business and technical teams.

🧩 Step 1 --- Verify Reqnroll Installation

Before creating your first automation project, make sure that the
"Reqnroll for Visual Studio 2022" extension is installed.
This extension provides the structure and templates required to build a
Behavior-Driven Development (BDD) framework using Gherkin and
Selenium.

Open Visual Studio 2022.
From the start window, choose "Continue without code."
Open the Extensions Manager.
Navigate to Extensions → Manage Extensions.
Search for "Reqnroll for Visual Studio 2022."
Check installation status.

-   If it shows **Uninstall**, the extension is already installed. 
-   If not, click **Install**, wait for it to complete, and
    **restart Visual Studio**.

💡 Tip: Reqnroll is the open-source successor to SpecFlow --- fully
compatible with .NET 8 and Visual Studio 2022.

🧩 Step 2 --- Create a Reqnroll Project

Open the "Create a New Project" window.
From the start screen, click Create a new project.
Search for "Reqnroll Project."
Select it from the list and click Next.
Configure project details.
Enter a Project name, choose a Location, and set the Solution name.
Click Create.
Select your testing framework.
Choose MSTest as the Test Framework, then click Create.
Verify the template.
By default, a sample project called Calculator is generated to demonstrate structure.

🧩 Step 3 --- Add Selenium Dependencies

To interact with browsers, you need to install Selenium via NuGet
Packages.

Go to Tools → NuGet Package Manager → Manage NuGet Packages for Solution...
Under the Browse tab, search and install:

-   `Selenium.WebDriver`
-   `Selenium.WebDriver.ChromeDriver`

💡 Tip: Ensure the ChromeDriver version matches your installed
version of Google Chrome.

🧩 Step 4 --- Create a Feature File and Step Definitions

Open the Solution Explorer and locate the Features folder.
Add a new Feature File.
Right-click Features → Add → New Item.
Choose the template.
Select Reqnroll → Feature File for Reqnroll, then click Add.
Name the file (e.g., Search.feature) and click Add.
You'll now have an empty .feature file with Gherkin structure.
Write your first BDD scenario:

Feature: Search
  Perform a search on DuckDuckGo to validate that results are displayed correctly.

  @smoke @search
  Scenario: Search for a keyword in DuckDuckGo
    Given the user navigates to the DuckDuckGo homepage
    When the user searches for "Reqnroll BDD"
    Then the search results should contain the word "Reqnroll"

Build the project.
The Gherkin text will turn purple, indicating that steps are
recognized but not yet implemented.
Generate the step definitions.
Right-click any Gherkin line → Define Steps... → Create.

🧩 Step 5 --- Using Selenium WebDriver with Chrome

The following steps demonstrate a minimal viable automation test
using Reqnroll.
The objective is to show the Given/When/Then flow applied to a simple
web search.

💡 Note:
Best practices like hooks (Before/After) and Page Object Model
(POM) will be covered in later tutorials.
For now, we'll just make it work end to end.

1️⃣ Create the WebDriver

First, we must create our WebDriver in the same class and specify which browser to use.
In this case, we’ll use Google Chrome:

IWebDriver webDriver = new ChromeDriver();

🧠 You don't need to manually download chromedriver.exe.
Selenium Manager handles driver setup automatically.

2️⃣ Given Step --- Navigate to the Homepage

The Given step defines the starting context of the test.
Here, we specify which page the browser should open using Navigate().GoToUrl():

[Given("the user navigates to the DuckDuckGo homepage")]
public void GivenTheUserNavigatesToTheDuckDuckGoHomepage()
{
    webDriver.Navigate().GoToUrl("https://duckduckgo.com/");
}

3️⃣ When Step --- Perform the Search

In the When step, we define the action that will be performed.
In this example, the user searches for a keyword in the search box:

[When("the user searches for {string}")]
public void WhenTheUserSearchesFor(string p0)
{
    var query = webDriver.FindElement(By.Name("q"));
    query.Click();
    query.SendKeys(p0);
    query.Submit();
}

We locate the input by name="q", send the text, and submit the
form.

4️⃣ Then Step --- Validate the Result

The Then step is used to validate the expected outcome.
We look for a search result link that matches our keyword and use an Assert to verify it:

[Then("the search results should contain the word {string}")]
public void ThenTheSearchResultsShouldContainTheWord(string reqnroll)
{
    var result = webDriver.FindElement(By.LinkText(reqnroll));
    Assert.IsTrue(result.Text.Contains(reqnroll));
}

✅ If the searched word appears among results, the test passes.
❌ Otherwise, the assertion fails.

5️⃣ Run the Test

Open View → Test Explorer.
Run the test from there.
The browser will stay open after execution.

⚠️ That's normal --- we haven't added an After hook to close the
browser yet.
We'll improve that in the next tutorial.

✅ Conclusion

You've just created your first BDD test using Reqnroll and
Selenium!
From here, you can extend it with: - BeforeScenario / AfterScenario
hooks

The Page Object Model (POM) pattern
Custom assertions and reusable steps
CI/CD integration with GitHub Actions or Azure Pipelines

The Invisible Cost of Flaky Tests

Emmanuel Salazar — Thu, 31 Jul 2025 21:28:34 +0000

Everything has a cost. And today, I want to talk about the costs we rarely mention in test automation—financial cost and trust.

The financial side is often heard but not really felt. We spend hours in meetings that yield no clear results, affecting team efficiency and wasting time and money.
The second cost, trust, is the currency we trade when we ask for more responsibilities or resources—and our leaders have to decide whether to trust us or not.

🔁 The Problem: Tests that Fail… Sometimes
In test automation, we use the term flaky to describe tests that are unstable—tests that pass sometimes, and fail other times, without any changes in the code.

You run the test 10 times on your machine and it passes. But when it's part of the full suite, it randomly fails. You rerun the suite to isolate the issue… and now it works again.

💸 Where Invisible Costs Start Adding Up
This is where the hidden costs begin to surface:

Time spent investigating “why it failed.”
Manual reruns to reproduce the issue.
Interrupting developers to ask about expected behaviors.
QA losing focus while chasing phantom failures.

All this while the clock keeps ticking.
Not only are you burning hours—you’re losing the team’s confidence in automation.

⚠️ When the Test Suite Stops Being Useful
This directly impacts the team. When we say “we have automation,” people assume:

Most of the system is covered.
Every new release will be validated by running the suite.

But if only 20% of tests are consistently reliable, the value drops fast.
Automation becomes more of a liability than a safety net.

🧩 What Can We Do About It?
We know maintaining the suite is part of the job. Each team might take a different path, but some common strategies include:

Controlled use of retry logic in specific test scenarios.
Temporarily disabling flaky tests and tracking them in a technical backlog.
Rewriting unstable tests from a new perspective.
In extreme cases, migrating to a more stable infrastructure.

Whatever the path, we can’t afford to delay decisions. Automation is a shared responsibility, not something one person carries alone.

🗣️ Communicating is Leading
If something fails, say it clearly.
Explain what happened, why it failed, what the impact is, and how long fixing it might take.

Because when confidence is gone, the issue isn’t just “a flaky test”—it’s the credibility of your quality process that’s at stake.

🎯 Final Thought: Automation is Also a Product
Test automation is not “just another tool.” It’s the product that validates the product your customer actually cares about.

That’s why our communication must be clear, transparent, and focused on continuous improvement.

Each day, our goal is not just to automate more, but to deliver more value with less noise and greater confidence.

💬 What about you?
Have flaky tests ever drained time or trust in your team?
What strategies have helped you bring stability back to your pipeline?

QA | Leading Also Means Deciding Without Slowing Down the Team

Emmanuel Salazar — Wed, 23 Jul 2025 17:21:49 +0000

This is something personal, but also a common theme in agile environments: meetings to plan more meetings.

How many times have you had to make a decision without consulting the whole team — even while working under a democratic leadership style?

When collaboration becomes a roadblock

I understand that every leader organizes their team differently.
In my case, I used to believe that the best way to lead was to involve everyone: the Product Owner, Scrum Master, developers, and of course, all the QA engineers.

Especially during critical processes like production releases, it felt right to invite everyone to participate, share input, and help us reach the common goal.

Three meetings for one decision

With the excuse that “we’re all part of the team,” we ended up having meetings for everything:
One to discuss how we’d search for test cases
Another to choose which scenarios to execute
And a third to validate that the team was happy with the selection and assignment of the test cases

All this… while the sprint clock kept ticking.

But reality looked different: some people didn’t show up, others didn’t engage, and most had competing priorities.

Leading is not about imposing — but it is about acting

I value collaborative work. I truly believe that ideas improve when everyone contributes.
But I’ve also learned that leading isn’t just about listening — it’s about acting with good judgment when the team needs to move forward.

And that kind of decision-making doesn’t come from ego or control.
It comes from understanding that leadership also means protecting the team’s time, unblocking progress, and stepping in when the process isn’t enough.

Expert judgment matters

A QA lead must be able to:

Read the context and make decisions without fear
Know when to bring the whole team in — and when not to
Fill in the blanks in the process
Avoid the endless cycle of unproductive meetings

Because quality is also about efficiency, balance, and product impact.

A shift in approach made a big difference

Just like in research, there’s more than one way to reach the desired outcome.

I used to involve everyone at every step to get alignment.
Now, I follow this approach:

I make a context-aware, technical decision
I implement the best possible solution
I present the results afterward for feedback and validation

That shift helped reduce time, avoid friction, and increased our impact as a team.

Final thoughts

I still care deeply about including the team’s voice.
What changed is that I now understand — as a leader — that efficiency, productivity, team well-being, and customer happiness are critical metrics too.

It’s not about excluding anyone.
It’s about finding smarter ways to include — without slowing everyone down.

QA | When It’s Okay to Break the Rules

Emmanuel Salazar — Tue, 22 Jul 2025 00:33:38 +0000

As quality professionals, we operate within organizational structures and processes designed to help us do our job better. These rules often act as safety nets — improving consistency, reducing risks, and supporting successful product delivery.

But what happens when those rules don’t account for the exceptions that make real-world work efficient?
This article isn’t a call to challenge authority for the sake of it — instead, it’s an invitation to reflect on when breaking the rules is not only acceptable, but necessary.

The Process Wasn’t Made for Every Situation

QA processes often rely on checklists, predefined flows, and rigid criteria. But reality rarely follows the script. Sometimes, strictly adhering to the process delays delivery or even compromises product value.

We see this shift in other disciplines too. Developers are now encouraged to write self-explanatory code rather than over-document every line. Why? Because documentation isn’t the goal — understanding is. The same principle should apply to QA.

The Danger of Inflexible Processes

When part of the process can’t be completed — due to lack of time, context, or information — teams often freeze. No one wants to move forward without “checking the box,” and that stalls progress.

Have you ever been in the middle of a regression run and forced to justify each and every test case you chose to include (or exclude)? That level of bureaucracy slows everyone down and adds no value if applied blindly.

Expert Judgment: The Unwritten Rule

Breaking a rule isn’t recklessness. It’s judgment. It’s experience. It’s the ability to assess context, risk, and goals — and then act accordingly.

That’s what we call expert judgment: the intuition, common sense, and situational awareness that come with time and practice. It’s not about skipping steps at random, but about knowing which rules matter most in each scenario and being able to defend your choices with confidence.

Would you treat a release with one small bugfix ticket the same as a major deployment with 20 changes?
Of course not. So why assume a single rigid process fits all cases?

Breaking Rules… Responsibly

The key is not to institutionalize chaos, but to acknowledge that exceptions exist and that our processes must evolve to support them. That means:

Evaluating the impact of not following a step.
Communicating the deviation with your team or tech lead.
Documenting the decision (even informally).
Learning from the case to improve the process.

Final Thoughts: Rules Should Be Alive, Not Sacred

Processes are meant to serve the team — not constrain it. If they don’t allow room for exceptions, they become bottlenecks. As QA professionals and leaders, we have a duty to challenge what doesn’t work and push for continuous improvement.

Breaking the rules is okay — if you understand why, can explain your reasoning, and it aligns with delivering value.