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.
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.