Urgency vs. priority – an example and an assertion

QA Engineer:  So, manager, which is more important, A or B?
QA Manager:  Well, engineer, they’re both important…they both have to be done.
QA Engineer:  So how do I prioritize them?
QA Manager: (a little frustrated)…like I said, they both have to be done.

How many times has this scenario played out for you?  Many times for me.  So, let’s examine this problem with an example we all experience, our own need for oxygen, water and food. 

All three are essential to our survival…without any of them, we will die.  There is no way to prioritize them in order of importance.  However, they definitely can be prioritized in order of urgency. 

• Without oxygen, you would be brain-damaged within minutes (and dead soon thereafter).
• Without water, you would die within days (one website I read said the average person would be dead within 9 days of 80 degree days).
• Without food, you can go months, but eventually you would die.

So, although all are essential in the long run, oxygen is most urgent. 

Does this mean we should always focus on our most urgent needs?  No.  If you focused only on your most urgent need (oxygen), and never paid attention to less urgent but equally essential needs (food and water), you would still die, albeit more slowly. 

I think the lesson of this allegory is that we sometimes ask the wrong question.  A better question would be “which is more urgent to test, a or b?”  And if both are equally urgent, as well as equally important, then the laws of physics come into play, and you lay out how long each will take, and the amount of time you have available. 

One final note:  this principle will certainly not alleviate the “I need everything done, and I need it yesterday!” issue.  But I do think it sheds some additional light on the questions to ask when prioritizing.

Another thing to love about RSpec

I’ve been busy working on refactoring our test framework, and I ran across a gem (spoken in the usual sense, not in the RubyGem sense).   

RSpec has a method for running a block of code before and after each example, before(:each) and after(:each).  Its syntax is pretty simple:

describe “this is my feature” do

  before(:each)
    do_this_before_each_example()
  end
  after(:each)
    and_do_this_at_the_end_of_each_example()
  end
  it “should be example 1” do
  end
  it “should be example 2” do
  end

end

This is pretty standard stuff.  The cool part is you can also use a before(:all) and after(:all) method to do stuff (like major setup and teardown) once at the beginning of the describe block, and the after(:all) at the very end.  Since it can be tied to any describe block, it’s completely flexible how big a block of example it applies to.

The more I use Ruby for testing…the less reason I have for looking at other languages.

Watir and security testing of web applications

One of the tasks I have at work is security testing.  Watir makes a great tool for security testing of web apps.  There are several reasons for this:

• Many of the common security vulnerabilities related to web applications (SQL Injection, cross-site scripting, buffer overflow) have to do with simply posting different types of information to a web server via a client.  This is pretty much what Watir is all about.  It even gives you access to hidden elements, so it really is a great tool for submitting form data to a web server.
• The Ruby side of Watir, being a full-service language, has great tools for querying the database, checking audit logs and the like.  Also, you can generate random data (or large datasets) to throw at a web app, or even pull the test data from a CSV file.
• There are some things you might not be able to do through Watir, but can certainly be done with Ruby.  Again, this is perfect – because Watir is not really a test framework, it’s just a way to drive the Browser when you need to.  So, tests which are more low-level (such as web service communication or network tests) can be run through Ruby and RSpec, or whatever actual test framework you’re using.

In short, Watir makes a terrific tool in your arsenal for web security testing.

Watir Design Patterns?

I think the biggest thing a lot of us Watir developers need is a good guide to design patterns with Watir.  I know for myself, I know the commands and basic syntax pretty well, and can design a test structure that works, but I'm sure there are things I'm doing that could be designed better (I'm a tester, after all, not a full-time programmer).  I'd love a guide that describes best practices for how to set up a directory structure, set up rake for common tasks, etc.

I know WatirCraft attempts to address this to some extent, but I guess I'm suggesting that some people might need to design their own framework, but not know how to do it.

My two cents.

Axiom Wednesday

I’ve decided to start a tradition (April Fools’ Day is as good a day as any to start this, right?).  I often come across axioms in software development…short, pithy statements that attempt to express some greater truth.  Some are terrific.  Some a little less so.  Every Wednesday, I’ll explore one.

Today’s axiom is:  Read more code.   Ideally, read more code than you write.

I extracted this axiom from James Edward Gray II’s great presentation at MountainWest RubyConf 2009.  It really makes perfect sense…if you want to be a great writer, you read.  Lots.  None of us would respect a writer who didn’t read much.  Yet it’s all too common (I’m guilty too, I admit) to not really seek out code to read.  With basically all of the Ruby universe being open-source, there is a treasure-trove of interesting code to look at.

One tip James gave at the conference was to not start out by finding the hairiest, most complex code to look at.  find a module that is fairly simple and straightforward (actually, Watir is great for this), and look at the source to see how it’s put together.

Some advantages James mentions of reading code:

• It can show you common idioms
• It’s good to practice breaking down possibly challenging code, because you will always have to work with other’s code
• Understanding how something works give you insight into any limitations it has
• Seeing bad code helps you write better code
• Knowledge workers always need more ideas