• I did Karate for eight weeks
• My friends in highschool were ninjas
• I did Kendo for a year
• I have seen hundreds (and hundreds) of hours of Anime
• My son now takes Karate so I’m hanging out at a dojo again (if only in the lobby)

Infinitely qualified, see?

First, I think we should steal the Tea Ceremony for its ceremony and presentation. Specifically designed rooms, lots of steps in specific order, repeatability and lots of history make it a fantastic specimen.

Oh.

Wait.

The Factory School already got to it.

Next then let’s steal Anime, or more specifically its Tropes. But let’s steal in a sensible way. Rather than apply things directly, each of these should be considered heuristic. And some of these are almost designed to baffle management. Imagine seeing ‘Quivering Eyes’ or ‘Snot Bubble’ or ‘Idiot Crows’ in a status update on the techniques used on a project. Priceless!

When I first thought of this post, I’m sure I had something on Japanese Gardens but can’t remember what, so that is left to the reader.

The final thing to steal is the notion of Shinbutsu shugo which is the syncretism of Shinto and Buddhism. In a testing context, there is Agile, Context-Driven, ATDD/BDD and Artistic camps. Each has its own priests and followers which get involved in religious debates. But the reconciliation and idea sharing is important regardless of religious differences. And now we can give a Japanese name for it.

And if we’re really good, we’ll mispronounce it.

• 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.

• 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.)

• 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.

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’

• 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.

• 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.

• 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.

• 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.

• 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.

• 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

• ‘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

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.

• 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

• 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.

• 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.)

• 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

• adam.goucher.ca – This will be ‘testing’ focused with the usual book reviews, podcast summaries and other things I think people interested in testing mind find useful.
• element34.ca – This is my ‘work’ site and will be catching anything dealing with Selenium. Which kinda makes sense since I now make my living off of Selenium and want potential clients to go to that site.
• seleniumhq.wordpress.com – This is the ‘official’ blog of the Selenium project and I’m going to start posting the Smattering of Selenium content there so it can reach more than just those who have stumbled upon my blog.

I think this split better serves the [core] audiences of the content better, and in the long run might actually expose it to more people.

Properties Files

Java’s native method for configuration information is the java.util.properties class. So if you are going to pass information into your framework, and let’s face it, its a framework so you will, use properties files. Not Excel, csv, yaml or some crazy propriety format. Use properties. Not only is it built into the language but it is a text format so can be checked into version control (and diff’ed, etc.).

getResourceAsStream

This builds off of the first point. Do not put paths into your code! Java has this thing called the classpath. You know, that thing that tells the JVM where to look for things — like properties files! Conveniently enough, you can parse a properties file as a stream from a file that was located in the classpath.

package ca.element34.flyingmonkey.environment;
 
import java.io.InputStream;
import java.util.Properties;
 
import org.apache.log4j.Logger;
 
public class ReadEnvironment {
  static Logger log4j = Logger.getLogger("ca.element34.flyingmonkey.environment.ReadEnvironment");
 
  public Properties ReadEnvironment() throws Exception {
    Properties environmentProps = new Properties();
    InputStream is = this.getClass().getResourceAsStream("/environment.properties");
    environmentProps.load(is);
    log4j.info(environmentProps);
    return environmentProps;
  }
}

Some things to keep in mind with this:

• The directory that contains the environment.properties file needs to be in the classpath. Don’t put the file itself in the classpath. You have no idea how many times I made that mistake when I was at HP…
• You need to have the leading / in the filename. Without it, the package hierarchy is searched and not the classpath
• You will likely have a number of environments that your framework needs to interact with, so have an environment.properties.development, an environment.properties.staging, an evironment.properties.production, etc. But don’t have checked in an actual environment.properties file. Instead, create a symlink to the file on the local machine.

Part of my role as a Selenium Consultant is to dive into a team’s code and spot things that will likely hurt them in the long run. My typical technique is to run the framework on a platform they are not using — it should work. And when it doesn’t, these two tricks will go a long way in moving it a lot closer to working.

And this isn’t to pick on just Java. Python and Ruby have similar native tricks for accomplishing this as well.

def enable_bubbles(se):
    if se.is_element_present("//span[@id='PinBalloonSelector']"):
        se.get_eval("window.ShowBalloonButton.set('checked', true)")
        se.get_eval("window.PersistBalloonPinMode()")
 
    se.wait_for_condition("selenium.isElementPresent(\"//div[@id='balloonContentDiv']/div\")", "60000")

Important things to note:

• YUI buttons are children of the window object so start your hunt there
• To ‘click’ the box on you set the attribute ‘checked’ to true. Setting to false ‘unclicks’ it
• After the click you need to call the JS function that would normally be triggered as we’re sneaking operations in under-the-hood
• Because all of this is happening in JS, you need to use the get_eval variant that your binding provides

That took me well over a day to figure out, so I figure someone else has likely run into issues where Se-IDE has recorded a button interaction one way but on playback or export it didn’t work because the button isn’t an HTML button, it is a YUI button.

So who wants to write a plugin for Se-IDE that deals with YUI controls properly?

• Twitter and between my followers who use Se and the RT’s it got hit an audience of I would guess ~ 150 – 200
• the selenium-users mailing list which has 1736 members
• the selenium-developers mailing list which has 308 members
• IRC which usually sits between 30 – 50 these days

Overall an overwhelming lack of interest to the survey was shown. And yet, meetups like the San Francisco Selenium Meetup get ~ 100 people once a month so there appears to be a market for geeking out over Se.

The first question was about location, and to be honest, I have no idea how to interpret this other than What’s wrong with Toronto?.



Well, it is not really a shock that Silicon Valley got the most votes given the community legwork Sauce Labs has done already. The high Maybe response to Chicago is a positive though (as I like it a lot better than the valley). But Chicago in November is likely not the easiest sell. Maybe we should have it in Cozumel; Sun, Sand, Selenium!

The next question was on length. The format wasn’t an option (single track) just the length.



Useful, but I think 2 days content + 1 day tutorial is right answer as it is long enough to provide a mix of content and be able to justify travel. A one-day conference, that isn’t intended to just be a regional one, is just an extended meetup.

The third question confirmed a lot of what I thought it would, and means I’ll I have to convince a bunch of the Se2 kids to come speak.



The trick, as with any one-track one is to make the speakers diverse enough to not bore the entire audience all the time on topic they don’t understand or don’t care about.

The last non-free form question was the whole cost thing which was interesting, if not really useful information. Conference pricing is often done on a backwards basis in that you get all your fixed costs figured out, subtract your sponsorships (paid and/or expected) and then you arrive at a number. And then pray you don’t lose your shirt.



I suspect if I put down $75 as the lowest amount, it would have been the most. I’m guessing that the $200 roughly maps to the ’1 day’ length of question 2, so doubling that to 2 days is $400 which is close to $500 and combined have the overwhelming total (all but one) then things are in agreement with what I had hoped for. SeConf would not be a huge production like Star and so wouldn’t need to charge as much. I would actually consider it a failure if we had to charge more than $500 for the conference. Tutorials, as is the common model, would be extra.

The final question was just a text box which resulted in lots of how come you didn’t pick my city? type responses.

I’ve still not wavered from the idea that there should be a dedicated Selenium Conference this year. Though we’re getting perilously close to being too late to have one this year given lead times on facilities and speaker travel planning. Especially if I am the driving force / organizer of it. I know exactly when and where the 2011 should be, but thats getting the cart in front of the horse somewhat. I may just have it in Toronto, survey results be damned; as someone pointed out yesterday, the trick is to have it happen this year. We can make it a huge success next year.

• The repairman has to begin each job by getting outside his own head and noticing things; he has to look carefully and listen to the ailing machine
• Knowing what kind of problem you have on hand means knowing what features of the situation can be ignored
• A realistic solution must include ad hoc constraints known only through practice
• Creativity is knowing what to do when the rules run out or there are no rules in the first place

All of these illustrate the importance of practice, knowledge and desire to do the job effectively. To treat it as a Craftsman would any other task. Unfortunately the number of people who treat testing as a Craft is small, though vocal. The testing world is experiencing something similar to what highschool education did in the 90s with the elimination of shop classes in place of computer labs. What schools turn out now are people who know the ‘why’ of things rather than the ‘how’. Or as stated by the executive director of the California Agricultural Teachers’ Association

We have a generation of students that can answer questions on standardized tests, know factoids, but they can’t do anything

If we swap ‘testers’ for ‘students’ in that statement you have a very generalized view of what is happening in the Standardization and Certification camps. That’s great that you know the definition of a testing task, but do you know how to do it, when to do it, and more importantly, when not to do it?

The focus on standardization in the testing world is also partly the cause of the mass offshoring of testing in recent years. If a task can be broken into a series of finite, distinct rules, then the task is able to be delivered globally. Not only that, but according to MIT economist Frank Levy, there is a downward pressure on wages for jobs based on rules.

The way forward then is to treat Testing as Craft, to be delivered by people who take pride in the application of learned skill and knowledge and not as an assembly-line like task where the testers are easily replaceable cogs.

Old bikes don’t flatter you, they educate you

Crawford is by day a motorcycle repair person and is constantly confronted by new problems, scenarios and indeed contexts. He says quite clearly that “Old bikes don’t flatter you, they educate you” and then to show that discovery is not limited only to bike maintenance he quotes Iris Murdoch about learning a new language

My work is a progressive revelation of something which exists independently of me.

Software systems educate us daily, if not hourly as they reveal themselves to our inquiries. How effectively they educate us is largely dependent on how well we prepare ourselves for the eduction. Philosopher Albert Borgmann has the idea of Focal Practice which is the decided, regular and normally communal devotion to a focal thing.

Focal Practice has existed in pockets of the Testing Community for awhile though under many different names. Testing Games, Katas, Dojos and now the Weekend Testing events are all examples of Focal Practice. And seeking them out and participation in are signs of someone who wants to master the craft of testing.

A Series of Masters

In the trades, the accepted way of learning is to apprentice at the side of a Master. They offer a model to follow and pass along their accumulated knowledge. Crawford recounts his education as a ‘gearhead’ in his his teens and early twenties; all of which was informal and outside of the traditional school system. And was utterly important towards his education of the craft.

Now I saw it. Countless times since that day, a more experienced mechanic has pointed out to me something that was right in front of my face, but which I lacked the knowledge to see. It is an uncanny experience; the raw sensual data reaching my eye before and after are the same, but without the pertinent framework of meaning, the features in question are invisible. Once they have been pointed out, it seems impossible that I should not have seen them before.

The testing craft needs to develop more of these situations where the awareness lights turn on, never to turn off again. Not only through the treatment of testing as a craft, but through continued analysis of ourselves as it relates to the problem at hand. One of the big evolutions the Agile movement brought was the periodic reflection of how the process was working at a team level through retrospectives. Crawford speaks on the singular with metacognition which is thinking about your thinking. Or as he describes it

It is what you do when you top for a moment in your pursuit of a solution, and wonder whether your understanding of the problem is adequate.

Is my context [still] correct? Am I on mission? It is the mission I think I was on before?

Another important role of the Master is to allow for learning opportunities through safe failure. Failure is something that has been removed from modern learning. Especially education based on books and theoretical discussion than from hands-on doing. Would you want a plumber redoing your bathroom who has worked under someone with years of experience or who memorized a book and wrote a multiple choice test? Now think about whose hands your software is in.

Tacit Knowledge

So what makes someone a Master? I would think it has a large part to do with the accumulation ,and ability to recall, a substantial body of Tacit Knowledge. This is what Blink by Malcolm Gladwell focuses on and its inclusion in another work lends more credence to the idea.

Just as firefighters will often leave a building just before it collapses — not because it looks like it will collapse, but because it doesn’t look ‘normal’ based upon their years of experience, a Tester can find bugs not because they are obvious, but because something doesn’t look right on the screen in front of them.

Just having the tacit knowledge is not enough though. They have to be able, and willing, to pass along that knowledge which has to be done on a human-to-human basis as it is too complex to capture algorithmically.

‘Manual’ Testers

It is trendy to pour disdain on both people who practice manual testing and indeed the very notion of it much along the way the trade of plumbing has been dumbed down to the image of a slovenly character with their butt hanging out of the back of their ill fitting pants. The trades used to be something to aspire to and commanded respect, now they are the subject of jokes and ridicule. Is Testing destined to go down that same route? I hope not. But if it is to escape such a fate we need to stand up against bad testing education and practices and bring the pride and ethic to it that a Craftsman brings to their work.

Impressions of Shop Class as Soulcraft

This is not a testing book. Instead it is a reverent look at a way of life that is under attack in a systemic manner. Though sometimes preachy, if you are interested in reading about someone’s journey from being a kid who liked cars that went fast to someone who fixes motorcycles for a living and how that can relate to testing then this book is a nice quick read for you. I’m going to say now that it won’t be one of the most important books for testers of the year, but it opened my eyes to a couple new concepts and reinforced some others and for that it was well worth the money.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

import unittest
 
class assertExample(unittest.TestCase):
 
    def setUp(self):
        self.verificationErrors = []
        self.selenium = selenium("localhost", 4444, "*chrome", "http://you.site/")
        self.selenium.start()
        self.open("/")
        self.wait_for_page_to_load("10000")
 
    def testSomething(self):
      se = self.selenium
      se.assertEqual("Login", se.get_title())
      try:
          self.assertEqual("Please login", se.is_element_present("welcome_message"))
      except AssertionError, e:
          self.verificationErrors.append(str(e))
 
    def tearDown(self):
        self.selenium.stop()
        self.assertEqual([], self.verificationErrors)
 
if __name__ == "__main__":
    unittest.main()

First let’s look at the Assert. In line 14 of the above example I’m using a common pattern of Asserting upon page load that I am on the correct page. If the title is not exactly Login, then the script will end and the tearDown function will execute. The rationale here is that if the script has taken you to a page that you are not expecting, then the rest of the script’s results will be suspect — if able to continue at all.

Lines 15 – 18 are the Verify. Notice how it still is based on an Assert provided by unittest, but we are catching the AssertionError that gets thrown on failure. This prevents the script from running and allows us to track the failure to the list that was created on line 6. The list contents are what will determine whether a test passes (empty) or fails (non-empty) which is done in the tearDown (line 22).

Is this the only place to use an Assert or Verify? Of course not, its just a common one. I also use Asserts when something is critical to the purpose of the script (the pass / fail criteria) or when something is worthy of extra special attention. The trick is to use both in a way that makes sense for your application and scripts.

• They mentioned they use custom firefox profiles for their tests to get around self-signed certificate problems. This is one of my great Se pet peeves. DON’T USE SELF-SIGNED CERTIFICATES IN TEST! Actually, unless you are using certificate based authentication, don’t turn on SSL at all in test. And if you, really, really, really think you need SSL in test (you don’t…) then use a real, issued by a trusted CA certificate. Oh, and custom firefox profiles are a good idea in general anyways as it gives you complete control over the environment (prefs.js is your friend)
• The coolest thing about their whole rig was that it was controlled by a bot you interact with on irc. Outstanding!
• They also created a central module (they use Python) which had all their object locators in it. Not really Element-UI and not really GUI-Map, but it seems to work. Se itself should think about how to support this pattern in a clean, well-documented manner…
• XPath as a pretty deserving reputation for being slow as a locator strategy, but seeing XPath in a script is not a bug. XPath is ridiculously powerful. Bad XPath is a bug, but bad anything is a bug. Good, robust XPath is a good way to access an object.

After Mozilla was Linked-In’s turn to show off their Page Object based testing framework. I also have some notes / opinions on it too.

• Their setup method had @env = Environment.new which is a nice object to be carrying around. I don’t know what was in Environment, but I suspect I’ll be stealing the concept. Or re-stealing I guess as I did something similar 4 or 5 years ago in an old framework but stopped doing it for some reason.
• Using the link locator strategy fails when testing across locales. Duh! Why didn’t I realize that before now?
• The whole framework seemed over-engineered. This was only the send Page Object one I had seen, but that seems to be a pattern. Abstraction is absolutely necessary for success, but to what end?
• What was cool as a result of all this effort was there was no direct Selenium commands in the scripts.
• Jason [Huggins] did some like code review during the talk which provided another key thing to remember when writing scripts and that is to let specific tools do what is better when appropriate. For instance, rather than looping through a list of XPath elements in Selenium (slow), hand off the page source to Beautiful Soup or Nokogiri whose sole purpose of existing is to do that stuff (fast)

One final bit of trivia. The meetup was held at the Mozilla (as in makers of Firefox browser) offices in Mountain View. That same building housed the first offices of Netscape — which of course died a slow painful death and whose source code formed the basis of Firefox. What goes around comes around…

• Nascar – act as a feeder series to the main Nascar series
• Superbike – says one insider – ‘These sports are stupidly expensive at this level, and we do what we do strictly for the tertiary benefits’
• Motocross – to move product for the sponsors; what wins on Sunday sells on Monday (incidentally, my bike will be orange for that reason)

Understand why a team exists will put all of its activities in to their proper scope and priority. Misunderstanding it will result in (potentially lots) of wasted money.

The same thing with testing. If you don’t know the why of what you doing, then you are not testing, you are just flipping switches.

<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
 
<overlay id="preflight_extension_loader_overlay"
         xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
         xmlns:html="http://www.w3.org/1999/xhtml">
    <script type="application/x-javascript" src="chrome://selenium-ide/content/api.js"/>
    <script type="application/x-javascript" src="chrome://preflight/content/preflight.js"/>
    <html:script type="application/javascript">
        ide_api = new API();
        ide_api.addPluginProvidedUserExtension("chrome://preflight/content/extensions/extension-random.js", "chrome://preflight/content/extensions/extension-random.xml");
    </html:script>
</overlay>

Yes, sorry. That is an XML file that needs to be provided. I could have completely rewritten things to not take XML, but the existing code expected it and working is better than pretty more often than not. Here is the format of that XML.

<apidoc>
  <function name="randomString">
    <param name="options">type and length separated by a pipe. type can be alpha, number or alphanumeric</a></param>
    <param name="var">variable to store random string</a></param>
    <comment>Generates a random string of specified type and length</comment>
  </function>
</apidoc>

Now the astute readers will notice that the information contained in that xml looks suspiciously like that which is is the Reference tab of the Se-IDE. And you would be correct. But that is also the source of another bug that has yet to be addressed: if you want to have your functionality appear in the reference box, it will also be exported via the Se-RC formatters.

This new functionality will be available in the version 1.0.7 of Se-IDE which should be out in the next week.

• Yesterday’s solutions appear on the front page of the paper as today’s problems.
• For a solution to metamorphose into a problem it first has to work. Solutions that don’t work fade away, like Esperanto. The solutions that haunt us are the ones that function well
• Problems are reincarnated solutions. One could say that problems get second leases on life as solutions, or solutions get second leases on life as problems
• A solution is something that substitutes itself for the problem it has eliminated
• There are no solutions, only replacements of one problem with another. This doesn’t mean that all problems are equal, only that all problems are problems. The best we can hope for is that our solutions will be problems we prefer to the problems they have replaced.
• Some replacement problems are more manageable than their predecessor problems and therefore they’re easier to mistake for solutions.

So how does this relate to testing? Two things very clearly jump out at me.

First is the whole notion of automation. Testing was slow so lets put an army of machines to work! Seems like an excellent idea on the front of it, until you get tools that allow for quick, but horrible testing.

The second is information overload and the use of Metrics. Yes, the modern software development project has a lot of information to juggle and using algorithms to help navigate it is a good idea. Except when taken to the extreme and entire courses of action are determined by math and not by humans making rational tradeoffs and decisions. Just ask the quants on Wall Street how well that worked in the last decade.

• There are three types of training: initial, transition, recurring
• Although [air traffic] controllers do not need a college degree to be hired; it helps. – Ah ha! Another industry that is confused about the value of formal education.
• Fatigue Science and defect rates is a post-graduate paper waiting to be written
• Leadership in the cockpit (by the Captain) is a top issue for regulators currently. I think part of the testing world is in good shape from a leadership perspective, but it needs to keep spreading.
• There is a spooky reliance on ‘intelligent automation’ in the next batch of planes. Where is today’s test automation [in general] on the intelligent / dumb-as-rocks scale?
• Training for the Embraer Phenom series jet is tailored to the pilots current experience, skills and deficiencies emphasizing certain parts over others depending. Nice! Tailored training is what will separate the next wave of coaches from the rest of the pack.
• The laughable ‘security theatre’ that one goes through at airports is recognized as such by people in the industry. And yet it persists. When does ‘testing theatre’ or ‘quality theatre’ enter the lexicon?
• Powerpoint training lacks context, interactivity, instructional design and graphic design. Hear hear! Powerpoint should support the training, not be the training.
• Four steps to alter attitude through training: motivate the learner, help the learner diagnose their challenges, empower the learner with knowledge to overcome challenges, reinforce the learning
• In a show report from the ‘Aerospace & Defence Training Show’ in Dubai, the following bullets are identified as challenges.
  • Out-of-date checks, which do not address the threats of modern aircraft operations
  • Training and checking for events, which are extremely rare
  • Making best use of limited and expensive training resources to ensure quality training is delivered at affordable prices
  • Combatting increased dependence on automation
  • Incorporating meaning CRM training into training programs
• In the same keynote were some solutions being implemented to address these, including
  • Using evidence based training via recognized programmes, which address legacy training and checking issues
  • Use the considerable data available worldwide to enhance training and make it relevant and appropriate for individual airlines
  • Review possible solutions to address the degradation of manual handling skills – The what?!?!
  • Acknowledging the fact that the 21st century does not mean training has to be wholly technologically driven – we can and must learn from the past

Low-Fare & Regional Airlines

• The proposed legislation … may be a solution in search of a problem
• Hours [of flight time] is no longer a predictor of competence. It is true that to go through all of the things you need to become a proficient pilot, it does add p to a certain number of hours. But what the industry has to get its arms around is having the right kind of training in the right environment to produce a highly proficient, skilled, safe pilot – Ummm, certifications and boot-camps anyone?
• It is going to become ever more important to tailor the training for the environment in which the pilot will operate – Hey, again with the tailored training. A trend from another industry that could be borrowed?
• Same article – Effectively, what we did was mould our training around the student, instead of making the student fit into our training programmes

Divorce Magazine

• So the url on the magazine is http://www.divorcemagazine.com but it redirects to http://www.divorcemag.com/. Dead-tree hand not know what the electronic one is doing?
• This is actually a consumer magazine rather than lawyer-focused which is where the interesting bits would be

There was also The Essential Marketing Guide For Family Lawyers, but its big and has lots of content — just like this post, so it will have to wait.

And with that, your mission from now on fellow conference goers is to crash the other conferences that are going on in the same facility as your conference and get their niche publications. They are the mine from which the next gold nugget will be found.

My observations from this round:

• A Detective variant was still the top hat from the group
• Firefighter was also right near the top of both lists. I continue to think that the people wearing this hat need to have a think about why they wear it and do some corporate structural changing.
• There was significantly more of what I will call ‘old school’ type hats with the Star East crowd. Things like ‘Soldier’, ‘Defender’, ‘Victim’ and ‘Spy’ all, to me, reflect the sort of us-versus-them, command-and-control quality police that still exists in too many organizations. But it was to see whether this would happen, as I thought it would, that the workshop was held
• The teams that people split into tended to be far more insular than at Agile with very little conversation happening between teams. And when the Art was on the walls, few wanted to move things around for better groupings.
• There were still Hats on the wall that had no stickers on them to indicate that someone wore it
• I’m quite happy that Teacher came in second, and Coach in fifth. Aside from the Detective type ones, I think those are important ones every tester should strive for.
• Bottleneck really frightens me. Even more so than Firefighter. As someone who does a bit of agile coaching, I’d be looking at removing that hat from the organization as quickly as possible.
• The hats I listed at the beginning to illustrate the concept were not listed.
• Some teams did just a list of hats, other just the name, others drew the hat and yet others coloured it in (I gave them crayons)

Full Results:

• Sherlock Holmes – 30
• Teacher – 25
• Firefighter – 23
• Bottleneck – 22
• Coach – 19
• Houdini – 16
• Soldier – 16
• Product Support – 15
• Liaison – 15
• Diplomat – 13
• Collaborator (which was a princess hat…) – 11
• Translator – 10
• Battered – 10
• Pioneer – 10
• Hard Hat (to fend criticism) – 8
• Chef (a little of this and a little of that) – 8
• Scapegoat – 8
• Defender – 8
• Traffic Cop – 8
• Victim – 7
• Hero – 7
• Butcher – 6
• Psychologist – 6
• Advisor – 6
• Wishful Thinking (a crown in a thought bubble that says “Its good to be the king”) – 6
• Chef (What? You never bribed the devs with cookies? How else can you make them write unit tests?) – 6
• Reporter – 6
• Doctor/Nurse – 5
• The developers were late getting the material for your hat so we cam’t show it yet. Do you mind telling me what you think of the above anyways? (was a ‘?’) – 5
• Mediator – 5
• Team Player – 4
• Chef (cooking up test automation) – 4
• Keeper of Hats Hat – 4
• Spy – 4
• Chemist (person who does experiments) – 3
• Wizard – 3
• Referee – 3
• Planner – 3
• Guardian – 2
• Happy – 2
• Hard Hat (construction) – 2
• Parent (which appears to be a halo) – 2
• Celebration Planner – 2
• Lawyer – 2
• Clown – 2
• Psychic – 2
• Viking – 2
• Navigator – 2
• Author – 2
• Warrior – 1
• Invisible (things are going well) – 1
• Bandit – 1
• Fun – 1
• Witch/Dominatrix (shared a card so not sure where the star should be applied) – 1
• Conductor – 1
• Farmer – 1
• Judge – 1
• Timekeeper – 1
• Doctor – 1
• Pilot – 1
• Weaver – 1
• Swimmer – 0
• Dunce – 0
• Debugger – 0
• Reference Builder – 0

The gist of the talk is that the biggest inspiration we can have as testers comes not from blogs, or courses, or even other experts, but from living our lives. It is said that you really, really, know a language when you don’t do the mental flip to your first language, translate it, then speak; you just speak. The same thing happens with testers as well. You know you have truly become a tester when you see testing all around you, and not just at your desk between 9 and 5.

The first half of the talk relates how being a house league lacrosse coach has helped me be a better test team lead using strikingly similar approaches to skill development, planning, stakeholder management and efficiency improvements. This is essentially the same talk that I gave at CAST 2008. There is no blog post on it specifically, but I did write a paper on it.

The middle section is all about the lessons I’ve learned about testing from fixing both my washing machine and dryer. I never wrote up the washing machine story, but did with the dryer tale.

The final section is about how we have too much stuff and so I needed to build a shed in the backyard to hold it all. Again, this was documented at the time on the blog here and here.

The talk wraps up with the reiteration of the theme, which is that Testers Notice Stuff. We truly do — often to the detriment to the non-testers around us. Just ask your non-tester friends how much ‘fun’ it is to watch a movie around you.

• Steve McQueen, Consulting Software Tester
  
• If you want to test really well, you need to ferret out the underlying dynamics and principles
• There is no navy that is going to save me. Its just me and my band of friends.
• Think about what makes you unique
• Thing that lead to self-development and earning reputation
  • Project experiences
  • Writing
  • Teaching
  • Speaking
  • Innovation
  • Vision
  • Study
• You earn reputation if you don’t keep it secret
• Are you a buccaneer scholar?
  • You live free – have independence, seek first hand knowledge, self directed learning
  • You hunt ideas – are an explorer, driven by curiosity, intrigued by puzzles, dared by complexity
  • You win your place in the world of thinkers – earned credibility, earned reputation, you have constructed yourself
• Key components to being successful
  • Reputation
  • Portfolio
  • Performance
• You are not a commodity; don’t act like one

• Tellurium is another wrapper around Selenium. Looks like it has a couple things that we could borrow back.
• Why Selenium and Rspec? describes how to use RSpec with Selenium and how to involve both people who can code, and those who cannot.
• If you are writing Se tests, then you should also be running them under CI. Thoughts on Fowler’s Continuous Integration is a nice, quick tour through the [one of] the more important papers on the topic. Good review to some, necessary primer for others.
• Looks like the ‘Se in the cloud’ space is about to get more crowded with regressr coming out of stealth mode soon. (Where is my invite?)
• There is also Selenium Shots which looks like it is a custom Grid which will send you screen shots of what your page renders like in different browsers. I found out about them through their gem
• Another gem that crossed my path was Cross-stub which attempts to solve Existing mocking/stubbing frameworks support only stubbing in the current process. This is OK most of the time. However, when running cucumber integration test suite in non-webrat mode, these in-process stubbing frameworks simply doesn’t help. Or something.
• Want to run your Webrat, Polonium or JSUnit tests in the Sauce Labs OnDemand cloud? You could use the Saucelabs-adaptor gem that the folks at Pivotal have created.
• Gojko discusses How to implement UI testing without shooting yourself in the foot
• Alister Scott, a Watir core developer, talks a bit about the future of Watir, Selenium & WebDriver
• Kevin wastes no time rebooting the Se-Grid project by releasing Se-Grid 1.0.6 which is primarily a bug fix release.
• Testuff is ‘on-demand software test management’. I haven’t needed to use it, but they now have an integration with Se-IDE. Of course, what they should do is make it an Se-IDE plugin, but…
• If you are using Se and Zope2, then Zelenium might be of interest. Or might not. Your call.
• Aaron (after some prompting) ruminates on Smart or Dumb Page Objects.
• I’ve never heard of the ZK Framework, but if you use it then you can run Se tests against it with zk-ztl
• Speed of execution, and the need for increasing it are constant topics in the Se community. Here is one solution that uses Rake – Speeding up multi-browser Selenium Testing using concurrency
• Kevin’s (as in the new maintainer of Se-Grid) day job is Mogotest which is where he posted a tutorial on How to Accept Self-Signed SSL Certificates in Selenium. Again, just say no to self-signed certificates in test, and this problem doesn’t happen.
• Love RSpec and Se? You could try the selenium-rspec-dsl gem. Looks like its brand spankin’ new.
• I love the Faker gem when automating in Ruby/Rails. There is now a C# (3.5 SP1) port of it.
• For a client I need to look at controlling things of the browser, not in the browser. Here are some of the links I’ve collected on the subject. First, there is Selenium – Handle Dialogs which uses . And an alternate solution is Automating Windows with Autohotkey. For people on the Mac there isAutomator. But unfortunately if you are Linux then you are out of luck due to lack of standard windowing systems.
• Synchronizing when an AJAX request is finished can sometimes be a pain. Here is a solution if you are using Ajax4JSF or RichFaces
• The introduction to Pyrite pretty much says it all: We found Cucumber to be awesome, but no one was reading the features. We found Webrat to be fantastic, but way too complex for what we wanted. So, we made Pyrite – a few selenium-client methods wrapped up in a readable way.
• Frames can be a bitch. Accessing IFRAME Data with Selenium RC tries to limit the pain
• IronRuby has gone 1.0. If you are a .NET shop, stop creating your scripts in C# and start using IronRuby. As in immediately — if not sooner. (Well, you could also use IronPython, but thats not newsworthy this round.)

• Beautiful Testing – Last October my first book, Beautiful Testing, was published.
• Element 34 – I parted ways with Zerofootprint at the end of the year and have started my own Selenium consultancy / coaching / micro-isv, Element 34. I’m booked solid for the next couple months, but ping me anyways; I’m happy to chat about Se and Testing at length. In the future, Selenium postings will go to that site and this one will remain general testing.
• Se-IDE – I’m now a core team member for the Selenium project, specifically focused on Se-IDE. The main goal for Se-IDE this year is to get plugin support sufficiently robust so new features and abilities are done through plugins rather than change the core.
• Selenium Book – I started to write a book on Selenium for one of the major tech publishers, but we’ve mutually shelved the project after work scheduled conflicted with producing it. Hopefully we’ll renew it towards the end of the year.
• TASSQ – Last week I spoke at the March TASSQ dinner meeting. Slides and notes will be posted over the next couple days
• Targeting Quality – I’ll be speaking at this year’s Targeting Quality conference on April 21st about how to succeed with Selenium
• Star East – The week after Targeting Quality I’ll be at Star East for a ridiculously busy conference schedule. On the Wednesday I’ll be doing another version of my Testing Hats Art Show immediately followed by a Beautiful Testing book signing. On Thursday I’ll be part of the Test Automation table at lunch to field questions on Selenium and ‘automating checks and facilitating testing’ then later in the afternoon you can book 1-on-1 time with me as part of a meet-the-speaker program. At some point I hope to attend a session or two — or maybe just hold court in a central area somewhere. Oh. And if you haven’t booked your spot at Star East yet, I have discount codes.
• Agile 2010 – Acceptance notices went out last week and I’ll be speaking at this year’s Agile conference in Nashville in August about managing test cases in an Agile-ish manner.

In other words, learning a lot about being self-employed and being a consultant as well as speaking fairly regularly. In a perfect world I would speak somewhere once a month; May, June and July is still open.

• Kevin detailed how to hack SnapsIE to take full page or full canvas screenshots
• Speaking of Kevin, he was anointed as the new maintainer of Se-Grid. Congrats!
• Dawn announced that Selenesse .NET is go!
• Jim’s application likes to warm up before having automation applied to it and he shows how to use NUnit’s SetUpFixture to do it
• A lot of people don’t evolve their testing beyond Se-IDE and make use of the -htmlSuite option of Se-RC. If you are one of them, then how to run htmlsuites in Hudson is an important article for you.
• In the fall I did a presentation on how to succeed with web automation; the video is now online. I haven’t watched it, nor intend to, but so far I’ve had positive feedback. (Oh, and I posted the slides earlier but they are Lessig-ish so don’t worry about them too too much.)

Derek Sivers, CDBaby and MuckWork

• Only do what only you can do
• You have to do everything you can to not take people out of the questions
• But you need the right people
• People should freak out about your startup idea or you should get a new idea

Renn Vara, SNP Communications

• Just tell the truth
• Be ready for your own success
• Transparency is the direction things are going
• If you find your leader’s communication strategy in the legal, marketing or public relations departments, then it will fail
• In crisis, go to trust. Fast!
• People will forgive quickly if you admit error. They don’t want to feel like you are hedging
• But sometimes it makes sense to not communicate
• Or if there is a leak for instance, maybe you want to get even further ahead of the story. Jump out and go way beyond the leak with even more information.
• If I am not who I say I am, I am in deep trouble

Renn Vara, SNP Communications

• People pay for products, not ideas

2010 Predictions and author, developer Wally McClure

• Thou shalt not think that the mobile device is a scaled down desktop

Scientist/co-founder Mark Juras

• Build not the smallest chunk they are willing to use, but the smallest chunk they are willing to pay for
• Sometimes you have to market the idea space before you can market your product

Sramana Mitra on Positioning your Startup

• Target people with a specific problem, not a generic solution
• Don’t be a solution looking for a problem
• What unfair market advantages do you have individually / as a team? Exploit them.
• Having the right questions is important to finding the right answer

David Allen, Startups, and Getting Things Done

• There are only two types of problems: we don’t know how to do what we want and we don’t know what we want
• The secret of GTD is to figure out the next discrete actionable item

Carl Erickson, Atomic Object

You should just listen to this one start-to-finish. I know Carl and he is super smart. AO is one of the companies I would love to hang out at for awhile if I had a chance to.

• If you say you don’t have the time to test, it is ironically a sign that now is exactly the time you need to be testing
• ‘Teams of two’ is sometimes more culturally acceptable than ‘pair programming’
• Pair programming is a risk reduction strategy.
• You don’t have to ‘pair’ all the time, but solo code beside each other so conversations can still happen.
• The intersection of my ignorance and your ignorance is pretty small
• Sometimes its easier to show an ugly baby and make it prettier with feedback
• A startup is more than just an interesting idea, its a hell of a lot of execution and the people (of course)

Seth Godin on Linchpins and Startups

No bullets here other than I’m in the midst of a lengthy Seth Godin fanboy phase so you should just listen to the whole episode for yourself.

Greg Jones, Bookkeeping Express

• Outsource the things you don’t want to do

user_pref("print.printer", "Virtual Printer");
user_pref("print.always_print_silent", true);
user_pref("print.show_print_progress", false);

These preferences for curiosity sake are part of the tweaks normally used to put Firefox into ‘kiosk mode’ and there are all sorts of interesting things to be discovered once you start exploring that.

Anyways, one thing I am not yet doing is checking the actual ‘printed’ values, so the VPrinter one might not be the best in that situation but since I am using Se-RC, any Virtual Printer that produces hackable output could be used in its place.

• Look snazzy with your Se tests running automagically with Hudson propaganda-wear!
• This is from August, but I don’t think I’ve linked to it yet. It appears to be from a SF Se Meetup and features Dante Briones talking about Page Object Model for Selenium Scripting.
  
  
• Hot to use Fitnesse + SLIM + Selenium in tandem
• Selenium got accepted as a Google Summer of Code Mentoring Organization
• Aaron Evans details get past untrusted HTTPS connections with Selenium. I maintain that the simplest thing to do is just not use HTTPS at all or spend the money to get a trusted certificate.
• Se2 with Scalatest
• Se with Cold Fusion using MxUnit framework via SeleniumMx
• Selenium Simplified which is the first book out on Selenium (that I know of) is now in beta.
• If you are using Selenese tests with CI, here is a page on merging the result files
• Got NTLM? Dawn Cannan does, but explains how to handle windows authentication popups in Se-RC
• I feel like I have linked to this already, but even if I have it is worth a re-link; Sai Venkatakrishnan explains why not using a scripting language for Se tests is dumb. OK, so that isn’t his exact messaging, but I’ll take it further than he does to make a point.
• Dale Emery brings some automation theory to the table with his Four Layers in Automated Tests
• Firefinder is a plugin for Firefox which can find stuff via their CSS selector. Could be a handy thing to have if you have to run scripts against IE and don’t want to pay the XPath tax
• If you are using NAnt then you might care about [Starting and Stopping the] Selenium Server in NAnt
• And if you are using Java, then here is more of the same: How to Start Selenium Server with Java Code. (Also serves as a good example of how poorly formatted code is hard to read)
• selenium4j appears to be converting Selenese scripts to Se2 (Java). Cool, but it pains me as someone involved in Se to see efforts outside of the project to add functionality that should be part of it. Join the Se dev community! To the best of my knowledge we don’t bite.
• rquery extends selenium-webdriver by injecting jQuery into the browser, to expose the jQuery traversal API (including CSS 3 and jQuery’s custom extensions) to Ruby. Ummm, ya, what he said.
• Some more automation theory, this time on Writing Maintainable Acceptance Tests
• Convert your Selenese scripts to SimpleTest using this converter
• There is now an official Se-Grid plugin for Hudson; see blog announcement and plugin page
• Interested in how someone like the mighty Goog uses Se internally? Well, here are the Maps tests — or at least the way they were some while back.

@selenium.get_attribute "//input[@id='currency_count_total_value']@value"

And that works fine — until it is updated through Javascript. On the page the field will be updated but that snippet will always return the original value since the page hasn’t actually been updated — just the DOM.

So how do you get the updated value? Well, after an embarrassing length of time the magic is to use the get_value method.

@selenium.get_value "currency_count_total_value"

Now, in theory they should do the same darn thing. Reality is different. Yesterday evening would seem to imply that get_attribute works on the most recently updated html retrieved from the server whereas get_value works directly on the DOM.

1. Ack! Something went wrong! – Any time an assertion fails, take a capture of what is being displayed on the screen. This could save you the time of running back through scripts to get to the error point and if it is an intermittent fail you can capture those states.
2. As an aid for humans – The ability to drive different browsers is one of the great selling points of Selenium. But any tool like this is great for functionality, but really bad for layout and presentation problems. By wonderful coincidence though, humans are great at it. So why not make a script to capture each page in your application and stash it somewhere for a human to look at later?

This doesn’t mean that people have not been successful doing screenshot comparisons before. At CAST 2007 in Seattle, Harry Robinson demonstrated how Google Maps used image comparison when figuring out the driving directions algorithm. And at GTAC 2009 there was a presentation on Fighting Layout Bugs – Techniques to automatically verify the work of HTML and CSS programmers which Jeff Fry summarizes quite nicely. Here is the recording of that session.



So yes, it is possible to do automation using screenshots to determine pass/fail conditions. But for most projects they infrastructure and time to set it up is not worth the return. Instead, use them as tools to assist in figuring out what went wrong in a script or to capture information for later human analysis.

• Spidering – How spiders work, how to control their access to your site, and how to make their job easier
• Structure – There are ways to structure content to legitimately enhance its searchability without being scammy
• Redirects – How to deal with moved or removed content in such a way as to inherit prior page value
• Rich Media – Flash, images and audio all present challenges
• Types of Search – Horizontal, Vertical and Local search all have different needs

What is also important is the couple pages about ‘Grey / Black Hat’ techniques. These are the tricks that raise your search ranking for a bit, but are often frowned upon by the search engines themselves and could get your delisted. The less that reputable SEO outsourcing companies often employ these techniques so people need to know what they are and stay away.

There are a few things I don’t agree with in the book (of course). Primarily, the notion that runs through the book is that SEO should be first and foremost when planning a website. That is suits the needs of the users almost seems secondary. Being a book on SEO though from people who make their living on SEO, this bias is understandable. I would counter that if you forget the user experience though then it doesn’t matter that people found your site as they won’t use it.

‘The Art Of SEO’ is not really a read-cover-to-cover book. Instead I would recommend picking a topic (like redirects), skimming the places where it is discussed and then see if your site needs tweaking. It is not exactly a heavy read so you should be able to get maximum value from it pretty quickly — I knew 97% of the content already and went through it in 2 swimming lessons and a snowboarding lesson.

Do I recommend ‘The Art of SEO’? That depends on your prior knowledge in the area. If you have been creating content online for awhile and have picked up how to do SEO naturally then probably not. But if you are new to testing web applications or management of them, then there is a decent amount of value in the book and it would be a good addition to your bookshelf. Especially when you compare the $56.99 Canadian price tag to what so called SEO experts charge to do stuff to your website that you are more than capable of doing for yourself.