Collaborative Software Testing

Use of Fuzzers Helps Discover XML Security Threats

I posted about fuzzing a few days ago, and I think the tools are neat, and in the hands of good testers can be powerful. They are a nice way to augment existing security testing, to test data transfers or messaging, or to simply generate test data. However, some of my readers basically said: "Big deal. It's a neat toy for you, or some of your clients who have the time for that sort of thing, but why would I want to use one?"

The Register has posted an interesting article where fuzzers were used to discover potential security holes in XML libraries. Check it out here: XML flaws threaten 'enormous' array of apps. If my babblings about fuzzing don't get your attention, maybe this article will. The potential to use fuzzers (in conjunction with other security tools and techniques) to help people catch problems that bad guys will exploit is enormous.

Codemonicon, the company cited in the article, have a lot of interesting information and expertise in this area. They have a nice introduction to fuzzing on their website. This paper by Rauli Kaksonen has a lot of technical detail on fuzzing if you'd like to learn more.

Video: What's More Important: Being Agile or Creating Value?

Back in June, I presented a keynote at the Better Software Conference called
"What's More Important: Being Agile or Creating Value?" SQE have posted the video.

The video is just over 50 minutes long.

Session-Based Testing Using Instant Messaging

Here's a scenario: a programmer friend is creating a new web-based product for his company. He wanted someone to augment the existing testing that was already underway, and hired me to add more firepower. It is a distributed environment, which means that everyone in the office telecommutes. We decided to start with me doing an initial session, via instant messaging. We blocked out a time for the session, determined a focus ("mission") and I started testing.

As I tested, I typed what I was doing in the instant messaging (IM) client, along with questions, concerns, crashes and bug ideas. He followed along through the application as I tested, asked clarifying questions as I discovered problems.

After ten minutes, I had generated enough ideas for that mission. He logged 6 bugs in his fault-tracking system. I had discovered 5, he had discovered 1 himself while following me along and monitoring the server and database.

I've done session-based testing over IM quite a lot with different distributed projects, like open source projects such as Watir and Session Tester, and with some of my clients that use telecommuting, or are completely virtual. We've used and adapted some of the ideas from SBTM to help provide more structure around the actual test sessions.

Using session-based testing with IM seems to work best in pairs. Once a focus and rough timebox are determined, test setup is out of the way, both pairs initiate a session through an IM client. One drives by testing, and the other saves the conversation locally, and creates notes, logs bugs, investigates underlying behavior, etc.

This style is natural (we communicate a lot with IM clients anyway) and doesn't interrupt the natural testing flow if one person acts more as the primary test idea generator/executor and the other acts as the primary scribe. If you want to add some variation to your testing approach, give it a try.

New Exploratory Testing Tutorials

I've developed some new ET tutorials. The newest is "Managing Exploratory Testing", addressing questions I hear the most from managers. Since I've done a lot of this sort of training already, it made sense to start offering this publicly. I'll be teaching it at EuroSTAR and STAR West this fall.

The other tutorial is an evolved version of my take on "Exploratory Testing Explained". Due to questions and interests of people who have taken the course, it has evolved into a hands-on, experiential workshop: "Exploratory Testing Interactive". I'm also teaching it at STAR West.

If you'd like to work with me to get a glimpse into my take on exploratory testing, and learn some new skills, drop in at one of the conferences. If you don't or can't attend these conferences, you can also consider bringing me in to work with you and your team one-on-one.