Roman QC

Reading through Beautiful Teams ( review coming soon ), one of the contributors had a story about engineers building arches and how in ancient times the builder stood underneath the arch as the support was removed.

Trying to find more on this, I found a quote that seemed to be quite well known

"The ancient Romans had a tradition: whenever one of their engineers constructed an arch, as the capstone was hoisted into place, the engineer assumed accountability for his work in the most profound way possible: he stood under the arch.”
- Michael Armstrong of AT&T

I also found that I'm in esteemed company at using this quote in a blog as even Grady Booch has used it...

My searches for more background also turned up the Code of Hammurabi from 1700 BC

Law 229: If a builder has built a house for a man, and has not made his work sound, and the house he built has fallen, and caused the death of its owner, that builder shall be put to death.

Law 232: If he has caused the loss of goods, he shall render back whatever he has destroyed. Moreover, because he did not make sound the house he built, and it fell, at his own cost he shall rebuild the house that fell.

Law 235: If a boatman has built a boat for a man, and has not made his work sound, and in that same year that boat is sent on a voyage and suffers damage, the boatman shall rebuild that boat, and, at his own expense, shall make it strong, or shall give a strong boat to the owner.

I'm sure QA Hates You would still like these laws to apply...

Review - Selenium Simplified

A few months ago I thought it was time to learn more about Selenium and as I was a subscriber to the Evil Testers blog I noticed he had an ebook out – Selenium Simplified.

I paid and signed up, got my copy and had a quick read through but was too busy to look into it in any great detail. Then along comes Xmas and the best present from Santa – time to catch up on a lot of things that were on the back burner and first on the list was working through Selenium Simplified.

The book has 38 chapters and took me around 7 days ( full days ) to get through.
It’s written in a very informative, friendly style, full of tips and information.

Starts off easily with loading your machine up with the necessary bits – Java, Junit, Eclipse ( the book is very java centric ) and of course Selenium IDE and RC and guides you through starting off with Selenium – using the IDE and then running Selenium RC

Which is where I ran into my first problem

“Selenium is already running on port 4444. Or some other service is.”

A quick Google and I found an answer and learned how to use netstat

With that problem solved it was onwards and upwards and with the not evil at at all Evil Tester guiding me I was soon writing my own tests in Eclipse. Having written some basic tests the guide then took you through refactoring the code – not something I’d ever done in my programming days so that gave me a real sense of satisfaction.

This was something I really liked about the book – started off with simple tasks, guided you through them very well and then took you onto the next steps and gave you a sense of achievement and confidence.

The guide also gives you useful minor tips – in all my years of programming I never knew that you could give the Command window a title. A small tip but a very useful one when you have several windows open

The book also does not stick to Selenium but also gives a guide to the basics of Junit, refactoring ( as mentioned above ), Xpath and Css theory etc etc

Basic tests written and refactored, Xpath and Css and HTML forms and Javascript tried out the next step was to use Ant and Hudson. Having read about Ant but never used it in anger it was yet another useful exercise to see and understand how this works.

Just this would have been a good introduction to Selenium but the guide then goes on and takes you through setting up a Selenium Manager Class, using Page Objects, Data Driven tests, running the tests on multiple browsers, cookies and Ajax.

The book comes with source code which is useful when you’ve got carried away and think you know it all and find you have a null pointer exception ! This incidentally was another good learning exercise – a reminder of how easy it is to introduce defects

The penultimate chapter works through all the previous learnings and shows what a ‘production ready’ version would look like. Not only is this chapter useful in itself but it really brings home how much you’ve learnt by the time you reach this part.

Indeed, by this point I had a laptop with a lot of new tools to play with, confidence in having learned and achieved something and found that although it had been an intensive time it was enjoyable. So I looked at the recommended reading section of the book and ordered myself Agile Java…

In summary I found the book to be really useful, and nicely paced.
Recommended

High Quality Defect - Do Not Fix

Jon Bach recently blogged about his experiences with High School students and how he used the infamous bug in Notepad to get their attention

If you type "this app can break" save and close the file, then reopen it, it comes back as rectangles.

"Where's my data?" I demanded, role playing an irate user.


He could also have typed in "Bush hid the facts" or any number of phrases

The defect goes back a long way - Jon mentions it in a 2007 newsletter, Shrini Kulkarni was so impressed when he read an interview where Jon mentioned in that he had to write a blog post on it - and here I am doing the same.

Not just testers that know about it - even bodybuilders were talking about it.

If you haven't heard of this defect then here is one of the many sites that explains it

Now if we were to take the famous Weinberg quote - "Quality is value to some person" then this is a high quality defect ! It provides training material, opportunities for the MS bashers to vent and something for bodybuilders to talk about after they finished their iron pumping.

Has it become a feature and not a bug ?

Use the source, Luke

Raise your quality standards as high as you can live with, avoid wasting your time on routine problems, and always try to work as closely as possible at the boundary of your abilities. Do this, because it is the only way of discovering how that boundary should be moved forward.
- Edsger Dijkstra

Found the quote above in this article about Malcolm Gladwell and the 10,000 hour rule.

Also came across the 'lots of learning' required in the blog post Agile Programming: Lesson One (Part One) by Patrick Wilson Welsh

The Bad News: Lots of Learning
Agile Programming with object-oriented programming languages takes a good long while to learn to do “well enough.” You must master the technical practices, principles, and patterns involved, in the context of “breakable toy” codebases, and then in real enterprise codebases. Even if you are an experienced programmer, expect it to take thousands of hours to master Agile Programming well enough that you can be reliably productive on a mature, healthy agile team in the real world

I've covered this topic before but revisited it after a Xmas break learning some Cucumber ( see last post ). The Secret Ninja Cucumber Scrolls came complete with source code so it was easy to look and learn and see how things were done.

Is it easier to learn coding than testing ? Get yourself some computer theory books and then go off and put it into practice: write your TDD tests, write the code, run and rewrite the code until all tests pass, refactor and voila, done.
Then go off and find some source code and find how the experts ( with their 10,000 hours of practice ) do it. Easy
( gross oversimplification I know )

Want to see a web server written in Postscript ? Here's the source code

Cool javascript apps written in 1k - large selection here all with source code and comments.

Want your code reviewed ? Go here

etc etc etc

So what's available for a tester ?
Having read the theory books ( or maybe not, most testers haven't read a testing book ) then how to practice it ?

For example you can be pro-active in your learning, subscribe to some testing blogs, read the series of posts from IM Testy on Combinatorial Testing and think it's great - but if you want to go and off and practice it to see if you really understood it ?

Even Harry Potter knows that theory isn't enough

Dolores Umbridge:
It is the view of the Ministry that a theoretical knowledge will be sufficient to get you through your examinations, which after all, is what school is all about.

Harry Potter:
And how is theory supposed to prepare us for what's out there?

Matt Heusser posts the occasional testing challenge

The Weekend - and Weeknight - testing sessions are getting more popular and those that take part seem to get a lot from them

Markus Gartner is blazing the way - his latest blog post is on testing challenges and he's set up a Testing Dojos site and it will be interesting to see how this takes off.

( I've volunteered to help out and I'm sure Markus would appreciate more input )


A recent interview with Michael Bolton indicates that just studying 'testing' is not enough

Study testing, but note that the great ideas are likely to come from outside the field—at least the narrow vision of the field that the process enthusiasts and “certificationists” present. Testing is a marvelously interdisciplinary craft. One implication is that whatever you bring to the table from your life and your experience and your education can inform new ideas about testing

I've started a discussion on the STC site about what you would practice if you spent 2 hours a week for a year - how would you spend 100 hours a year on ? Feel free to comment there or on this blog