All software, whether intentionally or not, is developed within some sort of model. Be it waterfall, agile, spiral, etc. Each has it’s proponents and detractors, but the common to them all is that they can be drawn out on a whiteboard to explain them. Typically I describe how software is actually built in the world at large (from my experience and speaking with others) is to draw something very waterfall-ish and then point out the places where you can inject Quality into the mix.

Where am I going with this? Well, through a discussion on the software-test mailing list I became aware of the Prince2 process model. Two things about it make it interesting from a QA perspective is

• All deliverables need testing – note how they do no limit this to ‘software deliverables’
• Nothing is complete until it is checked, reviewed and tested – again, note the ‘nothing’

Of course, things like Prince2 and CMM are just tools in the greater battle against bugs and are not suitable in all environments, but I think theyve got some of the philosophy correct. Now if only they had a diagram for the software-build process and not just the project-management process.

When Google sent me this video I thought it would be something entirely different, which isn’t to say I was dissapointed with the content, just that I had to tune out a lot of it due to the discussion of physics etc which I have no clue about. But I guess thats what you have Murray Gell-Mann as the presenter.

Two points stuck out for me though

• The challenge is often to formulate the problem, only then can you solve it – I see this often in the testing world in the context of automation, usually along the lines of ‘We just bought Tool X, now go automate the application (and save us tonnes of time)’. It’s possible though that better bang-for-buck could have been achieved through Tool Y because they didn’t know what, or more importantly why, they were automating.
• The Thinking outside the box exercise was discussed a bit, and during the discussion he mentioned that you have to ask ‘what is disallowed’. The parallel here is that the answer to that is often an explicit constraint the implementation team has to work with and that we have to test. Without such a list, you end up an infinite number of possibilities of varying degrees of likelihood, something like this list that Pradeep posted.

  Direct link here.

Rails applications are being deployed more and more these days with entire companies popping up around it due to how rapidly you can create a site. It is helpful then as testers to find out about the problems other organizations have had deploying their applications to production in order to help prevent them in your company. The whole operational risk reduction thing.

Competitious is one such company that is build around Rails. They gave a talk at a local Ruby meeting, which was held at Google so of course they taped it. Not knowing Ruby or Rails some of the stuff was just gobblygook to me, but heres the relevant stuff I got.

• Problems they encountered going to production
  • Refactoring code is difficult
  • Rails is single threaded, so processes are heavy
  • Does not support complex queries
  • Fetches all the data, all the time
  • Easy to over-query the database
• Capistrano seems to be a must-have for moving from pre-prod to prod
• By default, Rails logs all queries — including those with passwords for instance, so always filter things
• The ease of doing database queries is one of the selling points of Rails, but it also means developers might less diligent about encoding things properly leading to possible XSS or SQL Injection problems
• REST makes design simpler
• You cannot rely on 3rd party web services to be up all the time, so you have to do some tricky stuff to be up when they are not. Makes you wonder about the commercial prospects of mashups in general.
• Great coders do not use code completion

Direct link here.

When I started this blog I had the usual notions of having conversations with readers. This of course means that the reader needs to participate via comments. Then I discovered how annoying blog spam is and turned on comment moderation. Essentially, the first time you post a comment I approve you as a commenter to my blog. From that point on your comments get through without my involvement. This (plus Akismet) beats the spam thing nicely.

Normally I don’t jump on the ‘here is a link everyone else has’ bandwagon, but this post by Kathy Sierra about how she has cancelled all appearances due to threats of sexual abuse and even death has made me doubly relieved not to allow anonymous comments. Having been online for more than 15 years (with a hefty online gaming addiction for awhile), I have done more than my fair share of regailing in the anonymity of the internet. But stuff like this makes me think that it is time for the Internet to give up it’s settler’s rush mentality, accept responsibility it’s impact it can have on people’s lives and start to remove anonymity.

Perhaps I’m getting cranky as I get older, or perhaps it’s because I have seen my 14 yr old daughter post a headshot of herself online any have a dozen comments from people using pseudonyms but claiming to be in their late 30s or early 40s as ‘hot’ but I am sick of the things done online by people because they have no way of getting caught. Nearly physically ill sick.

So I’m writing something at work that is similar to Nose but specifically tailored to Selenium. I had originally been running it via Python but I think I am going to start calling it from Jython. Why?

• Can access python Selenium RC tests natively
• Can access java Selenium RC test natively
• Can access perl Selenium RC tests through PyPerl
• Can access ruby Selenium RC tests through JRuby

Could be that I am just tired, but this sniffs somewhat Holy Grail-ish as far as integrating different test scripts under a common launcher / audit and result logger.

Michael Braidy’s recently posted one of his ’5 Questions with’ columns over at his DDJ column with Robert Straavaldson. The last answer I think is the best.

DDJ: Is there anything else you would like to say?
RS: Since a very young age I’ve had the “I wonder what’ll happen if I do this?” trait. It turns out this is the type of thinking that all testers need. Being curious and devious at the same time is a good thing.

I often tell the people who I teach to be devious and it often gets a chuckle. Good to see someone else in the field using the same term.

CAST 2007 (July 9 – 11) registrations are now open. The tutorials and keynotes topics are online now, but the speaker list has not yet been released (that I can see at any rate).

I’ll be there. As if there wasn’t already enough reason to be.

One of the realities of testing is that the day before release is usually pretty stressful. All you hard work from the days/weeks/months are coming to a head and if you missed something, it’s too late (more or less). Coping with stress then is a handy thing for all testers to know how to do. I know I have a long way before I can grapple my stress, so this video, while not specifically on QA and testing, caught my eye.

Jon Kabot-Zinn works at Center for Mindfulness and talks about stress and meditation and their effects on the human body. Certainly interesting stuff in there; here are some bullets.

• Stress degrades delomeres which are needed for cell division. No cell division, no life. The direct line is that stress can kill you
• If you think you are in a stressful situation, your body will act as if it is in such a situation
• Meditation is about paying attention for the sake of awareness
• Be in the moment. A theory lifted from the Buddhists if ever there is one
• Aim to have your whole life as a meditative process
• When you are in the shower, are you actually in the shower? Or are you already at your first meeting, or finding your first bug, or making the first phone call?
• The brain is continually morphing
• The mind can positively influence the healing process

For the local readers, here is the link to the programs run in Toronto.

Direct link here.

Bram Moolenaar is the benevolent dictator of VIM so it should be not surprise that he is pretty quick negotiating his way through a text editor.

In this presentation he outlines what he thinks are 7 habits that people who are at one with their editor employ. Of course, the examples are VIM specific, but the Emacs kids will appreciate the concepts none the less.

Each habit has three phases:

1. Recognize that you are being inefficient
2. Find the solution
3. Make the solution habit

The habits are as follows

1. Moving around a file quickly
2. Don’t type something twice
3. Fix it when it is wrong – automatically if possible
4. A file seldom comes alone – negotiating multiple files in one editor instance
5. Let’s work together – participate in the community to help others be more effective
6. Text is structured
7. Sharpen the saw – you have to hone the skills you have lest they become rusty

Other tidbits that came up before the 40 minute mark at which point it became a Q&A are

• Take the time to do it right
• Don’t try to learn everything, just what you need
• Don’t read the reference guide, but do indeed read the user guide

Finally, towards the end he started to get himself sidetracked talking about ICCF Holland which is a charity is involved in. He pulled himself back on topic which I think is a shame. How a geek from Holland now working in Zurich gets involved in schooling Ugandan children likely would have made a good tale.

Direct link is here.

The kids over at HP Labs have created a project called Smart Framework for Object Groups, or SmartFrog for short. Their site describes it as “a technology for describing distributed software systems as collections of cooperating components, and then activating and managing them”. Two of the researchers on it were at last year’s London Test Automation Conference showcasing how to use their framework for distributing your testing activities across multiple machines.

This is a pretty cool concept, especially as the length of your test cycles increases. While I was at HP, my full suite would take around 10 hours to run and parts of the environment would always be idle while waiting for it’s turn to be tested. Had I been able to get my testing parallelized across the machines I could have reduced the amount of idle server investment. In today’s increasing need to increase ROI, idleness is killer. Being able to distribute testing across a network of virtual machines seems to be something akin to a holy grail of ROI.

The video of the presentation has horrible audio (like most of the LTAC ones unfortunately) so I only listened to half of it, but if you find your automated testing runs getting longer and longer or have a manager who is getting cranky about how your have all these machines but they sit idle most of the time it might be worth suffering through. They also have their slides from this presentation and others on the link above.

Direct link here.