Hello Readers,

We need your help getting a discussion going on cloud computing at Insidespin.

Cloud Computing — The Talk of the Town

Come Join us for a discussion – I know you have some ideas worth sharing.

Adam


Just read an interesting article called In favor of tough criticism .

It’s a bit of a long read but well worth it. It’s especially timely as I am discussing testing dashboards with collegues and peers. I enjoyed the comments and I especially like the conclusion.

“The future of critical exchange stands at a crossroads. The increased reliance on faint praise, along with the rise of anonymity online, threatens to enervate the free flow of ideas in academe…. It is time for literary scholars to question their critical affiliations, to question behavior that encourages conformity over nonconformity; faint praise over pointed criticism; anonymity over transparency. Telling a colleague “You’re wrong” shows more compassion and collegiality than remaining silent—or hiding behind a cloak of anonymity.

We need to grow thicker critical skin. Why? Because critical behavior that always results in a chorus of affirmation is nothing more than conformity; because allowing views to persist that need to be challenged is nothing less than critical mediocrity; and because failure to tell our colleagues what we truly think about their work is simple dishonesty. A reshaped critical culture will help build a more robust, honest, and transparent academy.”

Even though the writing is focused on the academic world I think the ideas have usefulness outside that context. It made me think about the implications at work for direct reports, peers and bosses as well as colleagues in the technology industry.

What’s your thoughts on the situation?

- Critique (even if it’s harsh) to help your friend, employee, colleague, boss make a better argument or take the approach of “If you don’t have anything nice to say don’t say anything”?

- What is the proper forum for criticism – private, publicly or anonymously

- How does one prevent critiques from getting personal?


Posted in Feedback | 4 Comments »

I’ve added a link to the RSS feed and Google reader right hand column.

I’ve also added email subscriptions for those who don’t use an RSS Reader.

Now you don’t have any excuse – go sign up!


Exploratory Writing Skills

June 20th, 2010

I was looking for inspiration this weekend. I have an old article improv and software testing that I’ve been wanting to dust off.

While looking for “inspiration” I noticed I was applying exploratory testing skills. I wanted to share with you how I was applying this to my writing process using Jon Bach’s exploratory testing mnemonic MR Q COMP GRAB C R&R (pg 20)


Read the rest of this entry »

I’m sure there are lots of basic timer apps out there and I probably could write one myself but i’m just curious about what others do. The “obvious” answer is using the your computer clock. I find this method can be disruptive to thought and getting in the zone.

What do tools have you found that alert you to your session time being up without having to actively monitor it?


Risks Digest

June 13th, 2010

I subscribe to and scan the risks digest every once in a while. Some of the stories make me love and hate technology. Here are 3 that I found particularly interesting this week.

This article Computerized ticketing reduces ticket writing raises interesting points for people who work on software systems that are supposed to “make life easier”


Read the rest of this entry »

I LOVE this video by RSAorg. Their presentation method kept me very engaged.

I decided to blog this as several people have sent it to me…. make sure you check out RSA’s other videos

I got a nice surprise last week. Turns out I’m contributor of the month at InsideSpin. How is contributor of the month determined? Strictly by the number of posts in the discussion forum. Maybe I should look at my own post about misleading metrics

What is InsideSpin?

It’s a new technology forum for Entrepreneurs Seeking Excellence. It was started by Stephen Pollack, former CEO and founder of PlateSpin. The site is made up of a core of written materials and a series of member discussion  forums.  There is a wide range of business topics covering most operating disciplines of a high tech start up including:

- Sales/Marketing

- Product Management

- Product Development

- Customer Support

- Finance & Legal

- Board, Advisors and Governance

- HR

Stop by and check it out. I especially like the Product Management case study

How to keep updated

Along with subscriptions to the forum there is a linked in group to show your affiliation and twitter feed (@insidespinner) as well.

Help us get the word out and tweet this post!!

I was impressed by what Cong had done. I thought his summary was thoughtful and showed understanding of the concepts. I went through bugs and reviewed the answers to each of the 4 questions. I learned a few things about the details of our product that I didn’t know before.

I picked up the phone and called him to talk to him about his findings. I gave him credit for doing what he did. When discussing the bugs I asked him if he could do this process for every bug or if it would be too time consuming. His answer was something to this effect “Well even for bugs that I thought were trivial I still learned something from talking with the developer so I’ll have to use judgement in the future”

In discussion of one particular bug I asked him to think about whether it was something we should write down as a test idea for future release and also to help future testers learn about the product. I didn’t give explicit directions/instructions on whether this is an expctation/requirement for him. He will have to figure that out for himself and decide where the info would go.

One point we discussed was that there was no response to my initial request until it was done. Throughout the week I wasn’t sure if he was putting any effort into it. I’m also at fault for not setting expectations for an initial response. We both learned a lesson from this and can now communicate more effectively in the future.

I feel like now when I respond to his daily updates we can speak a common language and have a common understanding.

Here is my summary of this interaction

What went well

  • Attempting to make Cong feel safe and that I wasn’t threatening or unhappy with his work. I am his boss’ boss afterall and I had never given him a direct request before
  • Clearly set completion date
  • Set out expectations on how the end result should be delivered
  • Gave some local options for getting help
  • Follow up via phone to discuss findings and do a little bit more coaching

What could be improved

  • I could have picked up the phone in the beginning and explained the exercise, following up with the email writeup
  • In my initial request I could have asked Cong to respond and either accept, reject or negotiate my request and give him a date to do this by
  • I could have followed up with him mid-week to see how things were going with the task
  • I could have set up a skype call with him

Things to remember when coaching remotely

  1. Look for things that will teach you about something of interest to you – not only the person who you are coaching
  2. It’s important to set two deadlines – one for the initial response/commitment and one for the actual deadline
  3. If you’ve not met the person or had very little interaction with them make sure they don’t feel threatened
  4. Give the person options for getting local help
  5. Follow up via phone/skype, give feedback watching for anything from #1

I’d love to hear any comments on this situation or thoughts/experiences you have with remote coaching/training

Cong’s response  (only edited formatting)

<begin response>

Summary

One of the most important things in testing, is to have a sufficient number of perspectives. We can either look at a product by its elements: Structure, Function, Data, Platform and Operations-SFDPO, or by quality criteria from customer’s point of view, CRUSPIC-Capability, Reliability, Usability, Scalability, Performance, Installability, and Compatiblity. Note that scalability and performance are closely related, and usability, what might annoy or frustrate the person or program that uses the product, and installability should not be forgotten.

In test design, risk-based testing will try to anticipate a problem and test for it. Rapid Testers model the risk in four parts. There is a risk when a victim may be affected by some problems caused by a vulnerability in the product that is triggered by some threat. The model itself is a good application to the exploratory testing we do here at Platespin. When deciding how and whether to test the risks on the risk list, where risks are assessed via a combination of the four parts, tasks are prioritized and used to guide exploratory testing.

As a tester, especially a tester in exploratory testing, we examine the criteria (CRUSPIC) from a user’s point of view. Surprised, annoyed, puzzled, frustrated, or maybe satisfied, emotions are generated when user experiencing our product. Emotions, “arousals”, should guide us in testing and work as oracles that trigger heuristics and wake us up to the discovery of a new problem, a problem that might be function-wise correct but interfere customer’s goals.

In addition, there are several key points that can lead to successful testing: A diversity of workflows tends to expose sequence-related bugs; A scriptable or programmable API to a product makes it more testible (which is the case that we use vmware ESX and vCenter) ; shortening the feedback loop between developer and end-user is a powerful force for beneficial change; real (realistic) circumstances tends to reveal problems and to help identify the kinds of problems that are important to real users.

5 Bugs discussed with developers

Edit – removed bugs that were discussed

Please point out anything you like.

Thanks,
Cong
<end response>