I met a person working as a test contractor on a project recently who said to me: "There are no requirement documents so therefore I cannot write test scripts. And this means, I cannot test."

I've heard this before from other test contractors. I don't understand the logic being applied.

I tilted my head and was speechless. I thought I should keep listening to see if I could better understand. But I didn't. In this case, it seemed the tester believed the only way to approach testing was to read and review requirements, write test scripts, and then execute test scripts. Since this one approach was not an option in the environment at that time, the tester felt dead-ended with his work.

Here are two articles I published this month on testing.

"Improve Your Testing and Your Testers with Paired Testing"
Ideas and stories on paired testing
InformIT, April 2010

"Insights from Running UAT Sessions"

This afternoon I was talking with a friend and colleague who asked me about my writing, more specifically about software testing articles I've written. He was surprised to learn that I had published six articles in the past couple of months - he hadn't realized that I wrote so much or so often. I thought most certainly I had listed the articles on my blog as each article had been released but it doesn't look like it. Here’s a list:

Someone asked me recently why I don't participate more in software testing forums. Why I don't blog more often. Why they don't find me "around" virtually as often as they used to. Balance was my answer.

My online life was becoming consuming. And it’s easy to get out of balance especially when you live in a climate like Chicago where its winter for eight months (or at least feels like it.)

I gave a presentation called Building Alliances. It was a non-technical talk focused on working with people. The talk focused on positive alliances we can build at work as well as some of the realities – the good, the bad and the ugly of office politics. The talk was recorded at the Pacific Northwest Software Quality Conference (PNSQC) 2009.

I had a technical issue I needed to research for a client. Nothing surprising, I research different bits of information frequently. At the end of my research I realized I wanted to explain what I'd done, I wanted to clarify and present what avenues I had pursued, what information I'd learned, what issues remained and what possible other solutions we might look into. I realized I wanted to share these bits of information with the project team so I set out to write an email.

I like maps. I wasn’t sure why maps appealed to me until it dawned on me one day that maps are a form of data visualization. The phrase “here be dragons” was used by mapmakers many years ago in reference to uncharted or unexplored areas. I like the phrase. Maps were marked with dragons and in some cases, other animals were drawn to signify danger or unknown, uncharted territories. I find the concept and the phrase kind of cool in a geeky sort of way. You can read more about this old mapmaker’s phrase here.

I also like SQL. I like being able to access a database and spend time with data. I teach a couple of different SQL classes and one thing I’ve found repeatedly has been people’s intimidation by having to write a join in SQL. It’s amazing how far people will go to avoid the dreaded join – it’s a bit like “here be dragons” - a territory marked with fear and uncertainty.

It’s been a long time since a software bug agitated me - one that I was hit with as a user not a tester. But I've had one I've been dealing with this past week.

In some ways it’s been interesting to feel like a user. To get whacked unexpectedly with a software bug that impacted my day and took time to resolve. Mostly it’s left me agitated and thinking less of the company.

Blackberry released an upgrade to their software and I took the release. I didn't notice straightaway that the update stomped out my Google sync settings. Wiped out Google sync entirely, I had to reinstall. And impacted my Gmail, calendar and maps.