Please let us know your thoughts! Thanks!

Best,
Jonathan

[James’ Reply: How do you train them? How do you know they have skills?]

Normally I search for presentation hand-outs, articles or whitepapers. Only those didn’t present body language. Or support the feeling how you “actually” think about it at that moment. Perhaps that is one of the strongest things of your presentation. Make it available to the community how an expert is doing it and learn from it to become a better tester my selves.

Thanks again!
With kind regards,

http://riseagain.wordpress.com/2007/02/09/software-testing/

I’m also mentionning you in my previous article, please tell me if it’s not accurate.

Here is a blog on Storage Area Networking - How to get a job in SAN , how are the pay structure & how you can build your career in SAN . This one if filled with lots of Cool tech videos & makes very interesting reading http://storage-jobs.blogspot.com
SAN tutorials

- I might have a heuristic which works better for me, but that doesn’t invalidate yours. No point arguing (but worth mentioning).
- I might not be able to think of a better heuristic on the spot, so no arguing.
- I might be able to think of instances in which the heuristic is fallible, but that simply enriches it. No arguing.

[James’ Reply: Naturally, if we don’t have to agree on anything, we don’t need to argue about anything. But if we did have to collaborate on something, we might experience a clash of heuristics. This is not a problem if we are using heuristics properly. Proper use of heuristics, I think, is not to surrender yourself to them. They are merely aids. Therefore, if our heuristics oppose each other, we put them aside and rethink the situation together.

People who use heuristics without understanding them may not be able to operate without them. They won’t be able to deal with exceptional situations, or even a fresh perspective on a normal situation. This is a frequent complaint I have with the Agilists (note the capital “A”). They have many aphorisms, but it’s rare to hear them talk about conditions under which their little sayings hurt instead of help. Heuristics that are not questioned quickly become unquestionable, and a creative art that produced them becomes a dead art, like astrology or numerology.

When I share a heuristic with you, I am not sharing wisdom. I am sharing what I hope is a reference to wisdom. I hope the heuristic resonates with your own wisdom, so that it helps you exercise your skill with greater confidence. I share all my heuristics in the spirit that they are improvable and always subject to and cleansed by criticism.]

I tried downloading the *.avi version through the link given above and had a different experience.

I do not have an internet connection at home as of now and also we are not allowed to download media files in our office PC’s, so tried downloading the same from an internet cafe which is supposed to be a broadband. It went on for 6 hours, 175 MB and still was going on… I had to cancel the download paying around 150 INR. I came back home disappointed and it was Sir Thomas Alva Edison’s quote “People back off without being aware that they were close to success” that kept me sit, wait and see it getting downloaded for 6 hours.

I am exploring, why while downloading certain stuff alone we get to see the file size?.
While downloading the avi, I did not see any file size or is it that I am not aware of viewing it.

I also did a google search to find a tool to estimate the file size for the 57 minute avi video but perhaps could not find any such tool. It would be useful if it is available, isnt it?

Regards,

Pradeep Soundararajan
http://testertested.blogspot.com

The discussion about support is interesting. I handle practically all of the tech support and user documentation for a startup, as well as all of the testing - the support is not a part of the testing function, but in some contexts it’s appropriate for the same person to do more than one of them. There are two points of view I take on support - 1) Helping to get the product working (which is positive thinking), and 2) Making the product fail for me in the same way it fails for the customer (which is negative thinking, calling on my testing skills in a similar way as when I try to reproduce an intermittent failure). I’m personally not satisfied when I do #1 without #2, because then it’s likely that this customer and maybe many others will encounter the problem again.

I ask my colleagues to speak frankly to me. I try to make it worth their while, mainly by acknowledging their contributions to work that otherwise might be mistaken as purely mine.

I mull their comments and try to get better at what I do, because I want to be fabulous at this testing craft. Sometimes its hard for me to process what they are saying, but it’s important to do it. Paul’s post illustrates the power of shared experiences in helping your colleagues and getting help. The fellow he’s referring to is one of the most opinionated people I have met in my professional life. It’s a vivid image.

These are colleagues I would recommend to any of you, out there, to make part of your network, too.

Also, although I don’t know who you are, Insectivorous, I’m interested in reading more of your writing.

– James

Let me add to Danny’s comment in a way that may help you digest his main point (which as I understand it is NOT that he wishes you to “hold back”).

If you cast your mind back to WOPR2 you will recall a certain “dominating” personality at the workshop. It was not the general consensus at the meeting that he was “the expert” - although everyone would admit that he had a lot of experience, knowledge, and presented himself as an expert.

If you recall, there were many threads that had a lot of energy among the group which tended to die out rapidly after this person spoke. I feel (strictly my thoughts here) that the reason for the lack of discussion after his comments was not in what he said but in how he said it. He talked to the other attendees as if he was the teacher and we were his students - he spoke in a way that suggested that we better not disagree with him or we would be wrong.
There was only one person at that meeting who, in my opinion, could have “stood up” to him - which was you - yet unfortunately you were facilitating and could not directly participate in the discussions.

I think the point that Danny makes is that when you engage people in talks, you DEFINITELY invite them to scrutinize you and to challenge any of your comments - but you also attack (sometimes mercilessly) differing opinions in a way that is similar to our WOPR2 participant - you are right and they are wrong. I have noticed that when you present your opinion in the manner (or, more accurately, tone) that you are the expert then the discussion shrivels - when you present the opposing view point with a less superior attitude, then the other person is more readily engaged into the conversation.

I once had a direct boss who would continuously question and challenge every idea I presented to him without any indication that he thought the idea was potentially good. After a year, I stopped presenting him my ideas as I was tired of being shot down. I would implement my ideas without discussion with him - or even informing him. I later found out that he was intentionally questioning me in many ways about my ideas. He was proud of his behavior because he felt that it would make me think that he was listening to me and that he was ensuring that I was thinking the idea through. His strategy would have worked very well IF he had given me a little bit of hope at the beginning by saying: “That sounds like a good idea. Have you thought about…”. Without that acknowledgment I ended up feeling that I was being attacked along with my all of my ideas.

I am in no way asking you to change what you say or how you try and engage people, but perhaps you could start out a bit more gently and receptive when initially engaging someone in a “conversation”.

BTW - Feel free to keep the gloves off in our discussions - it is hard to find someone as passionate and intelligent as you to have a good conversation with.

- Paul

Well, yes, we are negative, or yang, or the other side. Between the time when the oceans drank Atlantis, and the rise of Microsoft, when Ken Olsen could scoff at the idea of a home computer and everyone believed him, I was a real-estate examiner. In a property deal, the buyer wants to buy, the seller wants to sell, the mortgate company wants to lend the money, the closer wants to insure it…everybody in the whole parade is in favor of going forward, except the poor schmuck who’s examining the title. He’s the only one saying “no”. (Made me a good fit for QA, I guess)

But that was my job, and it was reasonably well paid and respected. I mean, nobody thought that because I was a title officer, it was because I wasn’t “good enough” to be a closer, or anything remotely like that.

But if you’re a tester, you’re still fighting the lurking impression that testers are just failed programmers. The battle to establish testing as a profession in its own right, with its own skills and abilities, is far from over. Just consider how many shops are still stuck, at this late date, in the “code/test/fix” mentality, and have never even considered any kind of serious QA effort — or could even conceive of what that might look like.

If we’re ever to make serious progress on that front, it will have to be with obviously superior products — because of the QA effort that went into them. A lot like justifying a bonus at review time, we have to be able to point to definite contributions that are clearly QA’s. And doing that is a problem.

We’ve all learned that marketing trumps quality, hands down. If it didn’t, we’d all still be using dBase/FoxPro instead of Access. Or Quattro instead of Excel. We can’t do much about that.

But support and documentation also trump quality. The product might be great, and blissfully bug-free, but if nobody can figure out how to use it or hates to have to, then the quality of it otherwise won’t matter at all. And this is an area where I think we CAN make a difference.

We can bring our QA skills to the documentation effort, and to the support effort. We can find, test and reject docs that just re-iterate the help screens (and if they were adequate, why have docs in the first place?) We can discern support strategies and methodologies that are and are not effective, that do and do not lead to real closure and customer satisfaction. We can and do field-test applications, so why aren’t we looking at field-testing docs and help systems? We create use-cases, but why aren’t we also creating support-cases?

I take pride in finding ways to break applications, but I also take pride in finding obvious uses that aren’t documented at all, or in technical terms never explained. (Ex: When you first started using Access, remember how long it took you to figure out what the hell a “pivot table” was?)

And the next time you have an issue with cell-phone billing, after you’ve calmed down and can stop cursing, look at the whole experience with a professional eye: is this process broken? Can we instrument it to count and illustrate defects? Can we find and fix potential problems before we put the customer on hold for fourty-five minutes? Couldn’t we do support-testing, and do it as a fairly simple extension of what we’re already doing, too?

The way we do documentation and support is just as stuck in the dark ages as the old “let the customer find the bugs” thinking that we’re trying to stamp out. We’re the people who have the skills to show how it can be done better, in the same ways we can make software better, only we haven’t focused on it.

We can’t, and shouldn’t, start to actually DO documentation or support (though that helps, just as programming experience helps testing). But we can start to run quality control and quality assurance on both with the same techniques and skills we’ve already got.

But surely I can’t be the first one to think of this?