I was in California this week partly for a client meeting and partly for a Selenium Developer Meetup and had half a day to kill so figured What the heck, I’ll go hang out at Agilistry. And look! There is a workshop called Coaching with Questions. So much the better!. (I likely would have gone regardless.)

‘Coaching with Questions’ ended up being one of those ‘experiential’ workshops that the/us Agile kids like to have; in this case it was Dale Emery who was facilitating. And though I really dislike the ‘experience’ of them live, this one makes me think I should really participate in more. (Not sure if I’m quite ready for PSL yet though, but again, I’m pretty sure I should be signing myself for it based on not thinking I am ready for it.)

The first exercise we did ended up producing a list of reasons why someone might want to as a particular question, but end up asking a different one.

• New information
• Question was answered by previous question
• Something wasn’t clear
• Did not yet hear the current state of whatever is causing the questioning
• Inquire about the expectations for the questioning [in order to frame further questions]
• Separate the larger problem from the smaller, personal problem
• Alignment with the questioners model
• To confirm some conclusions that are being reached

The second exercise was done in small groups and was a conversation between two people but where the ‘coach’ could only ask questions. Its safe to say that section was incredibly useful to me as Elizabeth Hendrickson was my coach and my hand-wavey, nebulous question was nicely morphed into a big bundle of other questions (and fears that I had nicely put into boxes — aren’t that what boxes for?!!?) that I needed to be facing. (See, told you I both needing PSL and am consciously avoiding it.) Had I been paired with someone else I’m not sure how much I would have gotten from it, but she has some situational background knowledge and I trust her so it worked fantastic (I think — and its my blog post). On reflection I think I even forgot there was an ‘observer’ who was watching the conversation.

After each debrief was discussion in which I wrote done the/my key items.

• Part of coaching is inviting the client to think
• Don’t assume you understand the concerns of the person answering your questions
• Businesses tend to do things for three reasons: to increase revenue, decrease cost or make a strategic change
• An important part of coaching is permission. And that permission is tentative and always up for renegotiation
• A useful question – Are my questions useful?
• A context-free one – What question haven’t I asked you?
• The biggest value a coach / consultant can bring to a situation is ignorance
• Coaching is about helping to put pieces together
• You can’t help but advise people with your questioning since the very act of asking a question has context and background around why you asked that particular question at the particular time
• Part of what we bring to a coaching assignment is out models of the universe
• If something is important, it will come up again
• A question I think I first heard Jerry Weinberg say (to Adam White) – If you did know the answer, what would it be?
• Possibility Boundaries
• It is best to ask for explicit permission if you are unsure whether you have it for a line of inquiry
• A shift (in tone of voice, energy of speaker, body language)usually means some something

Coaching with Questions felt kinda ’5 whys’-ish at times, but its actually much more than that with the key word being ‘coaching’. I think ’5 whys’ is more of a focusing tool for a specific issue than the sorts of things a well done thread of questioning can provide. I’d have no problem recommending this to other coaches / consultants — especially ones who are just starting out.

Oh, and Dale provided handouts at the end. I really need to start doing handouts.

Within a 10 minute timespan I read two completely unrelated articles that, in passing, said the same thing which is something that should be paid attention to.

The first was in Canadian Thoroughbred (my wife is a race official) on decreasing field sizes at race tracks. Field sizes at racetracks is a lagging economic indicator in that it takes 2 years at least between conception and racetrack for a horse with most being fully productive in the winners circle at a 3. And so now we are starting to see the effects of the economy on horse breeding as there has been a 20% drop in mares bred since 2006.

But to say that there are less horses in the starting gate because there is a 20% drop in breeding accurate. Not quite; ‘because’ is a heuristic which means it is fallible. Here is an important part of the article.

In my opinion, there simply have not been enough owners who have wanted to race those horses, as the economics of operating a racing stable in most jurisdictions have become more challenging, and the overall economy as cause the type of individual who might invest in racing to cut back on their discretionary spending.

So yes, the economy is involved, but not in the way you might think.

The other article was in Canadian Business about beekeeping. There was lots of stuff on Colony Collapse Disorder, etc. and how ‘less bees means higher food cost.’ Except this part of a paragraph stood out.

“To be honest,” says Melhim, “we’re talking about the disappearing of beekeepers more than we’re talking about [the disappearing of] honeybees.” As smaller operations fold, fewer commercial beekeepers are managing more colonies—and shouldering more financial risk. “It’s not very sustainable,” says Jeff Pettis, head of the Beltsville, Md., Bee Research Laboratory of the U.S. Department of Agriculture (USDA).

So the big risk to the food system is not because of CCD, but the commercialization of beekeeping itself.

Which means we now need to add ‘because’ to our list of words that trigger further investigation upon hearing them. As if we didn’t have enough stuff on our plate already…

Canadian Business’ ‘Performance’ article for the August 16 dead tree issue is An introvert’s guide to schmoozing (though curiously it is Networking online). It starts out with a mention of Myers-Briggs types as its basis for defining what an introvert is and then goes from there.

• According to a University of Iowa study on brain activity led by physiological psychologist Debra L. Johnson, introvert brains show more activity in areas dealing with learning and planning, while extrovert brains are more active in regions that control sensory processes, like watching and listening. This might explain why an extrovert is stimulated more by external forces, namely other people, and introverts are happy in their own head.
• Her advice: stay true to your nature and use those “quiet ways” to get ahead.
• “It’s not about interacting with 50 people. It’s making connections with primary individuals, and introverts are better at that.”
• “introverts are generally patient, good listeners — and the key to client services is you have to listen.”

Introverts in MBTI is interesting in that I seem to have in my head that a lot of testers I know have said they are introverts. Not sure if there is causation or correlation there, but it is interesting. (For the curious, I am likely INTJ if the mighty Internets interpret things correctly.)

(Yes, I have a stack of Canadian Business articles to write about…)

Amber MacArthur is a bit of a social media powerhouse around here (ok, that might be a bit of an understatement) and part of that role involves doing the circuit to pimp her new book. In a Canadian Business interview with her she discusses how to hire, and best make use of, a social media consultant. (Which for the record I think is right up there with SEO consultant…)

I’m not a big fan of using an agency or consultant who will do all of the work for you. The best way to get up to speed with what’s happening in social media is to work with that person for a couple months to develop a strategic plan — what you’re going to do, what kind of schedule you need in place — and make use of their experience and their advice. But eventually you should run your own social-media initiative. There are lots of big agencies managing social media for companies, and that’s not always very authentic. To have the most authentic voice in social media, you want to have someone inside the company who is the face of your organization online.

Exactly.

This is the same for any sort of consulting work be it something as fuzzy as social media or technical like Selenium.

See also a description of how Brian Marick prefers to consult paying keen attention to the second last point – it is the most important one.

I’m starting to quite look forward to the articles Richard Branson has in each issue of Canadian Business. They’re only one page, but crisp writing that has a quick nugget of wisdom with tales from his own life as an example.

Now that I am a consultant and dealing with clients directly (or as a sub-contractor for a larger organization) creating customer loyalty is immensely important so Weak links in the chain of good service was timely.

• Delivering good customer service requires that a front-line worker receive supportive assistance from an entire network of co-workers—in effect, a chain reaction of teamwork, one that is consistent from beginning to end. And when it comes to helping a customer, the chain of assistance is only as strong as its weakest link.
• But going the extra mile builds massive customer loyalty and brand-enhancing benefits.
• While fiscal accountability is important, especially when an outlay of cash is involved, there will always be occasions when an asterisk needs to be marked on the balance sheet.
• No company can train its front-end people to handle every situation, but you can strive to create an environment in which they feel at ease “doing as they would be done by.”
• Good customer service on the shop floor begins at the very top. If your senior people don’t get it, even the strongest links further down the line can become compromised, as the story shows.

Surprise! Culture is important!

Just because you are technically not obligated contractually to fix a bug in a third-party open source package your company relies on, this is the ‘extra mile’ that he mentions in the article.

My talk at this year’s Agile conference ended 13 hours ago and I’m now sitting in front of the ticketing counter waiting for someone to give me a boarding pass home which seems like a good time to post my slides and such.

The slides themselves, as usual, are not much value without me talking along side them, but here is also the content that made up what I was trying to communicate.

• Checklists
• Mindmaps
• Session Charters
• Specifications and Executable Specifications
• Common ‘Stuff’
• Management
• The ‘Wiki Way’

This pattern of forgetting things is getting dangerous (T minus 32 hours). One thing that I wanted to suggest is that storing your checklists, etc. in a wiki is also ‘acceptable’ from an Agile perspective. Ideally you want them right there with the source code, but a wiki has the advantage of being in the browser. And everyone has seen wikipedia by this point so is has at least heard of the concept of editing content.

If you are going to go down the wiki route, you need to make sure that it, at bare minimum, tracks revisions of edits and can disable anonymous edits (for auditing purposes).

You also want to provide templates for people to use when creating specifically purposed pages. The last thing you want is having 3 or 4 people each doing somethings slightly differently. (Thanks for Marlena for that tip.)

‘Gardening’ is the common term for cleaning up the wiki and time needs to be allocated to do it. Most often when gardening you are looking at adjusting the links between pages and the tags to find them. On this subject Chris says

Links and tags are devices by which to organize related information. The scheme by which you organize the information is up to you, but links and tags are how you manage the organization itself.

Chris also reminded me of something you want to consider with all your infrastructure choices – integration. Check whether your wiki has an API, and if so, start to wire them together.

Both Chris and Matt reminded me to mention that Fitnesse (one of the table-based BDD/ATDD tools) is really just a highly optimized wiki. (Random trivia – the Selenese syntax that Selenium-IDE uses was also a fork of FIT so has wiki heritage.)

Now what else have I forgotten in this series…

I was about to call it a wrap on this series and realized I have skimped on the actual management part. Whoops. So here it is…

I guess there should be some definition of what I mean by management. It breaks down into three different categories:

• When/What to run
• Who ran it
• What was the result

Let’s try and tackle each of them.

When and What to run is the classic testing problem. You cannot run every single test case for the hold system. It is mathematically impossible. Up against such odds, you do what you always do; you use your judgement and experience of what has changed and therefore the risks of those changes and run the tests that best address those risks.

The specifics of how you find particular tests is also up to you but I have seen them organized by…

• File Name – This is the Hungarian Notation of test cases. This is human readable true, but requires a human to categorize and group. Well, I suppose you could make monster filenames but that is unwieldy.
• Directory – This strategy relies on the where a test is in a directory tree as to what it describes. This is a strategy I have used quite a bit as it is both human and machine parseable, but is falls down if you want to mix organizational metaphors (functionality vs. user vs. module)
• Tags – This is something that I haven’t made use of yet, but want to. Remember that everything we produce (except for the visual stuff like mindmaps) is just raw text. This means it can be parsed with a quickie script. So why not put a line is there that just says Tags: registration admin security or similar that captures the intent of the test. Images and other formats can embed this sort of information as well — it just means your locator script is a bit more complicated. (And fun to write!)

Or, better still, you combine all three of these.

Who ran it and when it was run are more interesting challenges. I find that most if not all of these examples of Agile Test Cases work best if you involve dead trees. As in print them out. But I never made the leap from being able to take notes in a different window while testing in another without losing flow. The original SBTM paper suggested that your notes should be just in raw text so anything in there could also be parsed by some tools. In either event, what you want to do indicate whatever you need to clear an audit on the test case. One one project we printed out the mindmap and initialed with a check or x beside each node and the date. And then the artifact has to be returned to version control (likely with a different name to allow for easy test case reuse). If it is from a dead tree, then it needs to be scanned and captured much along the lines of how some teams will design on the whiteboard then take a picture of it.

But truth be told, I recycle the paper when I am done with it. Why? Well, partly because I don’t do stuff in a regulated environment so don’t need to archive it. But also because a key attribute of Agile is Trust. If I say that I tested something then that is actually enough.

But as with everything, how you manage your tests is entirely dependent on your needs. Not mine. Or anyone else’s.

So what makes a system/means of managing test cases ‘Agile’? It depends of course. Marketing teams certainly try through the use of smoke-and-mirrors to make their products Agile … and sometimes that works. But to me, there is a barrier to entry.

• Version Controllable – When I am coaching new test teams, I use the phrase ‘If it has value, then it is versioned. If it does not have value, it does not get created’. You need to version for (at least) two reasons; to compare between two versions and to know what is the ‘golden’ copy of whatever you are using for test cases
• Natural Language – Test cases should be made by humans and consumable by humans. That does not mean that that a machine cannot also consume it (such as in the Executable Specifications context).
• Text – Application source code is just text, so why not your test cases as well. They are just as important. But the big thing is that it does not need to be fancy. The facts, and just the facts as it were. It does not need to be underlined, bolded, multi-sized etc. This means you don not need to use MS Word, etc. as the editor. Heck, you don’t really even need to use HTML (unless you are using something like Fitnesse which uses that as it’s storage means). The loophole around this when it is something visual (like a mindmap or screenshot)
• No Fluff, Just Stuff – This is a general comment, but I’ll put it here anyways. You do not need to have version data in your test cases — that is what version control is for. You also do not need an executive summary, or a definition section, etc.
Brain On – Testing is a sapient activity; it is brain on. If the person executing the case can do it without turning on their brain, then it is too limiting. Automated Acceptance Tests and Exploratory Testing are parts of Agile testing; rote script execution is not.

Of course, these are all heuristic. There are absolutely situations where each of these attributes are false, but I think those are few-ish and far-ish between.

Long gone are the relative safe topics from the first three posts in this series and we’re well into realm of dangerous with Specification and their automated compatriots, Executable Specifications. Speci-what? Executable who? Exactly. Both of these are tenants of Agile but are only just starting to cross over from the realm of the ‘cool kids’ and into the near-mainstream.

So what is an Specification? I’m labelling it as a concise, natural language description of an desired behaviour [of your application]. Once it is automated it becomes and Executable.

Notice the word behaviour. These are central to BDD (Behaviour Driven Development) and ATDD (Acceptance Test Driven Development) which appear to be the same thing, but invented on different sides of the Atlantic. But just like with SBTM, the whole flow of BDD/ATDD is out of scope and I’m interested just in the specifications themselves.

So.

I’ve got lots of notes from talking to lots of people, so here is the dump of them. Hopefully something will arise from it.

• There is no ‘right’ or ‘wrong’ way to write these, though some tools enforce a particular way
• A large part of why you develop specifications is to get everyone talking and agreeing that this is what we are building
• It is important to agree upon, and correctly use, the various verbs and nouns
• Specification do not describe the implementation, only the desired end result
• And so are at the domain level, not the UI level
• A Goal will be solved by n stories, and those stories will have y specifications
• Two common ways of constructing these are Tables (Fitnesse) and Declarative (GWT)
• But if those don’t work for you, create your own
• The tester / automator does not get to change the specification once it has been created (without business approval of the new specification)
• It is a value/ROI judgment that determines whether a specification is automated or not
• Bug it is highly desirable to do so
• Which requires certain strategies sometimes (see Agile Test Automation Strategy For the Non-technical for some of them)
• Specifications is a synonym for Example

The exercise for this one is going to likely be to use the GWT format to create a series of possible specifications for a story. What that story is exactly is tbd.

In the ongoing series of posts on Agile Test Case Management (which is pronounced ‘figure out things for my talk on Thursday’) I am now heading onto slightly shakier ground with Session Sheets. Session Sheets are the tracking method of proposed in Jon Bach’s paper Session-Based Test Management. SBTM itself is a much larger discussion and one that is beyond scope here. What is in scope is the sheets themselves as they are, according to Jon, the magic ingredient of SBTM.

Sheets themselves are…

• plain text (not .doc — that is a binary format)
• tagged for categorization and organization
• machine readable
• stored in revision control
• highly customized to the team and context

That could describe, well, almost anything. And it is supposed to; you are doing it wrong if you don’t tailor it to your environment. But what distinguishes a ‘good’ sheet and a ‘bad’ sheet. Again, beauty is thin the eye of the beholder and the devil is in the details – or rather in the charter. A session’s charter is what guides the testing and provides the mission. If you get the charter ‘wrong’, then everything else is as well.

The key thing, to me, is the detail of the charter. A good charter guides the tester, but does not direct. The Agile community is used to thinking in this stepped-back manner from dealing with user stories but it is mind-bending to new people or those still in a waterfall-ish environment.

According to Rob Sabourin at Star East 2010 a charter is…

• under 160 character
• statement of mission
• ties to purpose
• focuses work
• confirms understanding
• delineates scope

Also from Rob and Jon are a list of ‘types’ of charters.

• Discovery – searching for broad knowledge
• Capability – typically starts with ‘Confirm…’
• Failure Modes – what could break
• Quality Factors – the ‘ilities’
• Usage Scenarios – happy, sad, evil
• Creative Ideas – soap opera testing
• States
• Data
• Environments
• White Box
• And a myriad of different domain specific ideas

This list shouldn’t be considered definitive or complete, but should help guide and mould your thinking of charters. A well SBTM’d (yes, using it as a verb) product will have a mix of each. But again, the mix will change from group-to-group and project-to-project.

As an activity for this, I’m planning on ‘borrowing’ Rob’s idea of a charter contest — but without the contest part. Basically it will be a create-and-share each type of charter. Lots of practice — I have lots of chart paper and crayons.

This is second post in the series that will eventually turn into a my Agile talk. It also the easiest one to cheat on as I’ve more or less already written it. You see, mindmaps as a test case management system was 1/3 of my chapter in Beautiful Testing and since it the chapters are under Creative commons I can link to it directly.

But for the lazy…

• Provide a concise, visual means of tracking test ideas
• Are the secret way the testing cabal keeps track of things; not bullets or essays.
• Show only the what of testing, not the how
• As you think of new things, add them
• Standard ‘brainstorming’ rules apply: anything can be added, those some will be pruned later
• One strategy that has worked for me is each person does a different ‘feature’ in isolation, then the group expands it
• Projecting mindmaps onto a whiteboard is pure win
• Unfortunately, the formats are usually binary or formatting which means diff’ing versions is near impossible
• If auditability is really a concern you can print out the map and initial beside the end node with the date saying the result

The exercise for this one is going to be, unsurprisingly, to create a testing mindmap. And then we’ll compare them to see which ideas different groups come up with.

My session this year at Agile is on ‘Agile Test Case Management’ which looks at the various ways we can manage test cases without needing to have the ridicuouls amount of never read, took too long to think of, highly constraining documentation that is found on too many non-Agile projects. (And I’m sure on some ‘Agile’ ones as well.) This is the first of a series of posts as I explore my thoughts on them. (Yes, I know it is only five days from the talk time and I’m just starting…)

• Most testers use checklists to organize their thoughts. Don’t believe me? Look at their desk. It is covered with notes to themselves about current and future test ideas. Calling those notes a checklist is just a giving it a nicer name
• Checklists are not new; other professions have been using them for years. And years. (And years.)
• Like say ‘law’ and ‘psychology’ (all taken from Cem’s paper below)
  • Use them as aids to critical thinking in the moment, rather than as directives to be followed.
  • Myth: A script acts as “training wheels” for the new tester to learn the application domain, the program itself and how to test it. (This is a hard myth to accept and rebuff — I still have trouble with it.)
  • Students learn (and transfer) better when they discover concepts, rather than by being told them
  • Adults benefit from activity-based and discovery-based styles
  • A script specifies
    • test entry conditions
    • test operations
    • expected results
    • comparisons the human or machine should make
  • It is not about just what to ask, it is why
  • Data Collection checklists..
    • help you prepare
    • are broader than needed
    • are used in the context relevant order (not in preparation order)
  • The smart checklist designer(s):
    • captures test-relevant information
    • and organizes it into lists
    • list items are often annotated
  • Lawyers use checklists and predesigned forms, but customization is seen as a fundamental requirement of professionalism
  • lists are reminders, not scripts
• Atul Gawande turned an article in the New Yorker on checklists in medicine into a whole book on the subject.
  • The average patient required a hundred and seventy-eight individual actions per day
  • Generalist vs. super-specialist
  • But what if experience is not enough? Enter the checklist
  • Nurses have always had their ways of nudging a doctor into doing the right thing, ranging from the gentle reminder (“Um, did you forget to put on your mask, doctor?”) to more forceful methods (I’ve had a nurse bodycheck me when she thought I hadn’t put enough drapes on a patient). – See also my post on Mitigated Speech
  • The researchers found that simply having the doctors and nurses in the I.C.U. make their own checklists for what they thought should be done each day improved the consistency of care to the point that, within a few weeks, the average length of patient stay in intensive care dropped by half.
  • Two main benefits
    • Help with memory recall, especially with mundane matters that are easily overlooked in patients undergoing more drastic events
    • make explicit the minimum, expected steps in complex processes
  • Checklists can also bring to light organizational problems that only management can address properly
• In my experience, the best checklists (for testing)
  • Focus on a specific idea
  • Contain heuristics and mnemonics
  • Prod, but don’t bully towards the desired action
  • Can be used by anyone — and will have slightly different results (which is a Good Thing)
  • Can contain very specific items if warranted
  • Are tailored to the environment / task

Since this is at Agile and the prevailing way of learning is action, there will be two activities associated with checklists. The first is to create a checklist on how to test something (tbd) before — and then revist it after I ramble a bit. The second will be to create a testing mnemonic (because I really like them).

Resources:

• The Value of Checklists and the Danger of Scripts: What Legal Training Suggests for Testers – Cem Kaner, J.D., Ph.D.
• The Checklist – Atul Gawande

The Business of Software Conference is increasingly demanding attention on my ‘I think I could learn a lot from’ list. So it was not that surprising that the recording of Kathy Sierra’s talk from the 2009 version caught my eye. And continued to hone my opinion of how businesses should be run and my orientation towards certain details when testing.

• ‘Get Lucky’ is not a business model
• Which is better?
  • Their product is awesome
  • Their service is awesome
  • Their company is awesome

  It’s actually a trick question. The right answer is I’m awesome

• People with passion…
  • Show off
  • Learn
  • Continuously improve
  • Spend time
  • Spend money
  • Evangelize
  • Elevate the meaning
  • Connect
• Its not about the tools, its about what the tool enables
• Don’t sell me, teach me and I’ll sell myself
• I don’t want to be an expert at the camera, i want to be an expert in photography
• Don’t make a better [x], make a better [user of x]
• Don’t make a killer app, make a killer user
• Focus on what the user does, not what you do
• What [bigger cooler thing] is enabled
• Make the right thing easy and the wrong thing difficult
• 10 years vs 1 year repeated 10 times

TWST is the Toronto Workshop on Software Testing and is, well, a workshop on software testing in Toronto hosted annually by Fiona Charles and Michael Bolton.

This year Fiona posted this as a focusing topic:

I’m really interested in how we report on testing to project stakeholders.

Do we use narratives, graphics, metrics, or a combination? How do we decide which is most appropriate for the context?

There’s often a dichotomy between how/what we want to report (and believe we should) and how managers and others expect us to report. How do we resolve the differences to everyone’s satisfaction — or at least acceptance?

I had no idea what I was going to talk about that would generate discussion, until I listened to Malcolm Gladwell’s Outliers. You know, the book about the 10 000 hour rule for excellence. Except that rule is chapter 2 — and that it. There is so much more to it, including the notion of Mitigated Speech. That to me was the most important part of the book. And I think fits (loosely) to the topic of TWST this year.

Let’s start with a definition (according to Gladwell) of mitigated speech.

Any attempt to downplay or sugarcoat the meaning of what is being said

How often do we see this when communicating our quality related information to stakeholders who are not going to like what they are going to hear.

In Outliers, Gladwell makes heavy use of the research contained in the paper Cultural Diversity and Crew Communication to analyze the communications of a well known plane crash.

So what are the levels of mitigation?

• Command – This is all about Power Distance. How do you perceive and relate to your superiors? Your culture’s PDI has a lot to do with that.
• Team Obligation Statement – Reduces the power distance in the relationship as it includes but the receiver and the sender in the action.
• Team Suggestion – Equal power distance and implies full evolvement of both receiver and sender.
• Query – A concession that the sender is not in charge, and is phrased as a question
• Preference – Possible preferred actions presented in terms of I think or I feel
• Hint – Are a reminder to some previous goal but don’t directly suggest the actual action the sender is hoping for. In fact could result in a different action.

Note that nowhere is there an indictment of any of these mitigation levels. The trick is to know what they are, when you are using which level — and whether it is appropriate at that particular context.

I’m in a carb coma right now thanks to Melt, so going to indulge a bit of Seth Godin fanboy-ism by going through the 74 posts I haven’t looked at since my birthday and pick out the interesting bits. I’m sure there was other things of value in there, but these popped out. (Again, carb coma.)

I’ve talked about the 1000 fan thing before, The circles (no more strangers) has a fantastic chart to illustrate the stages to True Fans. And some ideas around it.

Multiple dumbnesses makes reference to Howard Gardner’s Theory of Multiple Intelligences. Not sure how to use it, but its interesting.

Apparently Seth has a lot of voices in his head — which he has categorized in Is this noise inside my head bothering you?. These would make a good first batch of personas to test as.

And in Archetypes at work has another list that could be similarly used.

Play a new game, not the older game but faster. Kinda sum things up. (via A car is not merely a faster horse)

The product development world has long been divided along ‘developer’ and ‘tester’ lines. Agile has show that the divide is not useful (in most cases), but that is secondary to the point of this post. Harry Petroski was on IT Conversations to promote his book The Essential Engineer and talked about another divide between scientists and engineers. The parallels are striking.

• Scientists seek knowledge and/or understanding – Testers?
• Engineers are looking to solve a problem — that is usually stated before hand – Developers?
• Science and engineering are inexplicably linked – see Agile
• One can drive the other – Feedback loops
• An underlying problem is that scientists have better status than engineering – compare the salaries between developers and testers recently?
• Engineering is more than just ‘applied science’ — things just aren’t that simple – testing is more than just ‘finding bugs’
• Maintenance will inevitably cost more than initial development

I was getting a drink for the train ride home when a giant cover of Seth Godin got my glance on the shelf. Seth is an interesting figure and the magazine was titled MOTIVATED (yes, in caps) so I picked it up. Here are the parts that testers will (or should) care about.

General Observations

• The editor’s email address uses the magazine’s publisher’s domain, not the magazine’s. That, to me, is a breach of the consistency heuristic.
• Definitely a Canadian magazine; will need to expand its advertising if it wants to survive I think
• Ironically, there was nothing new in the Seth Godin interview which was word-wise one of the smaller articles in the issue — though it did succeed in getting me to buy it
• The Naked Consulting article was eye-opening enough to more than make up for it

Watch Me! Audacity without Ego

• Audacity creates businesses, and art, and world ranked athletes
• Audacity is breathtakingly beautiful in her internal confidence; Ego seeks external recognition and often offensive.
• It can be very lonely when we choose to be audacious excuse culturally we’ve thoughtlessly accepted the notion that we shouldn’t challenge the status quo, that there are certain ways of doing things that there’s an order that needs to be followed while on the journey toward success.

Life is a Rollercoaster, not a Rocking Chair

• Miles Hilton-Barber is truly an amazing person. Attention conference organizers – this is the type of person you get for you’re keynote. Who cares if he doesn’t have experience with testing or development? He has worlds more experience in other things that analogies could be drawn to.
• …are meaningful not because they’re record-setting “firsts”, but because I set another challenge for myself and I did it!
• Only he who is willing to risk going too far will discover how far it is possible to go – T.S. Elliot
• You an keep going long after you think you can’t
• …the quality of our lives is often determined by circumstances, but b our response to them
• Fulfillment is achieved by working toward dreams and focusing on the thing you can do, not the things you can’t
• Louis Braille was blinded at the age of three, playing with a spike instrument. Many years later he invented the Braille alphabet, going back to millions of blind people the ability to read once again. Do you know what he used to make the raise dots on the paper? The very same spike instrument that blinded him!
• The basic lie plan I often refer t is: Dream, Decide, Plan and Persevere

Boldly Conquer Your Speaking Fears

• It takes commitment and practice to be a great speaker. But above all, it requires confidence, boldness and audacity.
• Great speakers aren’t born; they evolve. They get better over time because they practice much more frequently and much harder than everybody else.
• …in addition to practice, they carried a vision of themselves as outstanding communicators. Great speakers visualized themselves electrifying their audiences, even when they had very little experience in public speaking
• It all started in her imagination and a crystal clear picture of what she wanted to accomplish. For many peopled, confidence does not come easily but if you see yourself succeeding long enough, soon you’ll believe it and you’ll radiate the boldness of a winner.
• When you change the way you see yourself as a speaker, what you audience see will also change.

7 Steps to Taking Centre Stage

• Passion – Passion makes you want to get up early and get to work. Passion gives you the energy to work harder and longer than anyone. But you also have to feed your fans’ passions
• Knowledge – Keeping up with your industry and the world around you not only keeps your mind sharp but also gives you the ability to recognize trends and opportunities before anyone else.
• Networking – Networking is about forming relationships and finding ways to work together on any number of projects.
• Marketing – You should always have something to leave behind whether it’s a business card or some other item
• Organization – I have a plan. I know what I’ going to say. I’ve done my research, searching facts and figured. I have contingency plans, extra batteries, and my presentation on flash cards as well as on the computer. Any my list goes on. When you have a plan and you’ve organized, I guarantee you’ll have more confidence at whatever it is you do.
• Appreciation – No matter how big or small your organization is, never underestimate the importance and the power of saying thank you.
• Fun – Remember to enjoy the ride

The Brand Within

• A brand is a collection of perceptions in the mind of the consumer
• Success in business, or in our personal lives, will always comes down to the connection we have with others
• Some branding principles: differentiation, core values and purpose, knowing your consumer, production great products and providing superior customer service, consistently delivering on your promise
• He’s not perfect, but no brand is
• Building your own personal brand takes time
• Nothing happens by chance
• 5 steps to branding you: identify your core values, create a mission statement, know your customers, create a positive brand experience, be yourself
• 5 ways to derail your brand: disconnect between you and how others perceive you, poor judgement in ethics or morals, inconsistency in behaviour, not aligned with organization values, strategy, or goals, competency and skill set

Let Your Light Outshine You Fear

• Name your heart’s desire – Get clear with what you desire
• Inner/outer alignment – Someone living in alignment emits a glow of authenticity, powerful upward movement, and innovation
• Holy boldness – Driven by our mission, we walk over hot coals to do what we have to do
• Courage in spite of fear
• Commit to a crazy idea – Within those wild ideas will be the diamond of you next best step

The Merits of Naked Consulting

• This was a reprint of an article that appeared in the February 2010 issue of Business Week
• The essence of naked consulting is that clients are more interested in candor, humility, and transparency than they are in confidence, authority, and perfection. That’s not to say that competence is irrelevant; clients need to know that we have the knowledge and experience to help them. But once we’ve reached that level, the best way to differentiate ourselves from the competition—not to mention help a client implement our recommendations—is to be vulnerable with them.
• Vulnerability is the opposite of, well, invulnerability. It’s about honesty and authenticity. And it’s about overcoming the understandable fears that cause us to say and do things that hurt our relationships with clients
• What does being naked mean in practice? Naked consultants confront clients (kindly) with difficult information and perspectives, even if the client might not like what he or she hears. Naked consultants also admit their weaknesses and willingly acknowledge their mistakes. They ask potentially dumb questions and make potentially dumb suggestions, because if asking those questions or suggestions might help their clients, it is worth doing.
• Even before landing a client, naked consultants will demonstrate vulnerability and take risks. They will give away their best ideas and start consulting to the prospective client during a sales call. In fact, they’ll do no real selling at all, foregoing that activity in order to find a way to help a potential client even if the business never actually become a real, paying one.
• Three way to “consult naked” starting today:
  • Confront clients (kindly) with difficult information and perspectives, even if the client might not like hearing it
  • Admit your weaknesses and willingly acknowledge your mistakes.
  • Ask potentially dumb questions, and make potentially dub suggestions, because if asking those questions or suggestions might help your clients, then it is worth doing.

Cem Kaner was at TASSQ this evening to talk about applying test techniques to the evaluation of the models we build into software, to help us decide whether we are building the right thing, to address validation and accreditation of software instead of burying our heads in verification. And he did, though in going into the meeting I had focused on the sentences before and after that one which mentioned ‘automated exploratory testing’ which, as an automation consulting tester I was keenly interested in hearing Cem’s thoughts on the topic. So with that in mind I thought this was the poorest (personally) of the talks I have seen him deliver. Until that is, Paul Carvalho phrased it as a case study, as an experience report. With that frame of reference, it was an excellent talk which showcased in depth, methodical test probing of various financial models in a way only someone with his training and background could provide. Here are my notes.

• There are green bananas and ripe bananas and rotten bananas and big banana and little bananas. But by and large, a banana is a banana — on commodity level software testing. The lesson is don’t be a banana — though a preferred alternative fruit was not provided
• There are a number of levels of testing; five that fit on the slide are
  1. checking
  2. basic exploration
  3. systemic variation
  4. business value
  5. expert investigation

  I first interpreted this as a linear progression, but as he described them it appears as it was more 1, 2, then people tend to specialize in either 3, 4 or 5.

• The last three in the list allows a tester to ‘earn their keep’
• The decision to automate a regression test is a matter of economics, not principle
• Automation is a starting point to say it is ready to test, not that it is ready to ship
• The most important slide from the deck I think was on the seven risks to any model.
  1. model – the model is theoretically incorrect
  2. characterization – the model is correct, the spec is wrong
  3. comprehension – we misunderstood the model. our code accurately implements the wrong model
  4. implementation – our code inaccurately reflects our intent
  5. execution / environmental – platform too slow, volume issues, etc
  6. tool – the test tool misleads
  7. scope – the model is properly developed but it is not appropriate to today’s circumstances
• Implementation is the easiest to find and the least business value
• Computer programs are solutions to people’s problems
• If you understand the subject matter of the business and use that expertise in test design then you have true business value
• There is skill in empirical research that we have as testers that can be applied to any area that uses software. and that software is just a representation of a human model
• Focus your work on answering the questions you are trying to get answered rather than supporting your automation

Even with the correct context likely in place for the presentation, I have two complaints; both minor in the grand scheme of things.

• In his ‘opening rant against regression testing’ he said as agile development has gradually failed. Maybe it is because part of what I do is agile coaching-ish, but I felt it came off wrong and detracted from his point.
• The slides are terrible. I mean, they are loaded with information, but they are massively overloaded. The deck is not the presentation, the presenter (Cem in this case) is the presentation. Had it been anyone less trained and practiced in public speaking they could have just read from the slides and been coherent. Of course, I get the opposite complaint about by decks so lets call it a wash.

The title page of the deck mentioned that he will be doing a presentation as a keynote at this year’s CAST which seems like a good enough excuse to plug it. I won’t be there as my wife is at a conference in Alabama at the same time and then it is a Agile the following week, but it should be good. (As always.)

Nolan Ryan pitched in a different era, where pitchers were not on pitch counts and were not ‘coddled’. For the non-baseball readers, a pitch count is just that — the number of pitches thrown, and when a magic number (usually around 100) is reached the pitcher is pulled regardless of whether they still have command and strength to remain. During his career as a pitcher he threw 222 complete games and worked hard to stay in form. Well, he is now the president of the Texas Rangers and is re-instilling that sense of work ethic to the team. This change is documented in the May 24, 2010 Sports Illustrated in Nolan Ryan’s Crusade — the contents of which I can’t find on the SI website.

But here are the interesting parts that apply to testing and culture (painstakingly typed out even).

• What’s wrong with pitchers today? For one thing, they don’t learn to think for themselves anymore. Coaches started calling all the pitches in high schools and colleges. How do they know, sitting on the bench, what the guy on the mound has confidence in?
• Pitchers have been pampered. I’d go to spring training, and al they”d do was throw on the side. Now how in the world do you learn how a hitter’s going to react to your pitches without a hitter in there?
• Today a quality start is six innings. What’s quality about that?
• Their ceiling has been lowered. It’s up to us to jack it back up
• Texas hurlers have embraced Ryan’s challenge to raise their expectations and take ownership over their starts.
• Backing away from a pitcher’s limits too far doesn’t make a pitcher less vulnerable; it makes him more vulnerable. And pushing the envelope, while it may lead to a catastrophic event, is more likely to enhance the pitcher’s durability than to destroy it.
• …on the first day of spring training last year Maddux stood in front of his pitchers and said, “Pith counts are limits. You have no limits.”
• The Rangers instead believe that not all 100-pitch games are created equal. Some are more stressful on the arm than others, and if the pitcher is cruising late in the game, there’s no reason to hive him the hook.
• Ryan ordered that pitchers throw live batting practice to hitters from Day One of spring training — a routine almost unheard of in Big League camps…
• They were the first team willing to think outside the box and now they’ve started a chain reaction
• It is important to have people who are willing to make a commitment