Maintaining Behaviour Driven Development Specifications: Challenges and Opportunities (original) (raw)

Characterising the Quality of Behaviour Driven Development Specifications

Characterising the Quality of Behaviour Driven Development Specifications, 2020

Behaviour Driven Development (BDD) is an agile testing technique that enables software requirements to be specified as example interactions with the system, using structured natural language. While (in theory) being readable by non-technical stakeholders, the examples can also be executed against the code base to identify behaviours that are not yet correctly implemented. Writing good BDD suites, however, is challenging. A typical suite can contain hundreds of individual scenarios, that must correctly specify the system as a whole as well as individually. Despite much discussion amongst practitioners and in the blogosphere, as yet no formal definition of what makes for a high quality BDD suite has been given. To shed light on this, we surveyed BDD practitioners, asking for their opinions on the quality criteria that are important for BDD suites. We proposed, and asked for opinions on, four quality principles, and gave practitioners the option to add more principles of their own. This paper reports on the results of the survey, and presents an approach to defining BDD suite quality.

Towards a Taxonomy for Applying Behavior-Driven Development (BDD)

2019

Behavior-Driven Development (BDD) is a topic currently much talked about, especially in the agile community. Small scale examples of BDD suggest an intuitive and easy use, but experience shows that in practice, especially large projects, its application becomes elaborate and challenging. This paints an inconsistent picture about BDD. So, what are the requirements for a successful application of BDD? We have identi ed, discussed, and classi ed the core aspects of applying BDD. Depending on the application context, an aspect can speak for or against the use of BDD. These aspects and their pro and contra arguments are this article's main contribution. Everyone can use these aspects to decide whether and how to use BDD in their individual project context.

Adapting Behavior Driven Development (BDD) for large-scale software systems

Journal of Systems and Software

Context: Large-scale software projects require interaction between many stakeholders. Behaviordriven development (BDD) facilitates collaboration between stakeholders, and an adapted BDD process can help improve cooperation in a large-scale project. Objective: The objective of this study is to propose and empirically evaluate a BDD based process adapted for large-scale projects. Method: A technology transfer model was used to propose a BDD based process for large-scale projects. We conducted six workshop sessions to understand the challenges and benefits of BDD. Later, an industrial evaluation was performed for the process with the help of practitioners. Results: From our investigations, understanding of a business aspect of requirements, their improved quality, a guide to system-level use-cases, reuse of artifacts, and help for test organization are found as benefits of BDD. Practitioners identified the following challenges: specification and ownership of behaviors, adoption of new tools, the software projects' scale, and versioning of behaviors. We proposed a process to address these challenges and evaluated the process with the help of practitioners. Conclusion: The evaluation proved that BDD could be adapted and used to facilitate interaction in large-scale software projects in the software industry. The feedback from the practitioners helped in improving the proposed process.

Bridging the Gap between Requirements Modeling and Behavior-Driven Development

2019 ACM/IEEE 22nd International Conference on Model Driven Engineering Languages and Systems (MODELS)

Acceptance criteria (AC) are implementation agnostic conditions that a system must meet to be consistent with its requirements and be accepted by its stakeholders. Each acceptance criterion is typically expressed as a naturallanguage statement with a clear pass or fail outcome. Writing AC is a tedious and error-prone activity, especially when the requirements specifications evolve and there are different analysts and testing teams involved. Analysts and testers must iterate multiple times to ensure that AC are understandable and feasible, and accurately address the most important requirements and workflows of the system being developed. In many cases, analysts express requirements through models, along with natural language, typically in some variant of the UML. AC must then be derived by developers and testers from such models. In this paper, we bridge the gap between requirements models and AC by providing a UML-based modeling methodology and an automated solution to generate AC. We target AC in the form of Behavioral Specifications in the context of Behavioral-Driven Development (BDD), a widely used agile practice in many application domains. More specially we target the well-known Gherkin language to express AC, which then can be used to generate executable test cases. We evaluate our modeling methodology and AC generation solution through an industrial case study in the financial domain. Our results suggest that (1) our methodology is feasible to apply in practice, and (2) the additional modeling effort required by our methodology is outweighed by the benefits the methodology brings in terms of automated and systematic AC generation and improved model precision.

A Study of Framework of Behavioural Driven Development: Methodologies, Advantages, and Challenges

International Journal on Future Revolution in Computer Science & Communication Engineering

BDD is the behavioural driven development which is used for the development process of the software. It used to describe behaviour of the system in a language which is easy to read and understand. It is the development process which is used to bridge the gap between the technical people involved in the project and the businesspeople who are not technically sound. The aim and goal of BDD is to deliver business value products for which it helps to provide communication between developers and analysts via shared process and tools. The origin of BDD is TDD which is test driven development where examples are used to describe the behaviour of the system which could be used as acceptance test, and which could be converted into executable specifications. This process is very useful for the software developers as it is very useful for them to develop a software project which fulfils all its goals and aim. This methodology also helps to get rid of the confusion and improves the communication ...

Tool for Generating Behavior-Driven Development Test-Cases

Journal of Information Systems Engineering and Business Intelligence

Background: Testing using Behavior-Driven Development (BDD) techniques is one of the practices of Agile software development. This technique composes a test-case based on a use case scenario, for web application acceptance tests.Objective: In this study, we developed a tool to generate test case codes from BDD scenario definitions to help and facilitate practitioners to conduct testing.Methods: The generated test case code is made according to the codeception framework format so that it can be directly executed by the tester. The procedure is performed as follows: map the correlation of the language used in BDD (gherkin language) and the code syntax of the test code in the codeception framework, designed the GUIs in such a way that users can easily transform the Use Case Scenario, built the tool so that it can generate test cases codes. Evaluation is done by gathering respondents; ask to run the application and gathering feedback from respondents.Results: This tool can generate a ...

A Study of the Characteristics of Behaviour Driven Development

2011 37th EUROMICRO Conference on Software Engineering and Advanced Applications, 2011

Behaviour Driven Development (BDD) has gained increasing attention as an agile development approach in recent years. However, characteristics that constituite the BDD approach are not clearly defined. In this paper, we present a set of main BDD charactersitics identified through an analysis of relevant literature and current BDD toolkits. Our study can provide a basis for understanding BDD, as well as for extending the exisiting BDD toolkits or developing new ones.

Detecting Duplicate Examples in Behaviour Driven Development Specifications

In Behaviour-Driven Development (BDD), the behaviour of the software to be built is specified as a set of example interactions with the system, expressed using a "Given-When-Then" structure. The examples are written using customer language, and are readable by end-users. They are also executable, and act as tests that determine whether the implementation matches the desired behaviour or not. This approach can be effective in building a common understanding of the requirements, but it can also face problems. When the suites of examples grow large, they can be difficult and expensive to change. Duplication can creep in, and can be challenging to detect manually. Current tools for detecting duplication in code are also not effective for BDD examples. Moreover, human concerns of readability and clarity can rise. We present an approach for detecting duplication in BDD suites that is based around dynamic tracing, and describe an evaluation based on three open source systems.

A Unified Specification of Behavior for Requirements and Design

NRL/MR/5540--07-9094, 2007

It would be useful to write one description of software behavior to serve both requirements and design. Having one description could reduce effort by eliminating the work of developing two descriptions and of keeping them consistent throughout development and maintenance. It would also eliminate the inconsistency inherent in having two descriptions, a fertile source of error. A question paramount to software engineers is Could one description of behavior for a real system serve both requirements and design? The purpose of the present document is to answer that question by producing one such description of the software behavior of a real system. The specification presented here is based upon behavioral specifications extracted from function and abstract interface specifications developed by Paul Clements, Alan Parker, Kathryn Heninger Britton, David Parnas, John Shore, Stuart Faulk, Bruce Labaw, and David Weiss.

A tool stack for implementing Behaviour-Driven Development in Python Language

ArXiv, 2010

This paper presents a tool stack for the implementation, specification and test of software following the practices of Behavior Driven Development (BDD) in Python language. The usage of this stack highlights the specification and validation of the software's expected behavior, reducing the error rate and improving documentation. Therefore, it is possible to produce code with much less defects at both functional and unit levels, in addition to better serving to stakeholders' expectations.