Why have information in one place, when it can be duplicated a 10000 times in many places? The web demonstrates very effectively how easily information can become corrupted by indirect communication. Take any news story, then (if you can be bothered), read the same story on different websites. Mostly, they are the same, but some cannot resist adding their own additions to the story.
“Please call Stella. Ask her to bring these things with her from the store: six spoons of fresh snow peas, five thick slabs of blue cheese, and maybe a snack for her brother Bob. We also need a small plastic snake and a big toy frog for the kids. She can scoop these things into three red bags, and we will go meet her Wednesday at the train station.”
You can hear these words recited 1,300 times at the online speech accent archive at George Mason University in Fairfax, Virginia – and every one is different.
[In TDD] first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards.
Should a tester/developers become a combined entity? Or is this simply representative on the increasing demands on a tester? Stepping back from this boringly over-debated point, there are reasons that the question arises in the first place …From QA Management persepctive, there is weaknesses in the path from user story down to code, and the transparency. Slight deviations can lead to major requirements gaps, and ATDD (or the identical BDD – Bahvaiour Driven Design), is one approach that addressed this on paper – but regards good tools available, they are still very light on the ground.
BehaviourDrivenDevelopment is all about GettingTheWordsRight. We find that when we use a consistent vocabulary, much of the traditional disconnect between Business and Technology simply disappears.
This is an alternative approach to BDD, which can help developers, in the form of using acceptance test frameworks such as Fitnesse (for which there a lot of plugins, to hook into to most IDE’s, including the montrosity that is TFS). The scripting language is down to user choice, but if you a language compatible with the application under test, you can do some more fancy hookup between unit tests, and acceptance tests. In BDD the onus is on the developer to write code directly from high-level user story/scenario. Using a good acceptance test framework will ensure:-
There has been some interesting discussions around User Stories on linkedin recently – and have illicted some passionate opinions on why people think user stories are not enough for every requirement. Take performance or technical requirements. This is too simplistic a view on user stories – I would challeneg anyone to find a requirement that cannot be traced back to user/action(s)/results. It does require a different mindset, which I think is why there is resistance to change.
- Non-functional requirements are generally “hiding” in a User Story
- We have to learn how to include non-functional requirement as a User Story
- We have to learn how to create acceptance criteria to support a non-functional User Story
Seems straightforward, doesnt it? Well it isnt – but then requirements gathering shouldnt be – its a key stage in the beginnings of a project, and there should be a blood/sweat/tears element.
When a product owner says “this system must perform adequately with 100,000 concurrent users” the product owner is putting a constraint on the development team. The product owner is effectively saying, “Develop this software any way you’d like as long as you achieve 100,000 concurrent users.” Each constraint we put on a system narrows the design choices a bit; calling these “constraints” rather than “non-functional requirements” helps us remember this.
Following recent experience with Agile Methodology BDD – I was impressed by how this appraoch provided tighter bond between user story and resulting code. And with maintenance in mind – every time a new story added or amended, these changes propogate down through to source code level. BDD also provides the clear scope for testing, and by using scenrarios as basis for a complete regression test set. A lot in Agile is relaint on the quality of User Stories (as in fact any methodology is reliant on quality of requirements). The BDD approach does ensure that user Stories are firmly in forefront of the SDLC.
Once a user story is defined, should we assume that is final and that if issues occur outside of its borders, they should be ignored? Test planning based on user stories is a constantly evolving documentation – only through continued development and testing is some issues arrive that weren’t considered in original scope. That is normal. Exploratory testing aims to catch these type of issues before they cause endemic problems in the system. What the stakeholder wants is important – but they are not going to be impressed by pedantic attitude of “well, you asked for it, so you got it”. To test firmly within boundaries is a risky business, becasue you are making dangerous assumption on the quality of user stories/requirements. I was always taught that you test requirements too. And you raise bugs against them if necessary, which in the days when business anaylsts were commonplace, was standard practice.
BDD (Behavior Driven Development) tools such as http://www.specflow.org, and Cucumber can help with exploratory testing, as with these tools, the person designing user stories will be more conscious of the requirement to code flow. BDD approach helps avoid the need for out-of-scope exploratory testing, as outside case scenarios can be addressed and included in earlier stages. The creator will be more aware of cases outside of their scenarios, as code generated can be reviewed as user stories as worked on. These tools encourage earlier reivew between analysis and development, but generating pseudo code based on user story input (which of course means requirement to code is traceable and more likely to be accurate to begin with. There is an overhead in planning/design stages, but less issues will be result. These tools developed from lessons learnt in Agile – the path from user story to code must be smooth and efficient, and if the user stories are properly integrated into the SDLC, then less basic mistakes will happen.
In specflow, this is how a user story is defined and broken down into scenario (which is turn can have 1 or more scenario outlines). This is nothing new fundamentally, but because the BDD workflow focus is heavily on the user story -> coding path. A major area of failure.
User story for a user dashboard, using Specflow’s BDD approach (the tables are decision tables – identifying test data prerequistes, and also examples of input/output).
Feature: Status Lights
In order to quickly view Section status
As Client User
I want a traffic lights type system to represent Section statuses
Given I am logged in as valid user
And I am on Homepage
And there are Sections and Sub-sections following the criteria in table below
| Type | Status | Worfklow |
| Sub-section | grey | Sub-section should be marked as no longer applicable |
| Sub-section | grey | Section marked as no longer applicable |
| Sub-section | tick | Final step in workflow has been signed off |
| Sub-section | green | Final step not signed off, and due date > 30 days away |
| Sub-section | Amber | Final step not signed off, and due date 7 days away |
| Sub-section | Red | Final step not signed off and due date 30 days away |
| Section | Amber | Step not signed off and due date 7 days away |
| Section | Red | Steps not signed off and due date <= 7 days away |
| Section | Red | Steps not signed off and due date already passed |
Scenario: Status Lights
Given has Section(s) in various statuses
And I am logged in as preparer or reviewer
When I view Company Status
Then Company Status displays according the Section(s) status
Scenario Outline: Company Status Lights Change
Given A Section contains "”
And Section has “” at either Sub-section or Section workflow status
When I view Company status
Then Company Status displays the lowest “” of “” of any Section
| Status | Rank |
| Red | 0 |
| Grey | 1 |
| Amber | 2 |
| Green | 3 |
| Tick | 4 |
Scenario Outline: Section Status Lights Change
Given A Sub-section contains “”
And Sub-section has “”
When I view Section status
Then Section Status displays the lowest “” of “” of any Sub-section
| Status | Rank |
| Red | 0 |
| Grey | 1 |
| Amber | 2 |
| Green | 3 |
| Tick | 4 |