I’m keen on Specification by Example particularly with a tool like Cucumber to automate tests. However this style of specification is also useful without the automation. I introduced my current team to Specification by Example and, with some help from me, the customer is now using the same disciplines to define requirements to hand to a 3rd party development shop. The experiment has been very successful.
Continue reading
Tag Archives: scope and requirements
Abuser Story – User Stories to Prevent Hacking
A couple of years ago Mike Cohn introduced me to a cute concept. The “Abuser Story”. A User Story to prevent abuse.
Continue reading
DRY Gherkin: When Using Cucumber, Keep Your Step Definitions DRY
When using Cucumber for automated testing I try to ensure my Gherkin uses ubiquitous language so the business and development team share a common language. But the Gherkin must also be DRY. This not only saves confusion but also saves development effort.
Continue reading
What do you do when the business imposes an arbitrary deadline?
My business stakeholders wanted the product launch to align with a major event in the political calendar – happens to have been the state opening of British parliament. The product was all about politics so launching simultaneously with a major political event made perfect sense to the business folk. The trouble was that this was just an arbitrary date as far as the development team was concerned. What do you do when the business imposes an arbitrary deadline?
Continue reading
Plug for Henrik Kniberg’s Agile Product Ownership in a nutshell
Just a small plug for Henrik Kniberg’s video Agile Product Ownership in a nutshell. Genius. Watch it.
Continue reading
Three Amigos Meeting – Agree the tests before development starts
“Three Amigos” is what Matt Wynne calls the meeting to discuss the Gherkin scenarios before development starts. The Three Amigos involves the business, development and testing voices. However who turns up, where they meet, what they produce in the meeting, the homework to complete after the meeting, and who does that homework can all vary depending on the particular team.
Continue reading
Declarative vs Imperative Gherkin Scenarios for Cucumber
Everybody I’ve met that is new to Gherkin starts with an Imperative style of scenarios. The Imperative approach is simple and intuitive and reflects what manual testers do. But I hate the Imperative style with a passion. I favour a Declarative style of scenarios not least because a declarative style means I can test business rules. The UI is prone to change but the business rules tend to be more stable.
Continue reading
Whose responsibility is testing anyway?
I have a painfully small manual test team, sometimes 1 tester per 15 developers. The answer to the obvious question “who tests?” is “mostly the developers”. Of course this only works if you’re doing extensive automated testing including Specification by Example with a tool such as Cucumber.
Continue reading
When Buckets Go Bad
I use the term Bucket Planning for Release Planning. The metaphor works because buckets overflow if overfilled. There are risks associated with Release buckets corresponding to Minimum Viable Products (MVP). A large MVP bucket has gone bad and a MVP Bucket that continues to grow is a Bucket gone really bad.
Continue reading
What to do when Scope is Fixed
Sally was a prospective customer of mine. She worked for a high profile but rather old school company and wanted a fixed price contract. Sally genuinely thought her business analysts had nailed down the scope and was confident nothing would change. From her perspective all I had to do was price the work and deliver the product. Sounds perfect except Sally was wrong. My experience is that, fixed price or not, scope is never fixed. Pretending nothing is going to change is a form of self-delusion. Sally was deluded. What should I have done?
Continue reading