Specification by Example helps even with no Automation

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

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

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