BDD Acceptance Tests feel....short?

Question

So I'm newly adapted to BDD and have been using Cucumber for Test Automation, but I also use the "Gherkin" style for writing acceptance tests (that I will hopefully be able to automate in the future, but since I'm a one-man show I have to do what I can with the time available)

That being said, I'm basing these acceptance test cases off of User Stories produced in Jira. The user stories are very typical IE:

As a user, I want to be able to Sign Out of my account, edit/change my password, and edit my name/account information.

Pretty basic User Story, so for my "Feature/Scenario" I have (Storing them in testrail for now):

Feature: User Account Functions
I want the ability to sign out of my account, edit my password, and edit my user account information

Scenario:
Given I have created an account
And I am signed in
When I select the Sign Out option
Then I should be signed out from the web application


Scenario:
Given I have created an account
And I am signed in
When I go to my account page
And change my password
Then my password should be updated to the new password


Scenario:
Given I have created an account
And I am signing in
When I go to my account page
And Edit my account information
Then my account information should be saved with the new information
But not contain any of the old information

So they just seem so...basic? and short. But the thing is I don't see the point in adding unnecessary detail (or imperative like steps to these). Is this right? I mean I'm pretty new to the BDD style/Gherkin style of writing. But I mean it gets the point across, I just look at it and it looks so short.

Maybe that's the point however? Because I could do a step by step test plan, but that doesn't really benefit anyone? Especially if I'm going to perhaps eventually automate these? But I'm thinking about for instance even if I didn't automate these, does the writing style still make sense?

Answer 1

This looks fine. BDD feature files is meant to be at a level to give useful information to product folks.

In each step you can call lower level steps if you want to give more specific information (or more reusable actions)

For this one for example

Given I am signed in

It might just call within it

 // enter the username
 GivenIEnterInTheField(string value, string fieldID)
 // enter the password
 GivenIEnterInTheField(string value, string fieldID)
 // click the button
 GivenIClickOnTheButton(string buttonId)

Which is also readable, but not necessary for the top level steps or feature file