Obviously the kids had a blast with the cows, and my oldest son made me proud by showing off his cow-milking skills, or at least how he’s not afraid to try

My son & our guide milking a cow

How is this related to testing???

Let’s start by saying that after having done both these jobs during my professional lifetime, milking a cow is nothing like testing software.

Still during the visit we learned something that reminded me of how we should always look for alternative (and sometimes unconventional) approaches to solve our biggest testing challenges.

Solving the “Hardware Disease” in the Dairy Industry

Did you know that there is such a thing as “Hardware Disease” that harms dairy cattle?  (and NO!, it is not related to a cow using a mouse and hurting its wrist in any way!!!).

Based on what they explained to us in the farm, up to some years ago close to 1% of all dairy cows would die as a result of eating metal objects (together with the hay) that would get in their stomachs, perforate them and cause large internal bleeding.

To solve this issue they first tried to develop technology that would “find and extract” all metal objects from the hay before feeding it to cows, but this approach proved both expensive and impractical.

An actual “Cow Magnet”

Then, someone though about an unconventional approach: ”Instead of fetching them before they are eaten, let’s prevent the cows from dying even if they ingest these metal objects”.  And they came up with the idea of feeding cows a relatively small but powerful Cow Magnet that would sit on their “second stomach” and catch metal objects before they would cause any harm to the animal.

As weird as it sounds this solution worked, and it is now widely used in the Dairy Industry saving thousands of cows a year world wide.

Looking for our own “Cow Magnet” solutions

Now let’s get back to testing…

How many times have you gotten stuck trying to solve a problem using conventional approaches instead of trying to think “outside the box” looking for unconventional wisdom?

When this happens it is usually because you are focusing on the wrong problem, like in the case of the cows where they tried to tackle the issues of the metal objects instead of focusing on the death of the cattle.

Let’s use an example of a testing challenge and how we solved it to explain what I mean.

A “Cow Magnet” to solve DB migration failures

Long before I started working in PractiTest, I was managing the QA for another enterprise software company.  The product I was in charge of testing ran locally on our customer’s servers (this was before the world learned about the advantages of SaaS software!), and we had thousands of installations world-wide, ranging from a handful of licenses and all the way to customers with thousands of end-users.

We had a problem in this company.  Each release (once or twice a year) we had to migrated the database to a new schema, and for a large number of the customers (who had made modifications mainly to create their own reports) this meant that their “version upgrade” would get stuck during the db migration phase, and they would need to get someone from our support to manually “fix” the issues and complete the migration process.

This resulted in large number of organizations that were afraid to upgrade, and our product quickly started getting a bad reputation in the field.

In the beginning we defined the testing problem as “been able to generate all these db customizations internally in the lab”, but after 2 releases of trying this approach the results in the field were still disastrous.

Then we started searching for our “Cow Magnet”, or in other words we re-defined our challenge this time to “making sure as many of the problematic databases would be able to migrate successfully”.  Notice that instead of focusing on the “testing artifact” we focused on the problem from the perspective of our users, and this was the big breakthrough.

We got in touch with our support team and asked them to contact all customers who had experience migration issues in the past and ask them if they would provide us with a copy of their databases.

We got our hands on close to 40 such projects (only about 1/3 of the organizations agreed to send us their DBs) and we created an automatic framework that would run the upgrade on all of them once a week verifying the results of this operation (a simple pass or fail test), and informing Development whenever one of their changes “broke” the migration.

By running these tests we found that each release had only between 10 to 20 operations that would be responsible for most of the migration issues.  And within one release we reduced the upgrade issues from around 6% to less than 0.3% of all upgraded projects.

Three quick methods to find your “Cow Magnets”?

Looking for your “Cow Magnet” is not hard, and the main challenge is to re-define your problems in a way that will let you find “other” possible solutions.

Following are three methods I use to achieve this.

Method 1 – Look at the problem from your user’s perspective

This is the simplest method and one you can even do by yourself, simply try to put yourself in your customer’s shoes and think how he sees the problem.

Like in the example above, the user didn’t care the problem was caused by his customizations, he simply wanted his project to be migrated successfully.  Or in the case of the dairy farmers, they didn’t care about the pieces of metal, they simply wanted their cows not to die.

Method 2 – 5 Whys

To quote Wikipedia on it:  ”The 5 Whys is a question-asking technique used to explore the cause-and-effect relationships underlying a particular problem.  The primary goal of the technique is to determine the root cause of a defect or problem…”

Basically, take some of your peers and write down the problem you are trying to solve on a whiteboard, then ask WHY?  (e.g. why are looking to take out the metal objects of the hay, or why are databases failing to upgrade?).

Write the answer/s you got, and ask once again the question WHY?

Repeat this process 4 to 5 times and you will get to the source of the issue you are trying to solve and hopefully to more ways how to solve it.

Method 3 – Brainstorm with other members of your Organizations, but not from your own team!

This might be the most effective method since it will give you the broader results, but it is also the most time consuming, so use it only when the problem you are looking to solve is important enough.

Set up a meeting where you bring people from other teams in your company such as Support, Sales, Marketing, Finance, HR, etc.  Then perform a brainstorming session with them around your problem (you can use the 5 whys, or any other brainstorming method you like) and try to bring as many ideas as possible into the table.

The advantage of this method is that it will provide a lot of varied approaches that are not biased by the technical nature of the testing and development teams.

Have you come up any “Cow Magnets” in the past?
Share them!!

An additional example that comes to mind is the tale about the Russian Space Pencil: As part of the Space Race it became apparent that pens (that work based on the principle of gravity) don’t work in outer space.  The Americans spent millions of dollars developing a pen that would work on Zero-G conditions (and also under water, at extreme conditions or cold and heat, etc), while the Russians simply gave their cosmonauts pencils… (BTW, this is apparently only an urban legend but still drives the point home)

Have you come up with “Cow Magnets” of your own?
Share them with us and give additional ideas on how to go around solving problems using unconventional approaches!

(*Image by FreeDigitalPhotos.net)

I have 3 kids at home, and I’ve never heard any of them say something like that.

Up to now I’ve heard them say that when they grow up they want to be: a Doctor, a Policemen, a Firefighter, a Princess, a Veterinarian, a Dancer, a Soldier, a Bus driver, a Tractor driver, a Builder (or more specifically Bob the Builder!), they want to be Mickey Mouse, or Minnie Mouse, or Strawberry Shortcake, or Smurfette, or even Tom & Jerry…

But never have I heard them say that when they grow up they want to be a Tester.

Testing is a grey profession

I guess after all testing is what they call a “grey” profession, or something that does not sound very exciting to kids; maybe it doesn’t sound very exciting to many grown-ups either?

On the other hand, there are many other “grey” professions that have enjoyed a surge in interest after getting some bright-color-lights in TV series or Hollywood movies. For example archeology after Indiana Jones, crime-scene investigaion after CSI (NY, LV, Miami, etc), pathology after Bones and NCIS, etc.

So maybe what we need to change the way people perceived testing is to come up with a TV series describing the work and adventures of an amazing team of clever software testers…

How would a TV series about Testers look like?

Let’s imagine a chapter out of our new TV drama:

T-G-I
(Testing Geeks Incorporated)

Scene 1 – Intro

The phone rings in the middle of morning, while the testing team is going over a regular task in the office (to make it look cool, let’s assume they are testing a multi-player virtual reality game of sorts).

One of the guys answers the phone and on the other side of the line there is someone asking for help with a very big and important problem.

The team scrambles to the Video Conference room and start a call with their customer, the Department of Defense.

In the conference a General explains the current crisis, half their users (including under-cover agents in enemy countries!) are not able to work with their encrypted communication software and are basically in the dark.

The General even shows how, when he tries to open this program on his laptop, he gets a general error message saying the system has performed an illegal operation and will shut itself down immediately.

The situation is critical and they need the T-G-I team to get in quickly and find the bug right away!

Scene 2 - The team goes into action

Our team of testers (two guys and two girls wearing jeans, sneaker and cool t-shirts) gather their equipment in their backpacks and scramble out of the office in a hurry as a military chopper lands on the lawn in front of their office, picks them up, and takes off without even slowing down its rotors.

They land in a military base and get out running towards the General who is waiting for them in a Jeep.  He greets them and drives them into a secrete facility deep within a mountain cave.

Once inside the team divides into 2 groups.  Team A will make a detailed analysis of the logs and the information gathered by the IT department, trying to look for clues on the bug.  At the same time Team B will take a more “holistic” approach, playing with the bug itself and talking to some of the users who are experiencing the issue.

Scene 3 – Understanding the issue

We follow the “holistic” Team B as they interview a couple of communication technicians who were the first to report the bug.  They use a heuristic-guided method to question them and gather information about the system and the problem at hand.

The technicians (a couple of Army Privates in charge of processing coded messages from the Middle East) explained that it all started 2 days ago when they got into their post to start their shift and one of the guys was not able to log into his communication program, he tried everything he could think of but nothing worked.

The strange thing is that a couple of hours later, when he got back from a smoke break he tried once again, and this time he was able to log in and work with it.

Then later in the day it started happening again, but this time it happened to both of them simultaneously.  And when they reported the issue to their IT it appeared that at least half the base was experiencing the same problem.  Many operators and officials where not able to log into their communication platform!

Some users are not been able to connect at all, while others manage to connect sometimes.

They tried login in and out of their computers, modifying hardware, everything!  Sometimes it helped for a number of minutes but then it stoped working once again.  In fact, nothing makes sense to them.

Our testers ask to see one of these machines where things work intermediately.  They play with it a little bit and install a service that will let them get more information. Then they ask one of the Privates to start working normally while they observe his operations from behind.

After a couple of minutes of work the error message pops up once again! But this time our testers are prepared and they move quickly to take charge of the machine.

They open the application they installed, that was gathering information on the system as the user worked, and start reviewing the activity log.  After about 3 minutes one of our testers points at a specific line on the screen while the others nodes her head in agreement and smiles.

They run a couple of commands on the machine, then ask the user to try to run the program once again and “PRESTO!”  The error message disappeared, while the IT guys who had been in the room all this time look in awe and disbelieve.

Scene 4 – Finding a solution

In the meantime Team A, the detailed analysis team, is gathering information about the latest upgrades installed on the system and the base.  They check all maintenance logs and updates, as well as client software maintenance that have taken place in the last 72 hours.

The IT clerks report that nothing out of the ordinary was done in the last 3 days, or in the last 3 weeks for that matter.  There were no major upgrades or any kind maintenance done.

As the testers start going over the routine upgrade list and cross-reference the actual components (libraries and executables) they get a call from the “holistic” team informing them about their break-through.  The “analysis” testers ask for the the list of processes they got from the internal monitoring agent and also to come and join them in the IT offices.

Based on the new information they modify their search and start analyzing all the data available once again.

The “holistic” team comes and join in on the search. After a number of minutes one of the testers finds something that looks interesting and calls to the rest of the team to come and see.

She is not sure about the exact details but she remembers reading something about a component on the list some months or even years ago.  With the help of another tester they start “googling” this information, searching for blogs, articles or release notes on the the specific component, and within a couple of minutes one of them shouts “EUREKA!  I found the problem and the solution!!!”

They download a file, give it to the IT technicians in the room and ask them to go to all the machines that are suffering the issue and replace the old file with the new one.

Scene 5 – Tying all the knocks together

The team gathers in the General’s office and quickly goes over their findings.

They explain that the source of the problem is a file that was been feed by the translating system that included some uncommon (but legal) characters in an old middle eastern language, and was causing some of the computers to get stuck while trying to load it to memory.

The problem was even worst because this file, that had been fed into the system 3 days ago, was been periodically loaded into the local memory by the program in order to make the system work faster, just like the rest of the files that were received in the last 2 weeks.

This bug had already been fixed a number of years ago by the company developing the Operating System, it was a small bug in one of the language libraries.  But since the computers used by his team and international operatives were disconnected from the Internet due to security measures, this specific updated had not been installed in any of the old computers as part of the regular software updates.

With this information in hand, our testing team simply provided the IT clerks with a new file that would immediately fix the problem.

BUG SOLVED!

Maybe not as good as Magnum PI, but what do you think?

Do you think we could persuade FOX to make this their next TV Drama?
I guess not but it was fun to write it anyway…

I am also not sure this is what would make any of my kids turn and tell me that they want to be a Tester when they grow up, but it surely makes our work look as a lot more interesting (and less grey!).

BTW, many of the facts on this story came from actual bugs I found and was able to reproduce during my years working as a tester (not the part of the secret base in the mountains, in case you were wondering…).

Do you have other challenges or ideas for our T-G-I team?
Feel free to share them as comments if you do!

- They don’t know how to say They CAN’T take that additional task and still meet the project’s original schedule.

- They don’t know how to say They DON’T have enough information to estimate how long it will take them to test the product.

- They don’t know how to say that The product should NOT be because they have not finished running the tests that cover the relevant features.

- They don’t know how to say They WILL NOT accept the build because the developers didn’t run their sanity tests.

- They don’t know how to say that The testing phase of the project WON’T finish on time because non of the previous milestones was met according to schedule.

Are you a YESaholic?

I know about these problems because I used to have them myself, “Hello, my name is Joel and I am YESaholic“.
For those of you who never heard about this term, a YESaholic is a person who is addicted to saying YES and can’t say NO when asked if he can do something.

I admit it, I don’t like saying NO when asked for help. I like to take-on all challenges and be the best of palls to all my coworkers, and this attitude usually lands me in hot-water for accepting more tasks that I can handle or for taking responsibilities that are not mine.

Back when I started my testing career I could not understand how it was possible to work under all the pressure of being a tester:
- Providing estimates to features I couldn’t understand based on the information provided to me.
- Trying to run all the tests and finish on time, even when the builds where delivered weeks late and with quality bellow any level of expectation.
- Helping every sales person, support engineer and developer in their tasks but never accounting for this work when planning my testing schedule.
- Working nights and weekends when developers where not even around to help me troubleshooting the bugs as I found them.
- Taking ownership for all the bugs and accepting to release the product even when I had not finished my testing cycles.

Providing a good service doesn’t mean saying YES to everything

After thinking hard about it I understood the problem was not in the testing tasks but on how I was approaching my job as a Tester and a Test Manager.   I always felt that testing was a service to be provided to the rest of the organization and as such it was my job to SAY YES WITH A SMILE.

My task was not to make everybody happy, but to provide visibility into the product and project we are working on. Uncovering issues, providing feedback into the areas where the development should focus their work, and helping product owners and project managers to decide whether the application was on track based on its release objectives and schedule.

The only way to do this is if we take our job with the top most seriousness and we learn to say NO when we need to.

You need to say NO when you don’t have time to help someone else. You can say YES, but only if you delay the task you are working on and the project team agrees with this delay.

You need to say NO when someone asks you if it’s OK to deliver a build late or to receive it even if no sanity tests were run by the developers. Or you can learn to say YES, but make sure the project teams knows that the schedule is no longer valid.

You need to say NO when asked not to run a set of tests in order to meet the schedule. Or say YES, and make sure everyone understand the risk for deciding not to verify a specific area or feature in the system.


You need to learn to say NO when you cannot say YES confidently, and understand there are times when saying NO is the most professional thing you can do. It doesn’t make you a bad team player, a bad tester or a bad friend.

Rob is asking testers to write up post it notes with why they like testing and send them to him.

So last night I spent about 45 minutes contemplating this question, and when I didn’t come up with anything useful I just went to see re-runs of Tourchwood…

But this morning I had one of those EUREKA moments, and all of a sudden every became clear once more.

I enjoy the interaction with all the project stakeholders, from customers and product owners and all the way to developers and project managers.  I like the fact that my job is to work real close with all of them and serve as a bridge that allows the project to get done correctly.

I also enjoy the hunt, and the adrenaline of the projects, etc.  But specifically about testing it is the pivotal role within the organization.

This means I can send my picture to Rob.  Now it’s your turn to think about it, write it down and send the picture to Rob too.
Why do you like Testing???

What we like most about the magazine is that it’s fresh, cool and different.  Starting from the large number of new names who published their articles and all the way to the fun stuff such as the tester cartoons by Andy Glover, the blogs and even the conversations that are included inside inside.

A lot of people worked hard to make it happen, from the authors who submitted the articles and the rest of the pieces, and all the way to Rosie and Rob who literally spent days and nights to get it published.

THANKS, YOU DID A GREAT JOB!

Now I can’t wait to see what will come out in the next edition…

I had not played Sudoku until about a month ago when I was stuck in a boring meeting and the only thing left in my BlackBerry (after being done with mails) was the Games Menu.

By elimination, and since I had never played it before, I decided to give Sudoku a chance. I choose the MEDIUM LEVEL, after all I was only trying to understand how it worked, and bum!
I got hooked.

Putting aside the addictiveness of the game itself, there are some pretty good attributes to Sudoku that are fundamental to every tester out there.
Naming only a few:
- Analytical pattern recognition
- The ability to look at what is there, and concentrate on what is missing
- Focusing at a problem from multiple angles until you find the thing you were looking for
- Even how to handle sisyphic tasks that not always end in success

There are many games that can be used in order to evaluate and even develop your professional abilities as a tester.

For example, “Where’s Waldo?”
I remember playing this game as a kid. It’s all about developing your eye’s capacity to find a needle in a hay stack!

You can even play Texas Hold’em poker on the Internet.
Weighting your hand while you try to figure out your opponents’ chances based on the open cards on the table helps you to develop your analytic capacity to extrapolate (and take risks!!!) under pressure.

There are many more games that can help you and your team do a better job as testers.
Remember that testing doesn’t need to boring or monotonic all the time…

Back when I was growing up social life was simple.

You defined your friends as the bunch of kids you played ball with or climb on trees in the park in front of your house. To be social meant to sit in the table and carry a nice face-to-face conversation with someone. Your pals were the guys and galls you went out for a beer once a week (or twice a week on a good week!). And the biggest social challenge you faced was how to fill your ego with the positive energy needed in order to ask the girl you liked to go out on a date.

Be My Valentine Charlie Brown

But today, Oh-Boy!

Being social is practically a full-time job!!!  No wonder people don’t have time for much else these days.

We have blogs, tweeter, professional networks, professional forums, social networks, Linked-In, Plaxo, multiple email accounts, multiple messengers, and the list of important media channels goes on and on and on…

If you want to be socially up-to-date you need to spend at least a couple of hours a day just checking all the information updated in these places, not to mention adding some information of your own in order not to be a silent listener (we all remember the Reebok commercial – Because Life is not an Spectator Sport!)

So here I am part of this new reality where.

-  I have MANY friends (not colleagues but friends!) I’ve never meet and live in places I haven’t ever visited.  We talk about work challenges and help each other in tasks; we are even up to date on all sorts of personal events and milestones.

- I am part of a great project to launch a testing magazine online with people I haven’t ever meet.

- I communicate with my best childhood friend using the BBN (this is the BlackBerry Network, for all you iPhone users out there), sending information and picts daily back and forward, and realizing we haven’t actually talked in close to 2 months!

- I talk to my parents using mails and messenger, and foward you-tube links to my brother to remember about stuff we used to see and do (and fight!) when were growing up.

- I go to conferences where all of a sudden someone comes to me and says “Are you JMG from QAForums? Well, I am <add username here>, we have been interacting for years!”

- My computer literally drives me nuts with all the tweet-tweet sounds once every 15 seconds or so.

- And on top of that, people get mad at me because they sent me a fish and a hug on facebook and I didn’t correspond by buying them a virtual drink (or something like that I don’t really understand)

Here’s the truth, I feel I am drowning under a surge of social media!!!

This stuff is like water, the right quantity is good for you and necessary to live and prosper, but once you get too much of it you are in danger of drowning (too much of a good thing?)

So this week I took a small first correcting step to take charge of my life once again.
I deactivated my facebook account. To tell the truth I hadn’t logged into my account in close to a year so it didn’t really make a concrete difference, but it actually felt good…

After I did that I talked to a friend considered by many (including myself) as a great example of a Social Tester, and he made realize this may be a case of becoming a kind of “Anti-Social” tester.

You know what…?
He might be on to something, and I think I like that direction!

So here’s my early New Year’s resolution:
From now and until the end of January I will closely examine all the social media networks, communities, sites, etc I belong to.
I will make sure only to be part of the limited number of communities that provide me with value (and where I fell I can add value too), and I will do my best to manage these channels and not to let these channels manage me.

Hello, My name is Joel and I am an Anti-E-Social Tester…

Let’s start with the QA&Test conference in Bilbao, Spain.
One of the warmest conferences I’ve been as a presenter; in-spite of the rain and cold weather outside in the city, the sessions and the hallways were a great and warm place to meet fellow testers and exchange information and knowledge.

Guggenheim Museum in Bilbao

If you are up to the challenge and understand Spanish you are welcome to check this short interview they did of me (Mae, I was expecting you to cut the bad parts…)
In short, QA&Test is a truly recommended conference.

Then I got back to the office where we really turned up the heat on our development (& testing!) process in order to release PractiTest’s latest update that included the first version of our Jira integration.  By popular demand (of a large number of our users!) this was the first integration we created.
So for all you Jira fans out there, come and get it!!!

The third update is that I am starting to get involved in a very interesting test automation project taking place on a company where Agile is not only their newest fad, but where they are really leveraging this philosophy in order to change the way they develop (and test!) software.
So, expect to read some stuff coming from that arena soon.

And finally the invitation.

I am honored to have being invited to provide a Mini-Track session on the upcoming Israel-SIGiST meeting taking place on November 24th.

The name of my session is “A bug is only a bug, right?  Wrong!” and I promise to provide some food for thought around the things we do and some we don’t with one of the main outputs of our work as testers, our bugs.

We arrived in the US on a flight from Costa Rica on a Sunday evening, I am guessing that my flight had something like 120 or 130 passengers and crew.  After disembarking we proceeded to the immigration section and right away noticed something was wrong.  There was a line of about 1,000 passengers; but while all the immigration officers were in their places no one was interviewing passengers, all were talking among themselves or simply resting and staring at the sealing.

When we got to the line we understood the problem as the person in charge of managing the line came to us and said: “Welcome to the US, we are sorry but the system is down“, then after seeing the frustration in our eyes she said this had never happened before and she couldn’t tell us how long we would need to wait.

Here I need to say that my wife is a genius!! Her maternal instincts immediately kicked-in as she told the line manager that we were traveling with 2 small children and had a 12-hour connection in less than 90 minutes…  this gave us direct access to the beginning of the line (and generated angry looks from many people standing in front of us).

When I got closer to the boots I realized how not-out-of-the-ordinary the immigrations computer system was, and how I had already seen situations like this happen to my clients and even to me as a customer.  From the conversations between the officers I understood that the system had fallen some 15 minutes before we arrived, the computers had frozen and they were not able to process any visitors.

During the next 20 minutes I saw how an “IT related officer” (on Sunday night you won’t expect a real IT geek to be around, right?) tried to troubleshoot the problem.  He went through the rest of the officers’ boots and asked them to do different operations based on a printed guide he had with him.  Stuff like resetting the computer, trying to access via a secondary account, taking out stored laptops and trying to log into the system, nothing seemed to work and everyone remained standing there.

The gateway to “the land of opportunity” was right in front of us but it was being blocked by a simple computer that would not connect to a remote system and allow it to make sure neither me nor my family were a “Persona non grata” in the US.

Then, all of a sudden something magically positive happened; one of the officers was finally able to log into his computer and regain partial access to the system.  It took him twice the time to process each person, but 10 minutes later we were able to continue our journey home by stepping out of immigration, getting our bags, rechecking them to our flight to Israel, and reaching the gate running 5 minutes before the final boarding call.

I imagine that in due time the posts managed to get back on-line and eventually all the people in the line, that by the time we left already numbered a couple of thousand, got through the system (or not!).  But this certainly changed the plans and trips arrangements for many passengers, some of whom arrived late to their homes while others must have certainly missed their flights altogether.

This is just another example of how we are all dependent and controlled by Information Systems (in more ways than we care to accept), and how a flaw in one of them can turn our day (or trip!) into mayhem.  Nothing we can do, but learn our lesson well and make sure that as Testers we add “alternative system access and recovery” scenarios to our test plans, to make sure other people will not need to suffer due to the fact that we did not foresee out-of-the-ordinary scenarios that will eventually happen to our systems under test.

My presentation itself went pretty well (I think) and many people agreed with the TI approach, no surprises there.  But the real value for me came from the people who initially thought the method was not doable (or even realistic!) for their workplaces since it involved to many changes and education of their management on this new approach.

Reviewing the subject together with them I got to understand that the best approach for deploying TI on large organizations is to do it gradually and from within, based on a slowly-progressing plan that would allow the organization to learn and adapt to it, enhancing the chances for success in these environments.

The Testing Intelligence paper and the presentation I gave are posted on the CAST2009 site.
If you get to read them and have any comments, please make sure to send them to me.

I also wanted to talk about my CAST experience.
I have been in many conferences in the past (both as a presenter and an organizer) and so I can point to some stuff that really made a difference on the impact and the value I got from CAST. I invite the people organizing these types of conferences in the future to contact the CAST Team and try to learn from them.

1. Achieving real constructive criticism via facilitated sessions.
The methodology at CAST is that each session (from the largest keynote to the shortest presentation) are divided into 2 parts:
The frontal presentation – where the presenter talks about his subject.
and
The open season – where the audience asks questions, bring forward comments, and even refute the whole argument based on their experience and points of view.

The open season is made possible due to the active moderation of a “trained facilitator” who is constantly making sure the session is kept alive and on a positive and constructive note.

As a presenter, it is a bit scary at first.
Only after you understand that the audience doesn’t want to take you down but wants to help you out, can you participate from the interaction and even enjoy it.

2. Real eye-level interactions between all the participants (and I mean all the participants!!)
It doesn’t really matter if you are a junior tester or a published expert, it always felt right to approach a person and talk to him or to take part in an open discussion (with cups of coffee or bottles of beer!).

Some of the biggest names in the world of testing took part in the conference (Caner, Bach, Weinberg, etc) and at no time did you feel that any of them showed nothing but the most sincere sympathy (or at least respect!) for everyone else.
I don’t know if it was the blend of informal activities or simply the attitude of the organizers, but it was amazing.

3. The feeling of a peer-organized conference.
Again, this was a “feeling” more than something concrete, but at no time did you sensed any hidden agendas or sponsor oriented activities that made you feel someone was trying to sell something.

I don’t think I saw a single person in the conference that was not related in one way or another with the art of testing or at least teaching testing, and this made a whole lot of difference.
A conference from testers, by testers and to testers… what a refreshing idea

There were also the regular things you get from any “large” conference: a constant brainstorm of amazing ideas, camaraderie and genuine will to share and learn, and the chance to expand your circle of friends and colleagues.

One last thing to mention about this CAST was the fact that it was a relatively small conference, apparently affected by the “current economic crisis” that made an important number of people not to come to the conference.
I don’t know if this affected the conference itself, or if it actually helped to create an environment of a close and connected family of testing professionals that would not have been achieved by a group twice as big.

In any case I wanted to give my sincere thanks to the CAST Organization Committee who invited me to participate and allowed me to take part in the event.  Having had the experience of organizing similar events I can appreciate their work and performance.

I would start thanking by specific names but this will only make me leave out some people out, so as I already thanked each of you on the last day of the conference I wanted to thank you again as a group, for the great work and for the successful conference you allowed me to participate in.

I hope to see you all again in CAST2010!