Posted on June 29, 2009 in Uncategorized by adamNo Comments »

In the paper this weekend was an interview with Hank Davis who is promoting his new book Caveman’s Logic: The Persistence of Primitive Thinking in a Modern World. Here are the juicy bits of the article

  • … we still happily shroud ourselves in superstition, magic and blind faith rather than burn the extra mental calories it takes to think critically and reach rational conclusions
  • We continue to default to the same magic explanations that our caveman ancestors did. (Such as ‘Thank God’, ‘Good Luck’, ‘Everything happens for a reason’)
  • he debates the relative merits of heuristics and shortcomings of the human mind
  • Patterns are everything to us. We hunger for them. We revel in them. … But a perceptual system that is so geared to wrestling patterns out of complex arrays of stimuli is bound to produce some false positives
  • Our Pleistocene ancestors need to err on the side of caution in order to keep themselves well fed and safe from predators
  • Our problem is not with the adequacy of the cognitive mechanisms we have inherited; it is with the inability to turn them off. They work all too well and too frequently.
  • Part of the problem with our brains is a “causal detection error” that leads us to wrongly believe that our behaviour has more of an effect on our environment than it actually does.
  • Asking people to retrain their brains to question their most fundamental beliefs is a tall order.

This article would likely have got a write-up on the merits of the ideas alone, but definitely gets one in light of Dave Rooney’s post last week on Reverting to Training. The crux of it is:

During my flight training, my first instructor made a point of saying early and often that it was very important to listen closely, do what she said the way she said to do it, and to practice that way afterwards. She emphasized the importance of this, saying that “when faced with an emergency, you’ll revert to your original training”

In other words, when faced with crisis we revert back to our caveman logic. Of course cavemen didn’t have complex coding, testing or deployment problems so we encode our caveman logic into our brains, and those who follow us, at a much later evolutionary state (late teens / early twenties usually) but the effect is the same. The problem of what should (and more importantly should not) become our fallback position is perhaps more important than overriding the ones we have through evolution.

Posted on June 29, 2009 in Uncategorized by adamNo Comments »

Last night I was looking for a demotivator for Death Marches, but couldn’t find one. (Quality came close but wasn’t was I was trying to capture.) For those unfamiliar with the term, wikipedia defines it as such:

In the software development and software engineering industries, a death march is a dysphemism for a project that is destined to fail. Usually it is a result of unrealistic or overly optimistic expectations in scheduling, feature scope, or both, and often includes lack of appropriate documentation, or any sort of relevant training. The knowledge of the doomed nature of the project weighs heavily on the psyche of its participants, as if they are helplessly watching the team as it marches into the sea. Often, the death march will involve desperate attempts to right the course of the project by asking team members to work especially grueling hours, weekends, or by attempting to “throw (enough) bodies at the problem” with varying results, often causing burnout.

This isn’t a bad description, but I don’t like the use of the word ‘fail’ too much. Chris McMahon put it well on twitter last night that sometimes meet their objectives which is not really a fail.

Death march survival is one of those rites of passage in the tech world along with your first brush with layoffs. One thing that I am starting to notice is that Death Marches are a lot less prevalent in organizations that actually get Agile development.

I like Elisabeth Hendrickson’s definition of Agile: Agile teams

  • Deliver a continuous stream of potentially shippable product increments
  • At a sustainable pace
  • While adapting to the changing needs and priorities of their organization

Notice the second bullet in particular; at a sustainable pace. Death Marches are the anti-sustainable pace as they sacrifice the future for the current.

And now for the promised zombie tie-in.

I’ve seen it often that those in the midst of a Death March start to exhibit zombie like pursuit of project completion (SHHHHHHHHHIIIIIIIIIPPPPPPP!!!) which can have pretty negative consequences for product Quality. But I know lots of people who have done the Death March before who are really smart which got me looking around for a zombie hierarchy. Turns out there isn’t really one as compared to Vampires; I was looking for the Lich King of zombies since zombies are at their core selfish creatures which doggedly pursue a single goal and so have no leadership. (I did find a fun page of zombie types though.) I did find a zombie type which might come close to describing this phenomenon and that is the Quisling. There seems to be some debate in the Zombie fandom world about whether this is an official Zombie type but it serves my purpose to call it such. Again, here is wikipedia‘s definition of a Quisling zombie:

In Max Brooks’ novel World War Z, “quisling” refers to a human that had broken down psychologically due to the presence of zombies and thus begun acting like a zombie. These humans attack other humans mindlessly but are still attacked by normal zombies who can tell the difference. Being bitten by a “Q” (Quisling) does not result in zombification of the victim, but nonetheless imposes sincere mental stress on the victim since he/she believes to be ultimately infected – thus, the “Q’s” are being described as a danger which must not be underestimated.

I think we might also have a new team metric: Q ratio – the number of Quislings vs. Humans. Anything greater than 0 is a team fail.

Posted on June 26, 2009 in Uncategorized by adam4 Comments »

I’ve been leaning towards the idea recently that it does not matter if you have hired rockstar testers and developers, or you are using the latest / greatest / fadish development methodology, or any other fad of the quarter. The thing that drives a product’s Quality is Culture. Specifically Company culture.

If the culture a product was born and raised in is one that

  • Cares – about the product, their fellow co-workers, the company
  • Trusts – each other and management
  • Communicates – freely and without fear of repercussion
  • is Awesome

then you have a chance of a high-quality product. Notice that nothing here has to do with the actual creation and testing of code; they are all things that need to be addressed by people in terms of their interactions with one another (and their employer).

This idea really cemented itself with me this afternoon listening to Tony Hseih’s Web 2.0 Conference talk. It is well worth a listen. But for the lazy, here is the point he makes four or five times.

If get culture right, most of the other stuff will happen naturally on its own

I would argue that Quality is most certainly of the ‘other stuff’ he mentions.

Posted on June 25, 2009 in Uncategorized by adamNo Comments »

We just finished going through the first (and major) round of reviews for Beautiful Testing. In most technical books this review is for technical accuracy and things of that nature. Because Beautiful Testing is 25 chapters on 25 different topics by 30 different people, the review was more for consistency of theme and relevance to the reader.

What was striking reading the reviews is just how good good feedback is and how bad bad feedback is.

Here is my working definition of what both these categories are:

  • Good – Provides opinion, why/how they arrived at the opinion, and in the case of negative feedback what would have changed their mind on it. Example: Rather than an overview of the history and current practice of testing at Company X, I would have gained more value from a chapter with a point, “We thought this, we tried that, we ended up deciding something else.”
  • Bad – Just an opinion. Example: Bleah. That was my only comment on this chapter.

The feedback from the person who I lifted the Good example was consistently good, and the Bad example consistently bad. Testers provide feedback all the time through their bug reports. And the ones that get addressed quicker are usually the ones from the Good bucket.

I suppose in testing terms, Good feedback includes the Observation, Oracle and Heuristics that were applied. Bad feedback has only the Observation.

So the question is, are you a provider of Good feedback or Bad feedback?

Posted on June 19, 2009 in Uncategorized by adamNo Comments »

Someone asked in #selenium this morning about what they can do to prevent their test runs form affecting the site’s analytics.

The simplest thing to do is filter out the IP(s) of your test machines from the statistics your tracker collects. We’ve done this with Google for our office gateway so none of our internal traffic can skew our stats. (That is just a good idea anyways.). The person countered that it was for a client and so that solution was not directly available. Hold on a second. If they are paying you to run scripts against their site, and the site has analytics turned on, then they should be willing to filter out your machines.

This is a prime example of what is fundamentally a communication problem but attempting to solve it with a technical solution. Solve technical problems with technical solutions; solve communication problems with a phone.

Okay, rant done.

So let’s pretend that filtering was really not possible for whatever reason. How else could you solve it?

If you had access to the application code you could set some sort of configuration setting which will determine at render whether or not the analytics should be included. In Rails, it is particularly easy. We have this in a partial

<% if ENV['RAILS_ENV'] == 'production' %>
  <script type="text/javascript">
  var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
  document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
  </script>
 
  <script type="text/javascript">
  var pageTracker = _gat._getTracker("<%= omc_google_analytics_account %>");
  pageTracker._setDomainName(".zerofootprint.net")
  pageTracker._initData();
  pageTracker._trackPageview();
  </script>
<% end %>

This way, if the server is running in any other environment other than production the analytics don’t get included.

That solution is probably also not available to you if the communication is so bad that you can’t get things filtered. No worries, there is also a solution which is completely under your control and involved hacking DNS. Well, not exactly hacking but certainly manipulation.

What you can do is modify your hosts file to map google-analytics.com to 127.0.0.1 which will prevent your Selenium spawned browsers from requesting the script which means Google never even knows about you. (I used to do a similar trick with ad servers.) One thing you have to be careful of is that this will not return a 200 response code when it tries to fetch the script unless you put ga.js on the server. But if you put it on the server you are also going to want to make sure it ‘executes’ without error but that should be pretty easy as well.

Analytics are certainly a valuable part of a page’s payload. Heck, parts of your company would likely argue that they are the most important. But they also have to have to have accurate information and getting a traffic spike because you are running a test is not something you want. The above tricks will solve it for you.

Posted on June 18, 2009 in Uncategorized by adamNo Comments »

The LA Lakers won the NBA championship earlier this week and with that Phil Jackson became the winningest coach in the NBA. They were talking about him as a coach on the radio and the following nuggets were produced. I’ve wordsmithed (most) them around so they can be applied to test leadership or coaching as well.

  • Convince your stars to be part of the solution
  • Be a great manager of ego
  • [Orlando coach Pat Riley] is old school; a motivator and a hard line guy but you play for him. Because your dad motivated you like that. Phil found out what made every guy tick and pushed that button. If it is 12 different things or 13 different things then that is what he used.
  • Finds out what makes your players go and leans on it
  • Coaching great players are harder to coach than not great
  • Use people properly
  • Here is what I need you do to. Don’t do anything else. This is what you do
  • A beautiful Mercedes has a $0.25 lug nut holding on the wheel
  • Get people not only to play a role, but accept it
  • Practices are a team’s private time
  • Most coaching is done at practice, not game time
  • Stand back and let the stars talk sometimes
Posted on June 18, 2009 in Uncategorized by adamNo Comments »

Scrum is by far the easiest Agile methodology for companies to swallow. But it comes with its own jargon and baggage. One of these is the unfortunate term ScrumMaster. In particular, the Master part.

Too often people adopt Scrum and the Master would end up as being the ‘master’ of the project in terms of ‘Master and Servant’. But that is wrong.

Wrong, wrong, wrong, wrong, wrong.

I remember hearing somewhere that the it should be thought of as a Ring Master or Master of Ceremonies. They don’t dictate, they direct and move things forward.

Brian Marick posted something last week on the idea of ScrumMasters which I think did a wonderful job of describing the problem and rephrasing the solution.

Too often these days, the ScrumMaster is thought of as the boss of the team, when in fact the roles were originally reversed: the team was the boss of the ScrumMaster. The team would say, “Behold, there is an obstacle in our path. Pray remove it, Good ScrumMaster.” And the ScrumMaster would do so.

The team bully is not the person who should be the ScrumMaster. The person who is on good terms with others in the team and the other teams you interface with is the ideal person I think for the role.

Posted on June 18, 2009 in Uncategorized by adamNo Comments »

Geoff Colvin is out pimping his new book, The Upside of the Downturn and has distilled out some Actions of True Leadership in this month’s Fortune. The theme around these actions is that the economic downturn is a ‘crisis’ that is going to be around for awhile, but they would also play out well for short-time ones as well.

  • Be seen early and often – successful leaders in a crisis first make emphatically clear that they are present and on the job
  • Act fast – every instinct tells you to decide more slowly than usual, yet it’s vital to decide more quickly
  • Show fearlessness – show fearlessness, not be fearless. You may be terrified, but it doesn’t matter
  • Tell a story that puts the crisis in context – reframe the crisis as a normal, interesting element of life from which we can learn and can respond to
Posted on June 16, 2009 in Uncategorized by adamNo Comments »

Here is an article I had open from New Scientist (which I suspect I found on Twitter, but not 100% sure) that I thought was interesting on the grounds of ‘If you understand humans better, you can test software designed for human consumption better’.

Humans prefer cockiness to expertise is a study by Don Moore where it was found that we [humans] prefer advice from a confident source, even to the point that we are willing to forgive a poor track record. This is partly because there is evidence that precision and expertise do tend to go hand in hand.

Ummm, that is interesting, but how does it relate to testing? Well, finding a bug in your software is often the easy part. Getting it through triage and in front of a developer is often the challenging part. Or how about trying to make your case for holding up a release due to a particular bug; always a fun conversation as well. If you go in with lots of ummms and ahhhs is not going you are not going to convey confidence which not only intuitively is going to hurt your case but now will scientifically. I’ve seen this played out a number of times between a non-confident QA lead and a very confident dev lead. (To his credit, I learned a lot about being a team lead from him; do the opposite.)

I also need to work this into my paper on managing your career somehow.

Posted on June 11, 2009 in Uncategorized by adamNo Comments »

I realized as I was about to check-in the Selenium stuff I had been working on for a Rails app for work (yes, I know, frequent check-ins, etc.) that there would have to be a dependency on having the server running somewhere. That’s a dependency fraught with danger so I looked at removing it.

Turns out that it is remarkably easy-ish with the selenium-client gem which I was using anyways. It comes with some rake tasks to control the server if you have the server jar tucked away in the project.

  1. Extract selenium-server.jar from the Selenium release and put it somewhere in your Rails project. I put it in vendor/selenium-remote-control. I also renamed it to selenium-server-1.0.1.jar so I can tell at a glance which version I have.
  2. At time of writing, the current version of the gem is 1.2.15 and it has a incompatibility with version 1.0.1 of Selenium RC with regards to shutting it down. To fix it, change shutDown to shutDownSeleniumServer in lib/selenium/remote-control/remote-control.rb in your local copy of the gem.
  3. In Rake and Selenium I posted my test:selenium Rake task. Well, I’ve changed it a bit so it starts the server before running the test(s) and shuts it down afterwards.

    require 'selenium/rake/tasks'
     
    namespace :test do
      task :selenium do
        Rake::Task["selenium:rc:start"].execute
        begin
          Rake::Task["selenium:rc:tests"].execute
        ensure
          Rake::Task["selenium:rc:stop"].execute
        end
      end
    end
     
    Rake::TestTask.new(:'selenium:rc:tests') do |t|
      t.libs << "test"
      t.pattern = 'test/selenium/**/*_test.rb'
      t.verbose = true
    end
    Rake::Task['selenium:rc:tests'].comment = "Run the selenium tests in test/selenium"
     
    Selenium::Rake::RemoteControlStartTask.new do |rc|
      rc.port = 4444
      rc.timeout_in_seconds = 3 * 60
      rc.background = true
      rc.wait_until_up_and_running = true
      rc.jar_file = Dir["vendor/selenium-remote-control/selenium-server*.jar"].first
      rc.additional_args << "-singleWindow"
    end
     
    Selenium::Rake::RemoteControlStopTask.new do |rc|
      rc.host = "localhost"
      rc.port = 4444
      rc.timeout_in_seconds = 3 * 60
    end

    To replicate the old, non-server-controlling behavior the task is now selenium:rc:tests.

Of course, this assumes that you are doing it all on localhost. If you wanted to get really trick you could take this idea and implement it with capistrano or vlad or even puppet.

Next Page »