Paul Gerrard's blog
Huib Schoots asked me to name my top 10 books for testers. Initially, I was reluctant because I'm no fan of beauty parades and if an overall 'Top 10 Books' were derived from voting:
- The same old same old books would probably top the chart again, and
- Any obscure books I nominated would be lost in the overall popularity contest.
So what's the point?
Did you know? We’re staging some webinars
Last night, we announced dates for two webinars that I will present on the subject, “Story-Based Test Automation Using Free Tools”. Nothing very exciting in that, except that it’s the first time we have used a paid-for service to host our own webinar and marketed that webinar ourselves. (In the past we have always pitched our talks through other people who marketed them).
This tutorial suggests that rather than being a document, test strategy is a thought process. The outcome of the thinking might be a short or a long document, but most importantly, the strategy must address the needs of the participants inside the project as well as the customers of the product to be built. It needs to be appropriate to a short agile project or to a 1000 man-year development. It has to have the buy-in of stakeholders but most importantly, it must have value and be communicated.
Many thanks to the Eurostar folk allowing me to present the webinar, "Live Specifications: From Requirements to Automated Tests and Back". This talk describes how we think companies can implement continuous delivery and live specifications using the Behaviour-Driven Development approach and redistributed testing.
This video tutorial for the Business Story Manager product is in two parts.
The first few minutes shows a short presentation of the approach to managing business roles, personas, requirements and stories. The remainder of the video demonstrates the Business Story Manager facilities that support the core Business Story method.
A couple of weeks ago I gave a talk that included a couple of slides that focused on the idea of Specification by Example and how it cannot be relied upon to fully define the functionality of a software solution. I thought I'd summarise it here while the thought was fresh in my mind and also because Martin Fowler recently re-posted a blog originally published some time ago.