This article came from Nat Torkington’s great series of ‘Four Short Links’ on the O’Reilly Radar. Specifically from February 24, 2009‘s.

In it the article Online Community Management 101, a list of seven points to consider when building an online community are given which were from cribbed from a one-day workshop by the community managers of Flickr and MagCloud. A lot of software these days are building in ‘Web 2.0′ or ‘Social Media’ features so how you build the user base around it is suddenly within scope of a tester.

• A definition – Don’t call what you do a community. Just give people these tools and over time the people who use it will call it a community.
• Ask Why, Who and What you are building – There are a bunch of other questions, but essentially, if you cannot answer these, you shouldn’t be building what it is you are going to build
• Paperwork – Things like Privacy Policy, Acceptable Use, etc.
• Structure
  • Give people small, simple tasks
  • Give them to a large, diverse group
  • Design for selfishness
  • Aggregate the answers
• Keeping things ticking over – Reward good behaviour and be transparent
• Trolls – Identify and Stop
• Observe the ‘ask for forgiveness rule’ – Act first, then tell the boss

There was a bit of a flurry of words, or opinions and counter opinions in the podosphere recently between Joel Spolsky and Uncle Bob (Robert Martin). John Cook summarizes the back-and-forths with links to each escalation and subsequent de-escalation. I don’t listen to most of the podcasts, but the one I do listen to is StackOverflow so heard the excellent conversation when Uncle Bob was the guest recently on that podcast where it turns out they are more-or-less saying the same thing only differently (as usually happens when two smart people argue).

Here is the audio and the transcript.

The conversation started with just general rambling and a bit of discussion around ‘principles’ which in testing lingo could be called ‘best practices’.

• There is some deep thing wrong with programmers which makes them good programmers
• Dependency Magnets – a module that many other modules depend on which necessitates lower modules be tested to changes on it
• Understand where your guiding principles originated. Do they apply to your environment?
• Independent deployability is still an issue
• Controlling the deployment hairball is a Good Thing
• Not only do you want to independently deploy to your customers, but within your own organization as well
• At what point does knowing the rules make things worse?
• If you just blindly follow principles without knowing each’s why then all you end up with is a well formatted mess
• There are two types of developers: those who think about what they are doing, and those who don’t
• Developers in the second group can transition to the first

At the 36 minute mark the really good part begins. In it they talk about unit testing and coverage. Robert Martin is right up there with Kent Beck in the unit testing hierarchy.

• 100% code cover is a good goal, but not a requirement
• There is a point where there is no point trying to increase your coverage
• Uncle Bob keeps it around 90% lines of code
• If you are feeling pain while working with your code, then its a smell that something should be refactored, more tests, etc.
• Unit tests
  • describe in excruciating detail and unerring accuracy how the code they are testing works
  • lack ambiguity
  • written in a language the programmer understands
• If there are a set of unit tests that don’t exist, what you have is a couple statements of the specification, not the specification itself
• Some things are too stupid to test (getters and setters)
• If there is an if statement, write a test
• Changing resolution is a common failure mode of GUI tests
• There seems to be a good argument to not automate testing of the GUI. Automate the underlying business rules that the GUI is using
• Only test the GUI through the GUI
• But of course, you need a major separation of the front and back ends
• If you disabled the command-line on every unix programmer’s machine the level of quality of UIs would increase dramatically overnight
• Writing tests first forces you into the mindset that forces the separation of things
• TDD also allows good rules of design will be used more frequently and to a greater degree

And then they do a weekly feature where they discuss an answer found on the StackOverflow site.

• Two smells around switches
  1. Whole bunch of outgoing statements and each statement has a dependency causes the switch to become a dependency magnet
  2. Switch is replicated all over the place

I heard the following quote today

Believe nothing, no matter where you read it, or who said it, no matter if I have said it, unless it agrees with your own reason and your own common sense. – Buddha

And here is Cem Kaner’s most recent definition of what Context-driven testing is.

Context-driven testers choose their testing objectives, techniques, and deliverables (including test documentation) by looking first to the details of the specific situation, including the desires of the stakeholders who commissioned the testing. The essence of context-driven testing is project-appropriate application of skill and judgment. The Context-Driven School of testing places this approach to testing within a humanistic social and ethical framework.

Both these quotes seem to shoot down both the notion of ‘Best Practices’ and ‘Cult of the Expert’. Instead they say that a tester should use their brain and their own judgment in each situation before doing an action.

I don’t know the religious views of most people involved in the content school, but I know a couple and can safely say that all contextualists are not buddhist. If we take that as a truth, then how about the opposite? Was Buddha a contextualist?

Danese Cooper was at OSCon doing a version of a presentation that is kinda a call-to-arms for women in technology called Why Whinging Doesn’t Work. She made it more-or-less gender neutral for this event as it no doubt was massively skewed towards the male side of the spectrum.

• Whinging – complain in a repetitive, incessant way
• Stop whining, start doing
• Masks of complaints divert us from our fears
• Confirmation bias – what you believe reinforces what what you see
• Move out of your bias a little bit every day
• Complaining makes you isolated due to the feedback loop
• Center for non-violent communication
• Radiate gratitude
• Don’t focus on the problem statement — focus on the problem itself

It’s been a snowy and icy winter here in Toronto and I walk 40m each day as part of my commute so I notice lots of people trekking their way the elements. I’ve realized there are two broad categories of person on the streets and sidewalks during this time of year: those who are confident, and those who are not.

Exposed ice is slippery, and snow can hide ice which could cause you to slip. But in my very unscientific sample of people I witness, those who are in the confident group do not fall (or come close to falling) as much as those in the non-confident group. The confident people also get where they are going faster.

Let’s take this idea to testing.

If you have confidence in yourself, you will have greater chance of finding more bugs more effectively. Why is this? A confident person is not going to take tiny baby steps, instead are going to take broad strides through the application. Greater distance will also be covered with each step.

Confidence is unfortunately a finicky thing. It is hard to get, and easy to lose.

I would guess that the people timidly making their way through the ice and snow have either been hurt or are prone to being hurt in the case of a fall. They might have been confident at some point, but something happened, and they haven’t get it back. And may never.

Part of a team lead’s role should be to spot who on their team is starting to be afraid of slipping and help them get their confidence back. And if you don’t have a lead which is going to help you it is up to you to recognize that you have lost it and do everything possible to get it back.

You will miss bugs in your software. Its a fact of life in testing. And in most cases, the consequences are not too bad. But even if they are, create your checklists, have them double checked, learn about new defect vectors, etc.

The most important thing to remember about ice and missing bugs though is that even if you do fall:

• You learned something — the location of slippery ice or a whole in your bug strategy
• You can stand back up and keep going. You might be bruised, but we heal

The last two posts had one thing in common (aside from the host) and that is they mention empathy as a key indicator of success. That might not really be noteworthy, but last week James Bach tweeted:

The whole point of testers is that they think like testers, and not like anyone else. But for collaboration, empathy matters.

Lets look at the wikipedia definition of empathy

1. the intellectual identification of the thoughts, feelings, or state of another person
2. capacity to understand another person’s point of view or the result of such understanding

The second definition is the one that really matters I think in testing. Especially when interacting with other team members which is a critical success factor in Agile (and pretty much every other methodology as well).

So I guess I need to be less like Dexter (minus the serial killing) and find some empathy somewhere.

Anyone have some I could borrow?

Darrel Rhea is the CEO Cheskin Added Value which apparently guides innovation
through the understanding of people, culture and change.. Whatever that means. I haven’t quite figured out what he was pushing, but he was on TechNation the other week in theory to talk about ‘Marketing During an Economic Meltdown’ but they went off into innovation and systems thinking. I was hoping for the marketing stuff, but the other wasn’t bad either.

• Now is the most important time to be innovative
• Businesses that thrive coming out of the recession
  • Produce more value
  • Connect and are more relevant to their customers
• Instead of doing two initiatives, pick one or two and do them really well
• Innovation trend over the last 10 years has been people or customer centric rather than tech
• Embed customer empathy into corporate products and services
• Make sure your metrics and rewards system rewards the customer too
• Ideation – generating, developing and communicating ideas
• Corporations exist to create value for their customers
• How deep and authentic are your corporate values?
• And how embedded are they in the fabric of the company?
• Are you walking the walk, or talking the talk?
• Perform a Design Intervention – apply a systems approach to problem solving
• Look at what is meaningful for consumers as the basis of innovation
• Use a systems approach with the basis being human beings
• Go outside of how you might normally define problems
• Embrace complexity
• What are the principles of success based upon what we know about people?

Zachary Shore (a historian by trade) is on the circuit to promote his book Blunder: Why Smart People Make Dumb Mistakes so was on Tech Nation.

• Mistake – a simple error (such as missing information)
• Blunder – a solution to a problem that makes things worse than they were before
• Cognition Trap – rigid ways of approaching and solving problems
  • Exposure Anxiety – The Fear of Being Seen as Weak
    • People in positions of power who have exposure anxiety so reinforce failure rather than work towards success
    • Men with exposure anxiety portray extremely confidence
    • Women show their exposure anxiety as being cool and quiet or with greater toughness than the men around them
  • Causefusion – Confusing the Causes of Complex Events
  • Flatview – Seeing the World in One Dimension
  • Cure-allism – Believing That One Size Really Fits All
  • Infomania – The Obsessive Relationship to Information
    • Infomisers hold onto information
    • Infovoiders refuse information contrary to their belief or from sources they don’t like
  • Mirror Imaging – Thinking the Other Side Thinks Like Us
  • Static Cling – Refusal to Accept a Changing World
• Historians work from the end and go backwards; social science has an idea and move forward
• People fall into cognition traps by lacking two attributes
  • Empathy
  • Imagination
• ‘Control’ is part of the scientific process — think ‘oracle’ in the testing world
• A cognition trap checklist could be useful pinned up in one’s workspace
• Openness to information is critical
• The quality of the information is irrelevant. It is the relevance of the quantity of information that counts

Another common thing I have seen in the forums and came up last week in the irc channel was about creating test suites to execute. This is actually two completely different questions which gets asked in the same manner.

A) What is the format for html test suites? – For a long time you had to dig for sample code in the forums or blog search to find the syntax for a Selenese (html table based) test suite. There was instructions on how to run them, but not create. I posted the format in the forums last week, if for no other reason that I know where to find it in the future. There is a big documentation effort going on about Selenium right now so hopefully that will address it in the future.

B) How do dynamically create a test suite? – This is a much cooler problem to have and one I’ve solved in a couple places so far. Pretty much all the RC binding languages’ testing frameworks have the the ability to access the underlying test suite creation and manipulation methods. For example: Python, Java (JUnit) and Java (TestNG). If you insist on using Selenese style suites (and if you find yourself in this situation that is almost guaranteed to be the wrong approach) you can just use your calling language’s XML library to build the suite on the fly. Regardless of the language, I’ve found that if you save your tests in the manner described here with the path structure embedded in the filename makes your life is easier.

One thing that I see in Selenium blog posts, the irc channel, etc. is the overuse of the browser to do stuff. Yes, the whole point of Selenium is to drive a browser, and it does it quite well. But that doesn’t mean you must, or even should, use the browser for everything.

Take for instance checking whether a page is available. If you are testing the page flow from a particular page to the next page you should use the browser (as there likely is some action for whether the page is available or not). But if you are checking for something outside the flow you are testing, use something else. For example, python’s urllib.request module.

Same thing for database access. I seem to recall seeing an extension someone wrote which would let you contact the database through the browser (okay, through the Selenese — but it runs in the browser). If you need database access from your test, you should be using Remote Control which then gives you full access to the binding language’s database code. Use that instead.

My rule of thumb is this: If something in a Selenium script can be done outside of the browser, it should not be done in the browser.