So I went to CAST 2010 in Michigan. It was a blast. Although, not so many people this year.
You never heard of CAST ?
Why - it is a wonderful conference, with a huge emphasis on CONFERring. So it's sold, and so it is also. I've been going three years in a row now and I keep learning from this conference.
One of the special things is that all the sessions are about half presentation, and half discussion. And discussions run far and deep too. In comparison to other conferences, you could actually attend them and not really speak a lot, except in the hasty breaks in between sessions. One or two guys would get to ask questions. Maybe they are not even good questions, but there's no more time. Then there's lunch, where you usually sit among total strangers, and you first need to find rapport and common grounds - usually small talk about the weather and the subway is the only conversation.
I mean, there's nothing particular bad in this. You hopefully get to listen to great presentations by smart people. Only - at CAST you get to participate.
I know this is described in different places, but I repeat it here: At CAST discussions are facilitated. That means that everybody (yeah - EVERYbody) get's a red, a yellow and a green card. One for commenting on the current thread. One for signalling that I've got a new thread. And the red card for: I really, really need to speak right now!
And you probably think: ...a forest of red cards.. Oh no. You forget - CAST is facilitated. The facilitator (and they are pretty good at this) keeps track of who wants to speak (and will take away your red card if it is abused). If you've got something to say you get your place in the queue. It works. Threads are followed as long as there's energy and if you raise a card, you get to speak.
Again: this works. People talk. A lot. Even for long. Questions are never: yes/no. It's always a looong story. Seems like all have something to say. And the conference is truly trying to support this.
Lunch is pretty interesting too. You probably met people before. Maybe even argued with them. Makes talking to them much more interesting and fun.
This year I was lucky to present myself. Twice, even (which is a bit more stressful than I expected). We got pretty good reviews (I wasn't alone on either talk). One talk - Dealing with passionless testers (with Henrik Andersson) - ended with a great discussion. We didn't get through all the stuff we planned, and I was kinda sorry for that - then. Now when I think about it - we did trigger a very deep, valuable, sometimes very personal, debate. We used a small film to kickstart it. It's on youtube. Find it! If you're a good tester, you can! :-)
The other talk - Nice words are not enough (with Louise Perold) - about introducing session-based testing and exploratory testing in projects, went great, but I think it suffered a bit by being the last thing on the schedule - apart from the ending session. People was just a bit tired - or maybe exhausted ? But we still had a good, long discussion.
I do hope I can make it to CAST next year again. I don't know if it's possible but I hope. Because I am anxious to learn more and meet more cool people.
Meanwhile I will have to settle for EuroSTAR - in Copenhagen this year. I hope you signed up! I'm talking there too! "Session-based testing in practice". A sort of SBTM 101. I'm excited. It's just about my favorite subject in testing.
Thursday, 2 September 2010
Sunday, 7 March 2010
Software testing and amphibious attacks
Once in a while it's difficult to hit the kill-button on the remote while show after show rolls over the screen. Occassionally something interesting comes along. This time it was an analysis and review of two famous marine assaults, their planning, strategy and outcome.
What struck me in particular was the strategy, which resembles very much what we do in software testing.
The strategy for the marine assaults was laid out to contain objective, intelligence, approach, assault, lodging and break-out.
Here's how that goes for software testing:
Objective
This is what we want to accomplish, in short our mission statement - the entire purpose of the operation. Usually we talk of it as a want of demonstrating the systems functionality, or that it will break, or figuring whether it is or isn't vulnarable to a certain threat or risk. But like an army we actually want to conquer and gain control. Marines deals with territory. Software testers deals with information and knowledge.
Intelligence
Once we put our eye to what we want to do, we need to start gathering intelligence, or information. We need to figure whether it's actually possible. No good landing on a beach full of quicksand, right ? Just as bad to base your test on getting data from an external system you can't reach in the test environment. In a way this represents our first test results, but it's just what is needed to sanity check our plan.
Approach
Sure if you're about to land an army at position X, you need to transport it there, without getting sunk, hit or devastated before you reach X.
Likewise in testing - we need to find a way to approach what we're searching for, in a way so we will have all the necessary power and initiatives ready for the actual assault. In other words, we need to prepare test data, user priviliges, test environment and so forth. If we've decided to try to print 1.000 tickets, then we should make sure that the system contains 1.000 tickets in a state where they are ready to be printed.
Assault
How do we do it ? Land the full force in one go ? Establish a single, narrow bridgehead, or spreadout for a simultanous attack on several weak spots at the same time ? It's different from approach, which we can plan ahead and even refine in detail. During the assault we must be agile, open, observant and ready to change direction, method and toolset. Until now we've only modelled the 'landscape', so when we set our foot there, surprises are to be expected. This is also what makes this very interesting.
Lodging
We never really think of it, but of course we have to settle down in the newly won territory. We need to make ourselves safe and enable logistics. We need to transport data (troops and supplies) to the frontline. We need to examine the new ground we conquered. Isn't that what we do ? The first login is always a bit trembling. Soon we login and go much further without blinking. And while some testers will be operating on the frontline, others will have to take on the tasks of creating more test data, hooking up new equipment etc etc. Logistics necessary to keep the operation going.
Break-out
This is the one that makes it all fit together - we can't stay on the beach forever. We can't live with a frontline three miles into the country. We need to 'break through' and finally accomplish our goal. Marines don't establish a bridgehead on a beach just to claim the beach. They do that in order to accomplish something more. Now we've invaded the system, we need to find the weak spots and/or the opportunities to carry on, to conquer the remaining part of the system, so to speak.
I think this is a brilliant way of putting together a strategy, also for software testing.
Don't you ?
What struck me in particular was the strategy, which resembles very much what we do in software testing.
The strategy for the marine assaults was laid out to contain objective, intelligence, approach, assault, lodging and break-out.
Here's how that goes for software testing:
Objective
This is what we want to accomplish, in short our mission statement - the entire purpose of the operation. Usually we talk of it as a want of demonstrating the systems functionality, or that it will break, or figuring whether it is or isn't vulnarable to a certain threat or risk. But like an army we actually want to conquer and gain control. Marines deals with territory. Software testers deals with information and knowledge.
Intelligence
Once we put our eye to what we want to do, we need to start gathering intelligence, or information. We need to figure whether it's actually possible. No good landing on a beach full of quicksand, right ? Just as bad to base your test on getting data from an external system you can't reach in the test environment. In a way this represents our first test results, but it's just what is needed to sanity check our plan.
Approach
Sure if you're about to land an army at position X, you need to transport it there, without getting sunk, hit or devastated before you reach X.
Likewise in testing - we need to find a way to approach what we're searching for, in a way so we will have all the necessary power and initiatives ready for the actual assault. In other words, we need to prepare test data, user priviliges, test environment and so forth. If we've decided to try to print 1.000 tickets, then we should make sure that the system contains 1.000 tickets in a state where they are ready to be printed.
Assault
How do we do it ? Land the full force in one go ? Establish a single, narrow bridgehead, or spreadout for a simultanous attack on several weak spots at the same time ? It's different from approach, which we can plan ahead and even refine in detail. During the assault we must be agile, open, observant and ready to change direction, method and toolset. Until now we've only modelled the 'landscape', so when we set our foot there, surprises are to be expected. This is also what makes this very interesting.
Lodging
We never really think of it, but of course we have to settle down in the newly won territory. We need to make ourselves safe and enable logistics. We need to transport data (troops and supplies) to the frontline. We need to examine the new ground we conquered. Isn't that what we do ? The first login is always a bit trembling. Soon we login and go much further without blinking. And while some testers will be operating on the frontline, others will have to take on the tasks of creating more test data, hooking up new equipment etc etc. Logistics necessary to keep the operation going.
Break-out
This is the one that makes it all fit together - we can't stay on the beach forever. We can't live with a frontline three miles into the country. We need to 'break through' and finally accomplish our goal. Marines don't establish a bridgehead on a beach just to claim the beach. They do that in order to accomplish something more. Now we've invaded the system, we need to find the weak spots and/or the opportunities to carry on, to conquer the remaining part of the system, so to speak.
I think this is a brilliant way of putting together a strategy, also for software testing.
Don't you ?
Subscribe to:
Posts (Atom)