Oof. Just, like, wow, man.
Sorry. I don’t get a chance to talk about the theory and practice of QA very often, so when an opportunity like this comes along, it’s a bit overwhelming.
According to the Transbay Joint Powers Authority, four different groups of inspectors missed the construction goof that caused the Transbay Terminal closure. Four!
Granted, my QA background is in software, but I can’t imagine that construction is greatly different, at least in terms of the methodology. The basic idea is that QA sits down with the specifications–ideally, QA is involved in the process of creating the plans, helping to root out ambiguities and spot danger points early, but I’m trying to keep this simple–and produces a plan.
The plan describes what QA will test and how they’ll test it. The level of detail varies, but the intent is that it covers all the different types of tests in language that non-QA people can understand. QA then designs the specific tests, executes them, logs bugs (defects, places where the product doesn’t match the design), and eventually produces a final summary that describes what was actually tested, summarizes all the bugs, and documents any changes between the test plan and what was actually done.
Naturally, I’ve massively simplified this process. In the real world, many of the steps will be executed in parallel. There’s buy-in at multiple points in the process. Each test is documented: when it was run, who ran it, and what the results are.*
* In the software world, QA kills a lot of trees. I imagine it’s even worse in the physical world.
None of which explains how three separate groups–the outfit that made the beams, the company that installed them, and the general contractor who oversaw the whole process–apparently failed to confirm that the beams had been properly installed. Specifically, that holes cut in the beams had been ground down to prevent exactly the sort of cracks that developed over Fremont Street.
I have to wonder whether it was a planning failure–nobody said “Hey, we’ll test the welding access holes,” and none of the parties involved noticed the omission–or a failure to execute planned tests.
It’s worth noting that the holes in the First Street beam were cut differently, so that grinding wasn’t necessary. Why didn’t anyone notice the discrepancy? Was the change by design or error?
I’m less bothered by the failure of the fourth group involved. According to the Chron, a separate company did spot inspections. On the one hand, they specialize in QA. On the other hand, spot inspections will miss things. That’s part of the definition. They’re designed to give you a big picture; in the software world, you might do a spot check–a small fraction of your tests–to confirm whether a new module is ready for the full test. If, say, five percent of your tests (chosen to hit the areas of highest risk) show a lot of bugs, you’ll probably send the module back to development and say “try again.”
In this case, the Transbay Joint Powers Authority wanted checks to be sure the proper process was being followed. So, whether the tests were planned but not run, or never planned in the first place, it’s easy to see how the omission could have slipped through the cracks (sorry) of the spot check.
Anyone got an inside view of the TJPA? I’d love to know where the fault actually lies.