Tag Archives: story

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.

BDD

“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.

Continue reading →

Fitnesse ATDD

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.
Continue reading →

BDD pain relief

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.
http://behaviour-driven.org/ItsAllBehaviour

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:-
Continue reading →

User Stories & Non-functional Requirements

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.

Non-functional Requirements as User Stories

Behaviour Driven Development

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

Background:
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 |

@StatusLights
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

@StatusLightsChangeCompany
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

Examples:
| Status | Rank |
| Red | 0 |
| Grey | 1 |
| Amber | 2 |
| Green | 3 |
| Tick | 4 |

@StatusLightsChangeSection
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

Examples:
| Status | Rank |
| Red | 0 |
| Grey | 1 |
| Amber | 2 |
| Green | 3 |
| Tick | 4 |

Agile Automation

Do you know something I never heard is “the project is finished ahead of schedule”, its always behind. Now I thought maybe this is down to over-optimistic planning, and so cursing project to be behind schedule right from the start. Certain seemingly minor dependencies grow into big ones over time as they start to affect other dependencies. One thing that can be planned, and be delivered either on schedule or ahead of schedule, Agile-run projects, simply because the whole outlook is one of blinding optimism, but solid processes. How good it would be to say to a client that the project is ahead of schedule, so if they have any other requirements it is possible to include them. Of course, I am not realistic – it is considered prudent to hold back on reporting too much progress, to give yourself a buffer zone for the unpredictable.

An optional element of Agile is test automation, but it is with automation that you really get the full benefit of Agile. Test automation is another part of the end to end process of delivering user stories/requirements in finished product. And not just unit testing, but front-end driven testing (the best way to validate user stories). But it is not a forgiving area – try implementing that kind of test automation too late, and it could hamper progress of project, and end up too much trouble than it’s worth. Test Automation can result in actually hearing “the project is finished ahead of schedule”, because good test automation process means less bugs, and far more bugs caught early.

But now start planning at the beginning; if tests are drawn up against user stories as they are done, then that means the test automation setup can run in parallel with development (in fact many of the developers unit tests can be utilised to speed up progress). This is in realms of BDD, but I do believe this should be a rule, rather than methodology specific. Always assume automation when writing test scripts, and user story scenarios to write them. They are what is to be tested, after all. This process means that everything in the chain is hanging tighter together. As development requirements change, as user stories may be added or changed, the test automation is updated as part of same process.

There are tools where you can do all of this in one bit of software, or a few tools hooked up together (Selenium/Fitnesse) has been a long favourite for Acceptance Test Management and test automation.  The user stories go straight to Acceptance Tests – important to keep the goal in focus. All the stakeholder is interested is progress, and if they need to worry – so they will be looking at user story history, generally percentage completion – maybe the test results. The Product Owner and Scrummaster will be keeping an eye on testing activities, and with something like Fitnesse or SpecFlow, can initiate automated tests with click of a button, by simply selecting user stories, or set of user stories, or just one scenario. Transparency is a favourite word in business at the moment, and Agile goes some way to provide it.

Agile Defect Management Lifecycle

Issue Trackingv12I struggled to find anything close to an Agile/SCRUM defect management cycle diagram, so have done one (click on thumbnail to see large version). What struck me as I was doing this, is it was largely no different to any other defect management lifecycle.  Just substitute the following.

  • Scrummaster=Project Manager
  • Product Owner=Client
  • User Story=Requirement/Use Case
  • Sprint=Release

The only addition I have made,  as it seems to be forgotten in most modern methodologies,  is the test manager role.   Developers need managing so it seems a little odd that it is assumed testers are basically just “developer pets”, according to Agile/SCRUM.   Not so – testers should have an impartiality, not be totally lost in same world as development.   I could be harsh here, and say that Agile is an excuse to get testers to do developers unit testing 🙂 but that would be churlish!