xUnit Test Patterns

I picked up a copy of a new book called xUnit Test Patterns

Some of the developers I have given it to have said it was like gold to them with the help from Design Patterns

Built with a similar structure as the Design Patterns, the reference material at the front and back covers helped to fill in the gaps. The inside front cover shows the design patterns used to create xUnit fixtures and suites. At the back is something completely different - its like a Q&A of when people talk to you about why they can't put xUnit into their applications. My favorite section is "Legacy code cannot be automatically unit tested". Page 365, BAM! Often when I use this lookup, it start a discussion with a developer to begin thinking differently.

Its a nice all encompassing view of how to unit test applications. Although its not new, its nice to have it one place. I think these are one of those books that will be good 10 years from now because of the solid use of patterns over technologies. I'm not a fan of having a huge reference guide for many languages. I use pocket references mostly when I need reference material (or just look it up online). Its a very nice indispensable tool to look up all the different types of unit test structures and patterns in one easy location.

Check it out the reviews for yourself.

For quick reference, here are comments on some of the chapters:

• Chapter 2: Test Smells - I like this chapter because it explains why code smells and how to recognize where to apply tests


• Chapter 3: Goals of Test Automation


• Chapter 7: xUnit Basics - this has saved me a few times now on having to explain to developers how to integrate unit tests into legacy applications. I'm sure I'll get some more running ground on this chapter in the next few years


• Chapter 25: Database Patterns - this is something I have not got a lot of ground on. People still tell me they cannot abstract out databases. I don't believe you need to, you just should consider the contents of this chapter in order to unit test your database.

To get a copy for yourself, you can order it online or take a look at the online version for free. Again, I like free stuff, so go and educate yourself for free!

Books - Geekonomics

Here's a book you should avoid. Geekonomics: The Real Cost of Insecure Software and how it supposedly gives you the idea that software is like any other commodity out there.

I recently obtained a free copy of this book and thought "wow, I like free stuff, I might as well give it a read". Well, after a few nights of reading it, I came to the conclusion that this book was meant for those who don't develop software and for someone who only wants to understand how most of their life is ruled by how bad software works within their own lives.

My first reaction was "apparently, we don't test 'our' software enough". This wasn't the author's take, instead he was relating it directly to negative economic and business impacts (which are still true for bad software).

The analogy's used were nicely told; the one story that sticks out in my mind was about how cement/concrete was standardized. Basically, the moral of the cement standardization was that testing was rigorous and people held to that standard for testing it. However, where the author goes awry is when he says the same style of standardization should be applied to software development. I disagree with this statement because software if infinitely more complex than concrete or automobile manufacturing.

The moral of the story is that poor quality controls leads to a economic loss, which in turn hits the bottom line.

Also, don't be fooled by the title, its not that geeky. This is geeky.

A context-driven online course...

BBST Foundations Course - For all you Black Box testers out there, there's some courses available that might of interest to you. From the website:

"The Association for Software Testing is offering a series of free online courses in software testing to its members."

I would take the course, but I'm away during that first sessions. I suggest you take the opportunity to take this free course. Considering its in the lines of what Michael Bolton says about certification (and why it is a biased system of making people pay money to organizations who actually never watch you "drive the car"), this one might actually give you some suggestions and help towards being a better tester. My guess is that it will given the people who are developing/delivering the material are the experts in this field.

Since I can't take the course, I would suggest you sign up for AST (its only $50), and get yourself educated! Best deal in town!

UPDATE: I think I may have found the course-ware online (see video's), but you'll need to view it from home. I think in order to take the course, it would be like taking a driving exam... someone will watch you drive the car.

Google Apps Engine

Google has some pretty neat things. Its more than just the products, but its the archtiecture. They often are on the forefront of putting applications out there that no one else has done. Google Apps Engine is no different.

Remember my post about SOA, well this is it in a nut shell. Other people have SOA apps, but not against the computing power that Google is unleashing.

All in all, its not much different than any web hosting service, except for the fact that you have access to the whole google computer farm! Whoa! now that's a spicy meatball.

Man-o-man! - Tried signing up for the open source, but it was gone in a few minutes. After the initial signup, I read that the load on the system caused slow downs, which is probably a product of it being in a beta.

Entrepreneurs can use this app engine to build their systems without having to buy a lot of infrastructure. This frees up money for more R in the R&D.

From a testing perspective, I would definitely need to play with it to understand what they are doing. I read some of the docs to try and figure out what it does, but playing is what will tell me the most about the application.

I like free stuff...

Information is great, but when someone takes the time to put it into nice digestible chunks, I love that even more. However, when someone gives that away for nothing, well, that puts me over the top. So, I'm sharing with you what I just found...

Five more free magazines for you today:

1. One of the better magazines, even if they don't have a lot of issues out yet, is from the Association of Software Testers called Sapient testing. I like it because the articles speak directly to the context-driven tester community.
   
2. A testing magazine out of the UK, lots of good information here and regularly updated, more Agile and certification focus
   
3. Although more infrequent, the Toronto Association of Systems and Software Quality publish a nice little newsletter that has some really good information about testing from some of the major experts.
4. Software testing in general, good ideas for new people and experts in the field. Good advice as well
5. Scott Barber and regular articles about performance

That's all.

Initialisms, Abbreviation, Acronyms, Oh MY!

k.d.s. says:
are you in the CTC
k.d.s. says:
?
Marc says:
y
k.d.s. says:
are my sunglasses are in there?
Marc says:
i'll hal, jas
k.d.s. says:
?
k.d.s. says:
oh
k.d.s. says:
haha
k.d.s. says:
I get it
Marc says:
idst
Marc says:
sylth?
k.d.s. says:
I think so
k.d.s. says:
sometime yesterday
Marc says:
atoyh?
Marc says:
dyekwtm?
k.d.s. says:
enough with the arconyms. ;-)
Marc says:
(chuckle)
k.d.s. says:
hehe
Marc says:
there's a word not many people know
Marc says:
many people don't know that an acronym must be a recognizable work or else it's just an abbreviation or an initialism
Marc says:
an fact, things like RCMP and FBI aren't even abbreviations, they're initialisms
k.d.s. says:
oh
k.d.s. says:
I didn't know that
Marc says:
things you probably forgot were acronyms: radar & laser
k.d.s. says:
laser?
Marc says:
light amplification by stimulation of electron radiation or something close to that
k.d.s. says:
neat!
Marc says:
i remember diving into all this because of all the workflow names in tm.
Marc says:
if they are abbreviated in print but you say them expanded (e.g. "etc.") it's an abbreviation.
Marc says:
if the abbreviation forms a recognizable or pronounceable word, it's an acronym (NATO, UNESCO, radar)
k.d.s. says:
ohhh
k.d.s. says:
neat
Marc says:
if you say it letter by letter, it's an initialism
Marc says:
and to think, there are people out there who spend more time on this then i just did!
Marc says:
now i don't feel like i'm so lacking for a life anymore
Marc says:
it's always so good to talk to you, Ken
Marc says:
or at you.

Smoke Jumper

A friend of mine is a smoke jumper. She spends 6 months of the year up in Northern Ontario (about 15 hours drive away from here) in order to make sure the forests don't completely burn down.

I read an article recently that compared software projects in emergency situations to firefighting. While I disagree with the analogy because I have heard some of the experiences from my friend, I do like the quick synopsis of what to do if you are dropped into a critical situation.

The things advocated were:

• Determine your role
• Build trust
• Learn the territory
• Gather information
• Do your job
• Declare victory

I won't go into the details of what the article does an adequate job conveying, I'll just ask you to go read the article and see for yourself. Do you ever find yourself in these situations? Over the years, I've had my share of firefights.

I think a lot of firefights could have been avoided by paying attention to some simple and basic testing methodologies. I'm a little bias, but I do believe that beyond deadlines and politics, what remains is how you finally test your product and how to repeat that test the rest of the product life cycle.

The one that started me off - the Pragamatic Programmer

Every software developer should read this book. The perspective is interesting because it comes from someone who decided to write down the lessons he learned after working for 10 years. Lots of simple advice that schools don't promote. In fact, most of the advice lends itself well to people who have worked for a few years and now want to learn how to get better at what they do.

In general, it gave me a language to speak to senior developers, project managers and managers. The book is broken down in to "tips" and how to handle many different situations. I have a copy at my desk so that I can refer to things (at least the table of contents). Its by no means a bible for software development, its a nice book to have when faced with problems that are common in the industry.

There are a series of books available and another group I would recommend is the Pragamatic Project Automation, version control and unit testing series.

The idea of this post wasn't to sell you on books, it was to expose you to the whole library of pragmatic books out there. Take a look at Amazon for reviews before you purchase since they tend to have more in-depth ideas behind each book.

From a testing perspective, this is where a dovetail occurs. If I understand how developers should think, then I should be able to communicate to them things they may forget to do. In turn, I can help implement and change the organization for the better based on some basic fundamental ideas. This book is a landing platform for me to start this conversation.

So, go find out more. Over the next few posts, my books will become more testing oriented, some more obvious than others (aka: I'll throw a few curve balls, just to see what you think).

SOA and testing resources

Have you heard of SOA? Service Oriented Architecture. What does that mean for you?

Well, considering you're reading something on blogger, there's an API behind the scenes doing heavy lifting. A lot of this can be considered part of an SOA world.

SOA can take familiar applications and put them easily on the web. Actually, taking existing applications and moving them to a SOA world is much harder, but after that is built, ingesting the outputs from an SOA system is quite easy. Why does that matter? Think of your cell phone, a lot of the interoperability comes from SOA, such as being able to check your Facebook information, update your location based on your GPS co-ordinates, etc. These are all applications built because Facebook built a front-end for people to write applications for.

SOA made it possible for me to post this without the use of the web client. Since I can create applications far more robust on the operating system side, then publish to a website, this is the simplest of SOA systems available.

Here's some articles to get you started - Getting familiar with SOA.

What you might not know is that much of the internet and specifically Web 2.0 is using SOA. Facebook, Amazon, Google, MySpace, etc. all have some sort of SOA

What does that mean to you? The world is becoming even more connected. With the Internet applications being available, anyone can get started and build your own web application. Its not as hard as it sounds. To see it, sometimes with the right plugins, you only need a good IDE and the ability to draw.

Draw? What's this about? I'll save that for another post. Also for another post, how to test an SOA application and how to break it. For some quick info on the testing side, here's some articles for you.

What's performance testing to a tester?

I think performance testing requires more than just seeing how many users can bang on the system. A lot of systems don't differentiate between performance testing and subsections of that type of testing. Yesterday I gave a quick intro to a tool that allows you to "performance" test a web application. In fact, that covers everything but storage testing.

When I'm thinking of heuristics and how to remember all of them, it helps me to use analogies. Here are some of the analogies I use regarding how performance testing should work. Feel free to comment if think I'm way off base.

• Volume Testing - Think of your body. Try drinking a glass of water. Now, drink a glass of water each hour for the rest of the day. Tomorrow, do the same thing execpt drink one glass every half and hour. Every day keep decrementing the time spent between each glass. This is what volume testing an application is like. Finding the breaking point, except if you combine this will all-pairs testing, you can get glimpses into cross-configuration testing as well.
• Stress Testing - Think of any stress you have had on your body; have you been in a car accident? Have you had someone shoot you out of a cannon? These are all stresses, whether plausabile or not, each still have the same type of result... or do they? Stress testing an application is the same and two ways of stress testing an application may not fully express all the stresses that a system can take.
• Load Testing - Have you ever studied for an exam? How about two at the same time? how about 10? As you go up, the harder it is to juggle all of the data. Some people can handle 10 exams while others may not be able to handle one. If that person who could handle 10 exams, the load test here would be to pump that up incementally until they cannot handle any more.
• "Performance" Testing - How fast can you run? I can't run that fast. Some people aren't built for speed or sometimes they have other factors that limit their speed. Same in software - sometimes millisecond response time might lead you in a certain direction, but more often than not it is because of something you didn't expect.
• Storage Testing - How much can you eat? How far back can you remember in your memory? This one is pretty self explanatory. One could say that I'm somewhat famine proof because of the result of my storage capacity. :-)

These are just a few heuristics I use when I do performance testing. Load generation and configuration management is a huge part of this too, but I'll get into those another time.

Performance testing of your web application – JMeter

Performance testing doesn’t require expensive tools to simulate thousands of users. Apache JMeter is a 100% pure Java desktop application designed to load test functional behavior and measure performance. It was originally designed for testing Web Applications but has since expanded to other test functions.

What can I do with it?

Apache JMeter may be used to test performance both on static and dynamic resources on:

• files
• Servlets
• Perl scripts
• Java Objects
• Databases and Queries
• FTP Servers and more…

It can be used to simulate a heavy load on a server, network or object to test its strength or to analyze overall performance under different load types. You can use it to make a graphical analysis of performance or to test your server/script/object behavior under heavy concurrent load.

Why would I use it?

• Start doing performance testing as part of your unit testing. You can call your JMeter test from your JUnit (or NUnit, CPPUnit, or any xUnit framework) using an Ant task
• It can be used with many programming languages, not just Java. This includes Perl, C#, C++, etc.
• With the system running jmeter-server, which takes commands from the GUI (see screenshot on right) and send requests to the target system(s), you can deploy to multiple systems simultaneously.
• Its open source and freely available!

JMeter is not a browser. As far as web-services and remote services are concerned, JMeter looks like a browser (or rather, multiple browsers); however JMeter does not perform all the actions supported by browsers. In particular, JMeter does not execute the Javascript found in HTML pages. Nor does it render the HTML pages as a browser does

Fully multithreading framework allows concurrent sampling by many threads and simultaneous sampling of different functions by separate thread groups. Thousands of threads can be simulated on multiple machines. This can all be called from your xUnit framework inline with your unit tests.

VMWare and applicances

Yet another tool that I use on a daily basis is the use of virtual machines. If you don't know what this is, basically its a complete emulator for an operating system within your current operating system. Think of it this way - you can run a complete version of Windows XP within Windows XP. This is useful when you don't want to contaminate your own environment with software that might be unstable, or vise versa. Another reason is that you can create a client-server environment that is completely isolated and running on a desktop without the need for multiple physical machines.

Now, this is not an out-of-the-box tool. Companies give this technology away for free to run on your own system. Microsoft Virtual PC/Server and VMWare Server are both freely available for you to try out. (At work, I run VMWare Workstation because it has a lot of the branch/snapshot features I like).

What got me jazzed a few days ago was that MS is giving free 30 day eval of Windows 2003! Very useful given the limited amount of licenses I have access to. This is an interesting development too because MS has their own competing product and they are bowing to VMWare's dominance at the moment.

What are appliances? Basically pre-built versions of OS's that have the basic configuration completed so you can run your tests. In general, this is useful because you don't spend time having to setup a whole new environment for this effort.

I have been using appliances for quite a while. I use VMWare at home to run a Linux box (well, that VM on a Mac, so... Linux on UNIX is an interesting divide too) This would be super cool - I can run windows on my mac box for free! I run VMWare Fusion on my Mac at home.

So, why I am I talking about VMWare and how is this useful for testing? Basically if you're doing any type of testing, such as but not limited to:

• Regression tests
• Configuration Testing
• Compatibility / Conversion Testing
• Installability Testing
• Functionality Analysis Testing
• Cross-function analysis
• etc.

... this gives you the ability to do a whole lot of testing without having to have different physical environments available. All of this can be done virtually and with a lower setup time. A very effective tool for those in software development.

My bookshelf

This is my current bookshelf.



This picture is some of the books I'm reading now. Except for the Da Vinci Code which my wife sneaked on to my shelf, this is what I'm reading right now. Why do I read so many books at the same time?

Back in University, I spent a good part of my time reading. Most of the time the books were technical or contained information that was good for long term references. Occasionally I got to put some fiction in there, but mostly it was school related. There was a lot of concurrent reading going on and it kept me quite interested. One of the few books from school I still refer to is the design patterns book I used in 4th year.

I used to love going to a coffee shop and reading a novel, or a non-fiction book. My preferences were towards the non-fiction like biographies or technically oriented.

After leaving school, I had an allergic reaction to reading. I didn't enjoy it the same way I used to, for which I blame on having way too much non-useful reading to do. It took me some time to get back to a place were I'm reading stuff I enjoy.

So, in order to keep me interested in what I'm reading, I'll put one or two books out a night and read a bit from each. There are some that are always in constant rotation and I read a few pages from each night.

Over the next few posts, I'll be sharing with you my reading collection in relation to software development. I'll try not to bore you with details but give you the reason why you should be reading these books. These are books I think are a must have (unless I say otherwise) for anyone in software development. This isn't limited to testers, but anyone from project managers to developers.

Google Charts

Quick post today: Huge fan of google's little toys and API's. Everyone knows about Google maps and mashups, but they go a lot deeper than that. They occasionally release tools they use in-house for public consumption. One of them is called Google Charts.


Basically, you can provide a simple URL with enough data to form a chart, this in turn gives you an image to display. Charting from the URL! Amazing! I wish they would open source the backend code so we can all have a graphics library to do charting without needing the webservice.

I'm using this now to remove the need for an et.xls for Session Based Test Management scripts we use. I'll post the files up here once they are complete.

A replacement for Installshield?

I'm a developer/tester now with more of a slant towards test tools, technologies and technquies. However, I still care about how the tools we select for development impact our every day lives, mostly from a sustainability point of view.

Installshield is a necessary evil for getting software onto Windows machines. Over the years, I have my share of exposure to IS, including developer, professional and new versions of it. Each time, there was a new paradigm for developing in IS, from changes to how features, folders, file groups (whatever they are called now) to how things compile from a command line.

Yet another tool I came across called WIX which stands for "Windows Installers from XML". After downloading and taking a look, seems like a good alternative to IS and many of the proprietary systems for installing software. Ultimately, I want an MSI package that I can pull into a VS project and I don't want to learn a whole new language to do it. This is all in XML and the system is open source, so I can use it in every day life to make changes as I see fit.

This also means I can distribute my source for installing my software without having the burden of telling someone "Oh, you don't have that license for IS, sorry" or "I have no clue where my CD is anymore, so you'll need to hunt around for it". I'm getting frustrated with proprietary formats. It would be nice to see software developers who make software for developers create language agnostic systems for their applications. Some people already do this, like Selenium. These organizations can own the engine to compile, but don't create a new paradigm for your product.

This little utility look like it could be sustainable longterm since XML isn't going anywhere anytime soon and the source to compile the source is freely available. I'm a fan.

Perl IDE

I just found from a co-worker about this IDE for Perl called PerlIDE. It has some nice debugging features and the ability to look at scalars, hashes and watches on basic variables. Not sure how it would fair against a multi-threaded Perl app (this is a shout to Jarrett), but I have been using it for the past few days to debug some stuff I had worked on a few months ago. Its been great to use something a little more modern than Perl Debug.

That's all, quick post today. More to come.

Martin Fowler and CDT

Martin Fowler of Test-Driven Development and Agile Manifesto fame wrote on his blog this weekend about context-driven testing and how it relates to himself. He goes on to say that he doesn't know a similar thread regarding software developers in general and that there is an opportunity to help define this for the future.

I find it interesting that he sees this in himself at the same time I do. I'm of the TDD/Agile school and I'm learning how to become more context-driven. I believe there is a dovetail here and that in order to help define it, there needs to some thought into software development schools of thought.

My first thought on that school is more of an analogy: You can't take a C driver developer and move them into a BPEL Java Web Services environment overnight, you need some mentoring and retraining to make this transition effective. Same with testing, different schools need the same level of retrain/rethink in order to move in to other schools. I'm on my way now to the CDT world, but still bringing my TDD world with me.

Interesting post, and if you don't know who Martin Fowler is, you should find out! I love the tools his company makes and I'm constantly using them in my everyday testing world.

My two favorite work related PDF magazines...

My two favorite work related PDF magazines are out:

Methods & Tools - Spring 2008

• OpenUP
• How Quality is Assured by Evolutionary Method
• Creating an Agile environment
• Real Reuse for Requirements

Click here to view or download this issue PDF file, 1140 K

and

Software Test & Performance - April 2008 - Vol. 5, No. 4

• Fine-Tuning SOA in Search of Sweet Harmony
• Whip Those Test into Shape
• A Bug-List Rx Can Turn the Tables on Testing
• Trust, But Verify: Close-Up on Tester Objectivity
• Best Practices: Profiling: Leavin' on a Jet Plane
• Future Test: The Software Tester's Bill of Rights

Click here to view or download this issue PDF file, 6000 K

The best part, they are both free and the archives are fully accessible! They both have great information for project managers, developers and testers.

Conferences...

Well, its been a while since I posted. I was away at a conference earlier this week (Monday and Tuesday). The conference was IT360 and I wouldn't recommend it to any software development shop. Good place if you want to get your feet wet with speaking at conferences, but otherwise steer clear. They are not a conference "by developers, for developers", its more like it was done by professional conference people for anyone who will pay money.

Anyway, why did I go? I had won a "super pass", value >$1000 from a local IT organization. So, it was a very low cost event for me to attend and I thought I would learn a lot. When I got there, speakers (the ones I wanted to see) didn't show up and that almost killed a whole day. Anyway, this conference really was for people who don't work in software development and are looking for some information about topics they may not get exposed to (think government with an IT organization).

This isn't a complaint - I really appreciate going to the event, its just that I learned a few things:
- Developer conferences usually have enough people to fill in for other people if they are sick. There's enough people in the audience to recover from someone unable to show up.
- I'm only going to conferences by practitioners, for practitioners. Considering this is my second conference, its a good lesson to learn.
- Free is always good, but sometimes there are different levels of "free". :)

I'm going to a one day local conference at the end of the month. Should be pretty good and today was the last day for registration. This is a conferences by practitioners, for practitioners, so I'm pretty psyched about it!

“Quidquid latine dictum sit, altum sonatur”

My own skill set is changing lately. I used to call myself a periphery developer in relation to core developers. I used to do the installsheilds for complex applications, some GUI type programming, enterprise level build systems and test automation systems. Today, I mentor and consult on many aspect of these parts. One of the things I advocate is making code maintainable. That means, can the next person who needs to deal with the code use it well.

I had a discussion with a colleague recently and he recently inherited a "pristine enterprise application", >90% code coverage, thousands of JUnit tests, and properly written, from a tester point of view. In fact, when I had the chance to make it fall over, it was during a performance test and we simulated 40000 users hammering on this thing concurrently, and it held up to that torrent of traffic. Nicely done. Anyway, he was asked to make a quick fix for some new feature that may require a "hack". He told me in the parking lot that he was "violently opposed to any hacks because he came from a world of hacks". I was ecstatic to hear that, when someone care about the code so much to keep it testable. I think this an attitude that everyone should approach their code with.

Every time you make a hack, you make it difficult for the next person. On the karma scale, its pretty low for developers to do this. I also understand why developers do that since I am also guilty for making hacks to brand new code. I'm not perfect and the code I had to "hack", I made sure the next person knew that by commenting in giant letter "THIS IS A HACK, I'm really sorry". Sometime there are just time pressures and limitation that require it and sometimes its for the greater good.

Testers can just hack up tests too, this karma scale applies (even if the political situation negates the time for testing).

So, I know why things get hacked, but if you make it maintainable from the start, its best to defend that type of code base at all costs.

Anyway, the reason I thought about this was because of this website on how to create unmaintainable code. Basically, do the exact opposite of everything he says. :-)

“Quidquid latine dictum sit, altum sonatur” which translates to “Whatever is said in Latin sounds profound.”

Testable Passwords

Have you ever noticed when your password was rejected because it wasn't strong enough? I have found over the years that many password schemes (including most online banking) doesn't require strong passwords. Is your password strong enough?

I found a great online utility for such a check called Password Meter that verifies the strength of any given password you provide.

I tried looking under the hood to see what this client side application was doing. Basically its a quick AJAX application that does all the math on fly. Pretty neat and if you're looking for some really obfuscated code, take a look at this one (although it was easy to push it through a pretty-print/beautifier utility)

For your information, @Pa55w0Rd# is a 100%.

This is just another little tool that if you're testing your systems out, good to have a quick peak to see if your application can handle the password scrutiny.

You lost my luggage?

Over the years I have had my share of running through Heathrow Airport in London. If you have ever had to get a connecting flight through Heathrow from Canada on British Airways, you usually have to take a train between Terminal 1 and Terminal 4. In fact, I had to take the train from T1 to T4 to get on my plane through Europe and I only had 45 minutes. When I saw they were opening Terminal 5, I was somewhat enthusiastic because I thought it would help eliminate the delays and all the running around. (Personal aside: I was less enthusiastic about it because I read that it would handle 20 million more passengers per year, which from an environmental perspective is appalling).

Well, it opened up a few days ago and its reported that over 20,000 baggages were lost on the way between planes and destinations. It appears the luggage system, touted as one of the most advanced in the world, was unable to handle the load because "it could not be used to process delayed bags".

In simple terms, this means flights were canceled or delayed, and people who used to fly BA are now flying on other carriers who could accommodate their needs.

So, what does this have to do with testing? Everything. A couple of things about testing here:

• The political situation to get this terminal up and running must have been so intense that they thought this would be a temporary setback. In fact, it is but it will mean lost profits, and political attention that BA would not seek. Even the British Prime Minister was asked to comment on the situation. If I was a tester on this, I would feel it my duty to tell people the story of why their baggage is late.
  
• To the software developers - complex systems require attention to testing too. I realize that creating a system as complex as this one requires a lot of work, but testing should have been the most important factor when making design decisions. From the Times:

Sir, The teething troubles at Teminal 5 are a startling indication of the costly problems that can arise when launching complex systems that involve computers, software, machinery and people. In terms of complex software and systems it is well known that the testing phase is the most expensive part of the development of successful systems — consuming well in excess of 50 per cent of the total development costs. Part of the problem is that testing as a subject is rarely studied in universities — it is just not very fashionable — and so many graduates have no understanding of the difficulties and intellectual challenges that the testing of complex systems presents.
Professor Mike Holcombe Department of Computer Science,
University of Sheffield

• Use-case models and heuristics could have been used to anticipate and test for these conditions. The problem now exists that you need to test your software on a production system, so a word of advice, always use a scratch monkey.
  
• I am sure that the people testing this system told people and warned them of this problem. Again, a lessons learned activity from other deployments would have been useful here.
  

I realize that I'm over simplifying some of the aspects of this problem, however I'd like to point out that none of my testing errors made the six o'clock news. :-)

So, I'll take this as a lesson learned: if you plan to create a monster system, make sure that you can run regression tests extremely efficiently and abstract out the hardware where ever you can. Also, think of it from the users perspective because that will give you the best idea as to where problems will occur.

The shoe and tea test...

Really short post today -- Ever heard of the shoe test? Its a very applicable and reliable means of testing your software. Basically, you take your left shoe off (make sure its your left one) and place it on the keyboard. This test is often accompanied by the tea test, where you get up from your workstation and make a cup of tea. If you come back to your desk, take a look at the screen. Has anything changed? Did you find a problem that requires you to think about how you're replicate the problem again? Anyway, just some food for thought.

I also don't think we need to test our software anymore. Most computer system are intelligent enough to know how to fix and repair themselves. Most machines should be capable of thinking for themselves too now given the speed of the processors and how many processes each one can run. With all our automation systems we build to get the most out of exploratory testing, we should spend less hours testing and more hours just coding.

Have a great day. :-)