The BDD scenario problems and solutions (for developers) meeting result

Recently we've acquired 4 opened issues connected with BDD-style development

Here they are:

The solutions were developed.

Too detailed requirements

We can solve it with macro commands.

Macro commands are just several action steps combined in one name.

In example, instead of writing

Given process 'All Practices' defined

And project 'TargetProcess' for process 'All Practices' created

We will be able to write:

Given TargetProcess project created

So, we need to be able to define an action step (macro command) which consists actually defined with using of two other action steps.

No test output will be hurt! The output will be just macro command, not it's internal action steps.

Too Many Action Steps

Actually, having many action steps is not a problem. The real problem is that we can't navigate through them during scenario writing.

It was decided to try to implement intellisence for bdd specs.

Badly Structured Specs Location

Indeed, it's quite hard to switch from unit tests organization (class-level) to bdd specs (feature-level).

We need to switch our structure to provided above.

BDD Specs Meeting Followup

Today we discussed several issues connected with BDD specs and their role in QA and Dev Team collaboration.

As the resule the following agreements were achieved:

1. No User Story should be implemented or taken in In Progress state without specs (QA + Dev Team + Product Owner)
2. User Story specs should be updated with possible BDD scenarious. Those specs should be introduced as Test Cases (QA)
3. Specs should be revised by Dev Team and updated if necessary (QA+Dev Team)
4. Specs (formed Test Cases) should be marked as Passsed when implemented (Dev Team)