Eurostar > Day 1 > Keynote 2: Monty Python’s Flying Test Lab – Rob Sabourin

Eurostar > Day 1 > Keynote 2: Monty Python’s Flying Test Lab – Rob Sabourin

Great start to Rob's talk, despite a few technical faults…, great clip from Monty Python


Great example of Ambiguous Requirements. Don't we see this often in testing where we ask for clarifications.

Rob suggests we build a model and take to the customer to build this model. Instead of "your requirements are wrong" try to build a model with them to open channels of real communication. Concrete communication with checks and balance. "Is that clear" <– you haven't communicated anything – make it explicit.

Other ways from the crowd….."ask why?" "Paraphrase" "Provide a structure for requirements that need to be filled in (template) (Rob not so sure)" "Don't express your tests in a semantic language"

Next one up: The Witch scene:


Rob –> You could almost make a University of course of lessons learned from this clip.

We blindly trust the tool……just like they did when the witch weighed the same as the duck. Rob S did a mini rant on testing tools…when it tells you something, it must be true. Great point.

The chain of logic is something that people follow, even if the logic is wrong. Watch out for false logic and incongruent chains of reasoning.

In testing we check one thing and draw a conclusion.

Rob looks for three ways to judge correctness:

Look at the value on the screen, in a report and in the database.

Having a sticker doesn't make you a tester. How you apply your knowledge to solve problems makes you a tester. A hidden lesson from Rob about applying a cert or label or sticker to someone.

Clip 3


Dev teams would build software and then throw it over the wall at the test team. Lessons learned from Monty Python.

Great presentation.

Eurostar > Day 1 > Keynote 1: Putting Tradition to the Test – Antony Marcano #esconfs

Antony Marcano presented about:

Tradition. The news of Mr and Mrs Anderson Williams having a baby and the fact Mrs Anderson Williams would not be staying at home to look after baby. Traditions change. That's what she told her disgruntled mother. Time have changed, traditions and roles have changed, things are changing, morphing and evolving.

Antony draws the comparison to Agile Development and how our roles should change. If our working environments are changing then why are we hanging on to old roles, for old methodologies, for old teams?

What does a test manager do now teams have dedicated testers? Change their role and learn about testing, become a thought leader, become a practice manager and guru. That's what.

Antony then talks about special service teams whose team members are essentially cross functional, yet with specific specialities. Antony introduces us to a special forces process of clearing rooms from enemies. Each member is a specialist, but they know what the others do; they can switch roles easily. Antony draws a comparison to project teams and cross disciplinary, cross functional abilities.

The final story was about Nicole. She was a software tester. She started working in a government department full of ISO, IEEE and compliance. Documenting everything. Triple checking. Covering herself for blame. But she did enjoy it and the testers were passionate, but she decided to move on. She looked in to agile but couldn't see how this could work. She got a job though working for an agile consultancy company looking to move in to government departments.

1st day was iteration planning. Wow – what a way to start your deep dive in to agile. Trouble is they had no test plan. So she got out the trusted old style Test Plan, filled it in and sent it off to the team for review. Nothing back though. Nothing at all.

The problem was she sent it by email, and it turns out they don't check their emails. They concentrate on just building stuff. Not checking emails.

The manager drew a few diagrams on the board and showed her an architecture diagram, making a point that she needn't have dropped all of that information in to a document. The test plan was on the wall. 15 – 20 minutes was all it took, not hours.

My question would be is how do they communicate that to the customer; this big gov agency? Don't they require certain sign offs, approvals, assurances? How can this team be sure they communicate with the right purpose, audience and context? Lots of unanswered questions and the point seems to be about format of communication (i.e. drop email) than about what might actually be needed. Good example, but missing a few points 🙂 Collaboration is key is what Antony is suggesting – couldn't agree more, but collaboration can only happen when communication is great.

The Epilogue.
Nicole got loads of experience at agile and apparently even spoke at a previous Eurostar event.

Great opening talk by Antony, but the audience are indeed very quiet and, at the moment, a little shy. Antony's delivery is a little more rigid than I've seen him before, but the crowd is large and yep, he's opening the proceedings. Really clear presentation, great use of visuals too. Good start to Eurostar 2010.

Cannot Reproduce

Image from : viZZZual

Call me old fashioned, but in all of my years working nothing has beaten a good old face to face conversation with a developer about an issue or bug in the software. Using a bug tracking system as the primary means of communication is a “no no” for me.

Yet, last week I was chatting with a seasoned test manager who was extolling the virtues of bug reports. Now, I’m a fan of bug reports (in moderation) and I’m a fan of tracking issues (though not necessarily in a bug report) and I’m also a major fan of communicating clearly, but I also like to get things done with the least amount of friction. But this test manager was suggesting that bug reports are the single best form of communication between developers and testers and therefore every single bug should be logged in a defect tracking system mainly for no other purpose than communication. Communicating through bug reports is “fundamental” apparently. 


In my view, communicating through bug reports is a sign of some deeper issue within that organisation. If you are using a lifeless remote system to communicate between two humans as your primary medium of communication then you are destined to have lost meaning, wasted time and rework. You have a problem.


When we write things down we often (not always) lose information and more often than not, in the case of defects, waste lost of time bouncing bugs backwards and forwards when a simple conversation might have cleared the whole thing up. It often means the bug reports themselves are more thorough and complete when the developer and tester have chatted about the issue in advance. Now I’m not adovcating badgering a dev each time we find something, but I am suggesting we stop and think about how best to communicate the issue. Think about The Purpose, The Audience and The Context.

Would it be easier and quicker to show the dev the issue and talk it through before raising a ticket for it?

Or would it be easier to raise the ticket and then talk it through?

Or would the ticket clearly explain the issue without talking it through?

Or should I raise the ticket and then sit back and wait for the inevitable bounce back with “cannot reproduce” or “as designed”?

Or do we even need a ticket in the first place?


Here’s an over the top example, but scarily it’s not far from the reality I’ve seen in the past,.

Read More

Yes Testers, even we are in Sales

You’ve heard the saying “Everyone’s in Sales“. Well, it is indeed true. Whether we are selling our skills at a job interview or selling a defect (to be fixed) to the team or selling a new idea to the management, we are in sales.

We are also in Sales when we sit down to test software. Producing good software that people want to buy is a holistic approach, right from the Business Analysis, through the coding and testing to the marketing and sales departments. It’s a holistic package. Something many of us in business often don’t see.


David Ogilvy wrote in “confessions of an advertising man” – “In the modern world of business, it is useless to be a creative, original thinker unless you can also sell what you create. Management cannot be expected to recognise a good idea unless it is presented to them by a good salesman”

The same goes for selling defect fixes, process improvement and new ideas about testing. Delivered by a good salesperson any idea could be a good one..maybe.



Well, here’s the ever passionate Tom Peters talking about the same thing:

[vimeo w=500&h=283]


Big thanks to Garr Reynolds [Presentation Zenfor posting about this video over at his excellent blog



Translated in to Russian – I’m honored

I do feel honoured indeed to have had a blog posts translated in to Russian for the very excellent community. Very honoured indeed and it was great to be in touch with Alexei Barantsev from the community. I love what they are doing in the community. It also looks like the Russian testing community has some very exciting training and learning initiatives, so if you’re in Russia and want to learn more then check them out. I get a sense I may need to brush up my Russian language skills 🙂


Sharing your testing learning…and raising money for charity too

Over at The Software Testing Club we’ve got a little community project running to raise some money for Oxfam this Christmas time. It involves you filling in a short form which we’ll collate together with some other fresh content later this month. Once out, it’s yours to download. all we ask is that you give a little donation to charity (although it’s not required to download the ebook). If you’d like to be involved then head over to the clubs blog for more: