×
IBORN Logo
QA engineers discussing work.

Deliver the right software with SBE

Sara Pavlovikj
March 21, 2019


If you work with software development I’m sure that you’ve already heard words like BDD, TDD, ATDD, etc. But, have you heard about SBE? SBE or Specification by Example is a collaborative method for specifying requirements and test. It is a set of process patterns that helps teams build the right software product by writing just enough documentation to facilitate change effectively in short iterations or in flow-based development.

This method springs from the Agile Acceptance Testing and it’s based on defining software requirements by illustrating executable specification with precise examples. SBE is spoken by the Gherkin language. This is a syntax for writing test scenarios that implement BDD methodology. It’s designed to be easy-to-learn by non-programmers, yet structured enough to allow the concise description of examples to illustrate business rules in many real-world domains. 

The structure of Gherkin is the following:

Given - precondition

(and - optional precondition)

When - action/event

Then - outcome

(and - optional outcome)

Before we continue let’s explain some terms from the software quality assurance world and how the testing process goes by the exact order.

Two colleagues working together on a mac in a modern office environment.


If we need to implement something or make some changes, first, we need to create Living Documentation. Gojko Adzic defined the Living Documentation in his book “Specification by Example” as a source of information about system functionality that’s as reliable as programming language code but much easier to access and understand. Living documentation allows teams to collaboratively analyze the impact of proposed changes and discuss potential solutions. 

It also allows them to make use of existing documentation by extending it for new requirements. The Living Documentation helps you to analyze the impact of the changes and to share the knowledge better, so, it makes specifying and implementing more efficient over time.

The Living Documentation consists of a user story, acceptance criteria, and test scenario.

The specification starts with a user story. A user story is an outgrowth of agile methodologies and is used to state requirements without writing endless pages of documentation by break down customer’s requirements into small pieces that are easier to understand and build.

The structure of the  user story is the following:

As a - user role/persona

I want to - feature/functionality

So that - goal/benefit

 

User stories consist of:

  1. Title - a short explanation of the feature

  2. Body - brief description of who wants the functionality, why and what is the purpose.

  3. Acceptance criteria - defines what you will walk through to make sure that the story is completed.

Now it seems that we have a new open question. What is an acceptance criteria? Acceptance criteria is a specific and well-defined list of conditions that we must meet before the project is considered completed and the project deliverables are accepted by the client. Having clearly defined acceptance criteria can help you in many ways. It triggers the thought process for the team to think how a feature will work from the end user perspective, helps the team to write accurate test cases without any ambiguity to understand the business value, and keeps the right content.

So, first, we create a product specification with user stories. After that, every user story has his own acceptance criteria with one or more test scenarios. The test scenario is created with the Gherkin syntax mentioned above - Given, When, Then.

test scenario is a narrative, which describes how a user might interact with a website or software application. In these scenarios, a specific task is specified and a narrative is written describing how a user might accomplish this task.

Diverse group of people working on their laptops n a conference room.

Summing up, the SBE method is a set of process patterns, such as:

  • Deriving scope from goals - Instead of asking the client for project scope, make sure to understand the business goals and derive the scope from them. Understand the “why” and “who”, understand where the value is coming from, and understand what outputs the business users expect.

  • Specifying collaboratively - Successful teams collaborate with the business users in order to build a shared understanding of what needs to be done and to ensure that different aspects of a system are covered by the specification.

  • Illustrating specifications using examples - Maintain one source of truth. The illustrated examples should describe the entire feature. Data should be included, and don’t use yes/no answers in your examples.

  • Refining the specifications - Never use raw examples, but refine the specification from them. The idea is to use the specification without changing it in order to preserve the value of refining it.

  • Automating the specifications - When the team agrees on a specification with key examples they need to be automated as tests, so you can validate the system many times during the development to ensure that it meets the business goals. It would not be effective if you do these tests manually, it would introduce unnecessary delays and the feedback would be slow.

  • Validating frequently - The system and the executable specification need to be constantly synchronized. After the automation of the validations, you need to validate the system. If this validation is frequent the team get quick feedback. They identify the defects and any differences between the system and the specification early, so they are cheaper to fix.

  • Evolving living documentation - Software products keep evolving and changing after the initial release. That’s why the specifications need to be well organized, easy to find and access and the teams need to update the specifications with these changes, making it a living documentation system that evolves with the code, and it’s a reliable and authoritative source of information, easy to read and understand.

By applying the Specification by Example method you can bridge the communication gap between stakeholders and implementation teams, ensure the software quality from the start, design, develop and deliver the right (software) product.

More similar blog posts:

QA engineers discussing work.
How feature flags benefit various roles in teams

Everything you need to know about feature flags. Explore how this simple yet transformative tool enhances agility, quality, and collaboration across diverse roles in a team. 

QA engineers discussing work.
Achieving future-proof software

As IT engineers we take great pride when what we do improves an aspect of society. Even the little things, like improving loading time by half a second mean a lot.

QA engineers discussing work.
Enhance your business with an intelligent ERP

It is common among company owners and managers to think that the digital transformation process is completed simply by implementing an ERP system. But, this is a misconception, as that’s just the beginning. The question “And, now what?” follows logically.

QA engineers discussing work.
Introduction to Reactive Programming

Reactive Programming is a new declarative paradigm. It makes it possible to work with finite or infinite data flows asynchronously, allowing it to propagate generating changes in the application. As it is indicated by the title, it ‘reacts’ to the data by executing a series of events.

QA engineers discussing work.
SaaS: Advantages of Cloud Computing for SMEs

ew technologies can be very beneficial for small and medium-sized enterprises (SMEs), especially technologies that can improve and simplify business management processes without increasing costs.

QA engineers discussing work.
Business benefits of software consulting and development services

We live in a globalized world where companies that aim to be successful on an international scale are facing a lot of competition. In order to be a fast-growing company and climb high up the ladder, you should have a large team. 

QA engineers discussing work.
Top 8 myths about custom software development

Myths, false beliefs and assumptions obstruct the communication and software development process. Is it really custom software development slow, expensive and complicated? It doesn't necessarily have to be that way.

QA engineers discussing work.
Custom software development or off-the-shelf software?

The dilemma that most innovative software companies and business owners face at some point.

QA engineers discussing work.
Software development company vs. Freelancer

If you’re reading this, you probably have a great idea for a web project or an app. I’m pretty sure you have some ideas about how to do it.

QA engineers discussing work.
Creating Customer Value with Quality Assurance

From an eminently commercial point of view, creating value means offering something to someone who wants to fulfill a need and hopes to satisfy it by making some kind of sacrifice - usually economic.

QA engineers discussing work.
Benefits of making software quality assurance tests

Isn’t it frustrating when the software you are using suddenly stops working? If a website or an app takes more than 3 seconds to load, we close it immediately. Let's be honest, we live in a time when nobody has patience with poor quality software.

QA engineers discussing work.
BDD + Cucumber - The best of both worlds

What BDD as a development methodology has to do with testing techniques?

QA engineers discussing work.
9 myths about QA and testing

Do you know the real functions of a QA? Do you know the main difference between QA and Tester? Are they heroes or villains? Let’s go through the most common myths regarding the process of testing and try to debunk them.

QA engineers discussing work.
Quality Assurance vs. Tester - What is the difference?

Testing is an activity. Anybody can test. Sometimes testing is just using a product, while QA requires a strategic approach to testing in the sense of planning how, what, and when to test. Let's deep dive into what is the main difference between quality assurance and testing.