CITCON 2007 Review
I just got back from attending CTICON 2007 (pronounced KIT-con) in Dallas. Bret, Kevin and I went up on Friday. Registration was at 6:00 PM. After registration, everyone arranged themselves in a large circle and the hosts- Paul Julius and Jeff Frederick- (the pics are courtesy of Jeff too) went over the rules and expectations for the 60+ attendees. It is in an open-space format, which is a great way to have a conference run. (I attended my first open-space conference at AWTA in January and was really impressed by it.) Then everyone went around the room and gave introduction of themselves and why they attended this conference. I was surprised to find out that there were more than 2-3 testers there.
After introductions, the open-space format began and people suggest a topic that they wanted to talk about, they would create a sticky note. This person would be responsible for leading the discussion, not to give the discussion.
Once all of the possible topics were suggested, everyone went to the board and marked which topics they were interested in, so that the schedule could be created. It worked like a charm. This was followed by a social period where people could talk about themselves, their current technical quandaries, experiences, solutions, etc.
The next day, the meetings began at 10:00. Each meeting was scheduled for an hour. I'll briefly highlight the one's I attended. The first one was Bret's talk on, "Is RSpec Awesome or What?" Here, Bret showcased 
how RSpec can be used in testing. He showcased how he added a ‘succeed’ method to the RSpec library, so that we can extend other methods.
Let me give you a little background on this. We have login tests with assertions in them within our login suite. We also use the same method for other tests, for example, our create_case test uses the login method also, but we're not validating login in the test case. The ‘succeed’ method allows us to extend the login method and give a higher level error message, in this case, "Unable to login using #{@user} and #{@password}", instead of a low-level error message specifically related to the login test. This allows the developers to understand the problem, rather than having to grab a tester to interpret the Ruby error message.
The next session I attended was "What Is The One True Language For Writing Tests", which was led by Jason Huggins. This was an interesting topic, because at AWTA, I left there with the impression that Ruby was the tester’s language. One question I posed was what type of testing are we doing? Unit? Acceptance? The language will be different depending on the type of test. To try and quell the uprising, the group decided to brainstorm on what they wanted in a testing language. In the end, there was a matrix created where different languages were compared. Last time I saw it, Ruby was met the majority of the requirements and was in the lead. Not a surprise. What was interesting throughout the conference was that even though Ruby was talked about a lot, there were a few developers who had not looked Ruby, whether it be for a lack of time or the fact that they were happy using Python or another language.
After a great lunch sponsored by Google, the third session began. I attended "Are the categories of Unit test, Integration test, Acceptance test, etc., still useful?" This turned out to be more of a consulting session for a gentleman. Good talks though. His problem basically was that of terminology throughout his team. I don't believe everyone on his team knew the differences between testing terms and who performed what tests, and when pairing should be used.
Fourth session was "Next Gen Test Automation Tools What Is Next" led by Elisabeth Hendrickson. I referred to a two-part article she posted in February about the future of test tools. I asked her to explain more about Ward Cunningham’s new tool Process Explorer, as I did not grok it when I originally read about it. She gave the group a walkthrough, which led to a great conversation about what should be included in future testing tools. A developer in the conversation asked the question, what he can do to make a tester's job easier. (I love it when this is asked. However, this is also a two-way question and, as a tester, we have to ask what can we do to make the developer's job easier.) Three answers arose- 1) keep asking the question, 2) write hooks within the code, and 3) sit with the testers so they know how the AUT is tested.
Another feature for next gen was that Jason suggested creating movies for people who write the bills. I asked him to expound on this. He said he would like to be able to send the CIO/CTO, or whoever writes or approves the writing of the check, a link in an email. Upon clicking the link, some test(s) would automatically run. This would allow the person to see that work has been done and understand what they are paying for. Sounds like a great idea.
Elisabeth also suggested future tools have the ability to intelligently read and decipher heuristics. This feature would automatically know how to test different heuristics within an application, once the heuristics were specified. Talk about cutting edge!
The last session was one I suggested, "Its Red How Long Do We Leave It Like That"? This is something that we recently experienced at Dovetail. Our build was broken for 5 days. While we still could work, our productivity was not nearly as good as if it was green. The outcome from the group was that we should give the developer(s) under an hour to fix it. If it's still broken, the person(s) would have to rollback their commit. This is a general rule though. If they're the last one in the office, then there is no need to do this. Common sense needs to be used. And, the person who breaks the build must buy doughnuts :)
