Trying to understand something that's not defined here? Ask us in a message — and we can add it to the list 😄
This refers to the Behave Pro panel that can be added to Jira Issues for viewing Scenarios/Examples that add details to the user story and how the product owner/stakeholders believe the application under development should function when the issue is accepted as "Done"
Classic project type
The original project type in Behave Pro where the data is stored inside Behave Pro and is exported by users or build tools to be executed as Automated tests. This is ideal for very simple projects but a lot more functionality is available in Git connected projects.
An alternative name for Scenarios and is slowly replacing it as the term being used by BDD practitioners. See the definition of Scenario.
Git connected project type
A new project type where feature files are stored in the team's Git repository and any change made in Behave Pro to features or scenarios are committed directly to the git repository. Any commits made by testers or developers are synced back into Behave Pro and Jira. We recommend using this project type instead of the classic type.
Living Documentation is documentation that has been generated from a set of inputs in a repeatable and consistent manner.
In the case of BDD, the inputs are the Scenarios written in the natural language Given When Then format and the test results from Cucumber or SpecFlow. When these inputs are combined they created documentation that describes how the application or system works and if that functionality is working as described.
This makes a change from manually maintained documentation as every change is automatically added and can't be forgotten. How many times has a simple change been missed in manual documentation that has lead to confusion and delay.
This page can be found on the left navigation of any project using Behave Pro. It displays all the features and scenarios for the project to 'document' the functionality that has been developed.
A scenario is an example of how the application or system should behave in a given situation. The scenario is usually written in the Given When Then format used by Cucumber and SpecFlow.
Multiple scenarios are created for each user story to help describe the functionality required. Each scenario covers a single flow or situations, and when multiple paths are required multiple scenarios are created.
A special type of scenario where the core scenario is the same but takes different sets of values and expected outcomes. Very useful in demonstrating edge cases based on data.
An Examples table is provided at the end of the scenario. The first row of the table declares variable names which can be referenced from the Given When Then steps. The remaining rows of the table each represent a scenario whose values will be inserted into the Given When Then steps.