Gherkin is one of the most popular languages for writing formal behavior specifications – it captures behaviors as “Given-When-Then” scenarios.
With the help of automation tools, scenarios can easily be turned into automated test cases.
Quick Points
BDD is specification by example.
When someone says “BDD”, immediately think of “Given-When-Then”.
BDD focuses on behavior first.
Behavior scenarios are the cornerstone of BDD.
BDD is a refinement of the Agile process, not an overhaul.
It formalizes acceptance criteria and test coverage.
BDD is a paradigm shift.
Behaviors become the team’s main focus.
12 Awesome Benefits
Inclusion
Clarity
Streamlining
Artifacts
Shift-Left
Automation
Test-Driven
Code Reuse
Parameterization
Variation
Momentum
Adaptability
behavior-driven development
Testing Recommendations
Since BDD focuses on actual feature behavior, behavior specs are best for higher-level, functional, black box tests. For example, BDD is great for testing APIs and web UIs.
Gherkin excels for acceptance testing
However, behavior specs would be overkill for unit tests, and it is also not a good choice for performance tests
establish a methodology for evaluating software assurance tools
Source Code Security
Analyzers – This class of software tools examines source code
files for security weaknesses and potential vulnerabilities
Web Application Vulnerability Scanners – These tools crawl a web application’s pages and search the application for vulnerabilities by simulating attacks on it
A new effort on Binary Code Scanners - Similar to source code security analyzers, this class of tool analyzes a compiled binary application, including libraries, and provides a report of code weakness over the entire application.
The SAMATE Reference Dataset (SRD) - A community repository of example code and other artifacts to help end users evaluate tools and developers test their methods
Third annual Static Analysis Tools Exposition, which is in progress. The goals are to
enable empirical research based on large test sets,
encourage improvement of tools, and
speed tool adoption by objectively demonstrating their use on real software.
Is a use case a requirement or just a story?
Is a scenario just another name for a use case?
Is a use case a formal, semi-formal, or informal structure?
Is there a linking structure for use cases, or do they just come in piles?
make use cases “rigorous
People want a fairly informal medium in which to express their early thoughts
Using these semi-formal structures, we can both
Assert that use cases really are requirements and need a basic structure, and also
Allow people to write whatever they want when they need to.
Here is the semi-formal structure
Linking use cases to actors’ goals
If the software supports those goals, the software will yield the greatest business value.
goals sometimes fail
failure handling
Therefore, a use case is structured into two sections: the sequence of actions when everything goes well, followed by various small sequences describing what happens when the various goals and subgoals fail.
Why do we write things in the use case that are not externally visible behaviors?
contract between stakeholders
Here are four key pieces of advice that you should note from the evolution of use cases.
there remained a split between those who still wanted to keep use cases short and informal and those who wanted them to be detailed
The Stakeholders and Interests model fills the holes in the Actors and Goals model
Prepare for Multiple Formats
Only Use Them When the Form is Appropriate
Be Aware of Use Case Limits
Use cases should not be used to describe UI designs
use case is normally intended as a requirements document, and the UI design is a design
The same system feature is likely to show up as a line item in multiple use cases
Use cases have a basic mismatch with feature lists
Use cases are not test plans or test cases
Avoid the Standard Mistakes in Use Cases
The two most common and most costly to the project are including too many details and including UI specifics
it’s just that by the time I get subgoals at a good level and remove the design specifics, the task is less than nine step
The greatest value of the use case does not lie in the main scenario, but in alternative behaviors
If the main scenario is between three and nine steps long, the total use case might only be two or three pages long, which is long enough.
readable use cases might actually get read
Originally published in STQE magazine, Mar/Apr 2002
Note: Nice presentation, but should check for content (it states that use cases are test cases, and that would at least need some additional instructions).
User stories and backlog items don’t give the designers a context to work from
don’t give the project team any sense of “completeness
don’t provide a good-enough mechanism for looking ahead at the difficulty of upcoming work
Staring at the set of extension conditions in a use case lets the analysts suss out which ones will be easy and which will be difficult, and to stage their research accordingly
Here 5 reasons why I still write use cases
The list of goal names provides executives with the shortest summary of what the system will contribute to the business and the users
The main success scenario of each use case provides everyone involved with an agreement as to what the system will basically do, also, sometimes more importantly, what it will not do.
The extension conditions of each use case provide the requirements analysts a framework for investigating all the little, niggling things that somehow take up 80% of the development time and budget
The use case extension scenario fragments provide answers to the many detailed, often tricky business questions
The full use case set shows that the investigators have throught through every user’s needs, every goal they have with respect to the system, and every business variant involved
how much should be written up front to get the project estimate into a safe place
several sticky parts for people using use cases
iteration/sprint lengths are so short that it is not practical to implement an entire use case in just one of them.
Writing good use cases (or any other requirements) requires thinking, communicating, and thinking again. It is much easier just to write user-story tags on index cards and let the project blow up later
We have adopted many of the concepts of Agile development—such as daily build and test, build the smallest piece of functionality that delivers value, etc.—but have retained our up-front work. It’s worked extremely well
SPIder is een Nederlands netwerk van IT-professionals waarin kennis en ervaringen gedeeld worden op het gebied van softwareontwikkelmethodieken, processen en modellen, (software)procesverbetering (SPI), kwaliteit, kwaliteitsboring (QA), ontwerp en test, metrieken en invoeringstrategieën