UK Tester Forums

The 23rd Test Management forum will take place on Wednesday 29th
July at the conference centre at Balls's Brothers, Minster Pavement.

The meeting is sponsored by our patrons:
HP, SOGETI and SQS UK

We are most grateful to our generous patrons.

You need to be registered on UKTMF.COM to attend. | To book a place complete the contact/booking form.

Sessions already on the programme...

read more

A few weeks I went down to the U.S. Consulate in Toronto to register Ariel, my daughter, as an American citizen born abroad. (She's a dualie, because she was born in Canada to an American parent: me. I'm a dualie too, born in the U.S. to Canadian parents. Being born a dual citizen is a wonderful example of a best practice. You should follow it. But I digress.)

The application process is, naturally, fraught with complication and bureaucracy. There's also a chilling and intimidating level of security; one isn't allowed to bring anything electronic into the Consulate at all. No cell phones, no PDAs, and certainly no laptop computers. That means no electronic records, and no hope of looking anything up. So one has to prepare.

There's a Web site for the Consular services. One of the first items that one sees on the site is a link for telephone inquiries. Note a couple of things here: the telephone services are for visa information, not for general information; and that visa information costs USD$0.90 per minute for a recorded system with no operator. (Oddly, that's the price for calls from the U.S.; calls from Canada are cheaper, at CAD$0.69 per minute.) I didn't test that.

With only a little digging, I was able to find information related to registering a birth abroad. I gathered the information and documents that I figured I needed, and took it all down to the Consulate. I was getting ready to travel the next day, and so in typical fashion, I pushed things out to the noon deadline for receiving applications. I watched the clock on the car anxiously, parking at 11:53 and getting to the Consulate at 11:55. "Wow, that's pushing it," said the security guard. "Last one today."

When I spoke to the friendly, helpful lady behind the counter (I mean that; she was genuinely friendly and helpful) she they told me some things that the Web site didn't.

• The application form itself is online, and these days it's one of those PDFs that has input fields, so everything can be nice and tidy. Again, though, there are some fields in the form that have several possible answers. There is some helpful information available, but I still had questions.
• The consular officers want to see original documents, but accept and keep only photocopies of them. You need to come with your own photocopies. If you don't, it costs you $1.00 per document—and there are lots of documents. This isn't noted anywhere on the Web site that I could see.
  
• On one of the Web pages listing documentation requirements, it says "In certain cases, it may be necessary to submit additional documents, including affidavits of paternity and support, divorce decrees from prior marriages, or medical reports of blood compatibility." Well, what cases? The page doesn't tell me, and getting it wrong means an extra trip. The lady behind the counter reviewed what I had brought, answered a number of questions, and told me exactly what to bring next time.

As I travel around, I sometimes see an implicit assumption that documents tell us all we need to know. Yet documents are always a stand-in for some person, an incomplete representation of what they know or what they want. They're time-bound, in that they represent someone's ideas frozen at some point in the past. They can't, and don't answer followup questions. As Northrop Frye once said, "A book always says the same thing." Yet if we look more closely, not even ideas that are carefully and thoroughly debated can be expressed unambiguously. That's why we have judges. And lawyers.

The next thing that happened emphasized this. After I left the Consulate, I returned to my car. At the collection booth, the posted time was 12:20. I'd been less than half an hour, which is good because parking at that garage costs $3.00 per half-hour. I handed the attendant my ticket. The charge was $6.00.

"What?! I've only been gone for 25 minutes."

She looked at the ticket. "Sorry, sir. You checked in at 11:40."

"No way," I said. "I know what time I checked in; I was running late. It was at least 12 minutes later than 11:40. I got to the entrance to the Consulate, just over there, at 11:55. No way I could have taken 15 minutes to walk 75 metres!" She showed me the ticket. It said 11:40. "That's impossible. I want to check the clock."

The difference was only $3.00, but I was furious. I exited the garage, drove around to the entrance and check the display. It read 12:24, the correct time. I pushed the button and pulled out a ticket; it too read 12:24. To her credit, the attendant appeared and checked the clock, and asked to see the ticket I had just printed. "12:24. I'm sorry, sir, there's nothing I can do." Quite true, no doubt.

In this case, the (clearly fallible) machinery and the (clearly fallible) documentation were more credible than I. I didn't check the ticket on the way in. And yet I know when I arrived, and I know that there must have been some kind of failure with the machinery. A one-off? A consistent pattern? Happens only at a certain time of the day? A mechanical problem? A software problem?

All the way home, I pondered over how the failure had occurred, and how one might test for it. But what impressed me most about my experience with the Consulate's Web site, and the consular officer, and the the parking ticket machine, and the parking attendant, was the way in which we invest trust, to varying degrees and at various times, in machines and in documents and in people. When is that trust warranted, and when is it not?

Postscript: Just now, as I attempted to publish this post, the net connection at this hotel was suddenly unavailable. Again.

I have recently read a blog article titled, “testing sucks” by the charismatic industry guru, James Whittaker. The article gives an interesting and unique insight into the life of a testing professional. I am keen to see whether other testing professionals agree that this is a reasonable explanation for miserable testers.

If you have read the article, (if you haven’t you can find it here) what is your opinion? Has James Whittaker’s article struck a chord with you? Do you agree or disagree? I welcome your comments below...

Thanks to the energetic James Lyndsay, a bunch of us are meeting at the conclusion of his Exploratory Testing class and my Rapid Testing class on Friday, June 3 2009, in London, UK. I expect we'll be there somewhere between 5:30 and 9:00pm. The venue is the Prince Arthur pub, 80-82 Eversholt Street, Euston, London, NW1 1BX, right across the street from Euston Station, north of Euston Road. Three large tables have been reserved. All are welcome; please spread the word!

After that, I'm off to The Magnet, a pub near the Archway station, where a gang of folks gets together every Friday from 9:30pm until late to play Irish traditional music. I'll be armed with my mandolin. All are welcome there, too!

A rookie tester asked me this question. They are experienced in software development, and their grad school work was in a highly specialized area of mathematics. They have been hired to do a very particular type of testing that they are uniquely qualified for. After getting over the mindset shift required to be an effective tester, they were pleased that they were finding bugs that they'd been hired to find. Then a wrinkle appeared. The very people who hired them to find the bugs got angry when they found the bugs they were being paid to find. Sound strange? It might, but it's actually a common response to effective testing.

Here are some of my clarifying questions:

• Are the bugs you are finding important, or trivial? Stakeholders on teams can get irritated if you inundate them with only trivial bugs.
• How are your bug reports? Are they thorough? Do you provide enough information for devs to accurately reproduce the bugs?Programmers get irritated with bug reports they can't reproduce and track down.
• How's your attitude? Do you laugh with glee at the misfortune of the dev team? Are you empathetic, or a condescending jerk? Is your language accusatory. blaming or condescending in any way?No one wants to be around someone who enjoys the schadenfreude.

"No, the devs like my bug reports, and I've been as low-key and empathetic as possible. These are serious bugs that have probably been in the application since it was released several years ago. I'm tempted to stop logging the kinds of bugs that cause them to get mad at me."

Ok, you're probably not doing anything wrong. In fact, you are probably doing something right. Don't stop! You aren't failing in your work, you are succeeding.

Since they seem to be doing some of the right things and aren't knowingly or obviously antagonizing stakeholders, I assume that they really are finding important bugs, and that reaction is one telltale sign that they are being effective as a tester. I also encouraged them not to give up, but to do as Peter Block would recommend: move towards the resistance. That is a heuristic that tells us we are doing our jobs, and highlighting the really important problems. The resistance to being confronted with difficult problems that aren't trivial to solve is just human nature.

As testers, if we are finding good problems, and we're working with the team to help them, moving away from the resistance is a sure-fire way to relieve the pressure in the short-term, but lose credibility in the long term. If stakeholders realize we can't be trusted, we've lost out ability to effectively test, observe information, and provide information that is useful for them.

I have a personal rule: if I am being pressured not to talk about something, or I feel like I should avoid a contentious issue, that means I absolutely must deal with it and talk about it. I try to be empathetic, understanding, use the right kind of language and not be a jerk, but I bring it up. Every time I do, something important is brought to the attention of the people who need to hear it. They may not like it, and they may not like to see me coming, but they know that I will always tell them the truth.

Early in my career, I was told not to bring up issues that were met with resistance. I was told that was a "career-limiting move." My career is a testament to the opposite. Whenever I have faced resistance, stuck to my integrity and ethics, and talked about the hard problems the team had been taught to ignore, it has been a career-catapulting move.

So testers, if your work is pissing people off, the problems you are observing and reporting are important, and you aren't being a jerk, don't give up. It may hurt to point them out in the short-term, but it pays off handsomely in the long-term.

*Note:This doesn't just apply to testing work, but any type of work that requires pointing out and helping solve problems. Whatever it is you do, don't be discouraged if you are working on real problems and people are behaving strangely. Use that resistance to tell you that you are doing something right. The worst thing to do is give up and become silent.

I mentioned that Fiddler forms an essential part of my web testing toolkit, and recently I had a hankering for knowledge of Security Testing. Somehow I found my way to a Fiddler plugin called Watcher from Casaba Security. This lets me slowly learn about security testing in the course of my normal testing. Simple to [...]

I've done a fair bit of Web and Flash testing recently and I suddenly realised how much I rely on various tools I have installed to help me. In fact, I don't know how I ever managed to test web sites without these. So in this post I'll provide a wee introduction to the tools [...]

I still remember my first real test. Do you? Since I generalise wildly, I assume that you do. Note: my first 'real' test. Not "the first time I found a bug". For the purposes of this exercise I defined my first 'real' test as the first time I can remember purposefully thinking like a tester with regards to [...]

Since Compendium Developments houses my book reviews, you may have missed: How We Test Software At Microsoft Apache JMeter Software Testing An ISEB Foundation Next Generation Java Testing Head Rush Ajax

Which ones do you read? CrossTalk Testing Experience Better Software Software Testing and Performance (IN)SECURE magazine Methods and tools Any more I should add to this list?

I recently facilitated a session on free and open source test tools at the Test Management Summit. This post contains an edited form of my notes prior to the event and some amendments and additions based on the discussion from the session. [Download the slides from the session] What makes me think I have enough [...]

I dislike the term QA when applied to testers in general. I dislike it more when applied to my team. I dislike it even more when applied to me. If you read this, and you use the term QA - stop it.  Bad Trend towards QA Unfortunately if I graphed the trend for verbal usage of [...]

A few testers have recently mentioned the tool FireShot to me. Note they only 'mentioned' it to me - they should have raved about it and shouted out its name, and in between the effusive praising performed a little happy dance. This plugin works in both IE and Firefox and allows you to capture the [...]

"I clicked on that, why didn't the click work!" I recently faced the challenge of using Selenium to automate a web application that stubbornly resisted my attempts to automate it - until I found the fireEvent! No need to know the name of the application in question, but the basic situation I faced involved a form [...]

Over the years I have used and reused a variant of a single AutoIt script. The script basically polls windows for a dialog that matches a certain pattern and then performs some action. I most recently used this to get rid of the IE dialog that pops up using Selenium with IEHTA asking if you want [...]