Feature editing mode

Test management tool testomat.io allows modern Agile teams to work with tests in BDD format, and precisely on a Feature file level. QAs may edit existing feature files, review changes before saving, and study finished test cases in a convenient format. If you just started, you can easily import test cases from any other TMS you have worked in before, even if it only supports classic tests and automatically turn ones to BDD Gherkin syntax.

What’s are Feature file?

Feature files are documents that contain Gherkin scenarios and formed requirements (user stories). Feature files may be a deliverable of BAs, QAs, POs and other non-tech personas included in 3 Amigos.

Is the Feature file equal to cucumber?

Feature file is a basis for automated tests. It is a bridge between requirements and automated tests. But the Feature file is not equal to Cucumber .feature at all. A feature file is an entry point to the SpecFlow tests, Behat and others.

Features provided to users by Feature editing mode

After opening an existing feature file, you can proceed to edit it. Let’s look at below how convenient you can do it and many more:

1. Create new steps or reuse previously created ones – this is possible thanks to the formation of a database of steps and their inntelligent autocompletion.
2. Format written feature files with a single click – Format. This option allows you to make tidy BDD tests easy to read by removing unnecessary indentation between BDD steps and Gherkin keywords.
3. Replace the desired word in all steps at once. If you press the right mouse button, a context menu will open in front of you, where, in addition to the standard items, there is the Change all Occurrences item in all your BDD tests. Save your changes. After making all corrections, click Save, and the new version of the Feature file will be available to all users of the test management system.
4. View the feature file in a convenient format. Read the information about the test in the Preview tab. This is very convenient because the entire Feature file is on one screen and easy to read.

*Intelligent notification system tips quantity tests and scenarios, to check differences inside Feature files.

Best Practices for writing Feature Files

To make the feature files easy to read and to allow non-technical experts to be involved in the testing process, it is worth following some recommendations for writing them:

1. Follow the sequence of steps. When should not follow Then, and Given should not follow When or Then. These steps must be in strict Given – When – Then order and cannot be repeated.
2. Use a declarative writing style instead of an imperative one. It is worth describing not HOW to accomplish something but WHAT must be accomplished.
3. Write the steps in the third person. Alternating between the first and third person will make your test case difficult to read.
4. Use the subject and the predicate. Shortening the steps may make them unusable for repeated use – they will become incomprehensible and may be misused.
5. Avoid steps that have two actions connected with And. Such steps are better broken into two – this increases the chance of their reuse.
6. Don’t use the Or keyword – Gherkin just doesn’t have it. To cover multiple behaviors, write Scenario Outline.
7. Limit the amount of text. To make the test more readable, describe one function in each feature file. Each feature should contain no more than 12 scenarios, each scenario should contain up to 10 steps, and each step should contain 80-120 characters.
8. Adhere to grammatical and stylistic rules. Observe the rules for writing words and sentences, indent correctly, do not put unnecessary punctuation – all this will help make your test easier to read.
9. Pay attention to the headline. A good headline should be concise and clearly describe the intended behavior.

Set test management features tightly work with Feature editing mode

• Out-of-sync test synchronization: keep track of all changes made to a Feature file using Feature editing mode without any extra effort. The test management toolset will notify you about every such change, assigning the changed test case the unsynchronized status with a label.
• Real-time Reporting: after making changes to a Feature file, you can execute your tests and see its test result in a report with rich analytics.
• Automated tests analytics: make changes to test cases, run tests, and examine the results of modified BDD tests: Automation Coverage, Defects, Ever-failing tests, Slowest tests, Flaky tests, Never run tests, Tag statistic and Aggregated analytics across different projects. Determine which areas need improvement and move on to editing the Feature files you want.
• Jira BDD: by installing the Advanced Jira extension, all the functions in the Gherkin Editor are also available to users in the project management system. If you want to edit a Suite in Jira, the Gherkin language Editor opens immediately, and the Feature editing mode is available directly in the Atlassian Jira app.
• Living Documentation: this test management feature is indispensable for working with BDD tests because Living Docs are technical documentation about the testing written in text format. This allows even non-technical team members (e.g., business analysts (BA), project managers (PM) and product owners (PO)) to be involved in testing. Living Documentation is created automatically, and any changes you make in Feature editing mode are transferred there in real time.