Quality Assurance Practices in Katrina Relief Efforts
Test and Monitor | Posted September 26, 2005

Okay, so maybe this isn't exactly a "fun" article, but I thought this was something that, considering current events in the United States, would be appreciated amongst the QA community here at AutomatedQA.


Soon after Hurricane Katrina hit the Gulf Coast, I gave notice to my company that I needed some time off to go down and assist in the relief shelters in the Houston, TX, area.  I was able to get a week and a half off and, Labor Day weekend, I flew to Texas.


While I have a LOT of stories and observations concerning my experience, my purpose for writing this article is to give a Quality Assurance Analyst's outlook on the way that the relief shelters were run in Houston.  My personal experience comes from working at the George R. Brown Convention Center but I have second hand accounts concerning events at the Astrodome.


From what I heard, the Astrodome in Houston was an example of barely controlled chaos.  Different groups of people were not communicating so there were conflicting efforts in all areas.  One medical team from one hospital would set up one particular set of protocols at the same time as another team from another hospital would set up their own.  And so, when shift hand offs were performed from one day to the next, records were lost, mediciations were mishandled, and information got lost.  The same held trues in the areas of sanitation, sleeping arrangements, clothing distribution, housing services, job services, etc.


Meanwhile, at the George R. Brown Convention Center, everything was overseen by one organization.  For the first week of operation, Centerpoint Energy ran all operations at the shelter including scheduling of shifts of volunteers, different services offered, logistical organization of distribution of material resources, etc.  The second week these operations were handed off to Second Baptist Church of Houston.  While this second organization didn't do things the same way as the first, again, procedure and process were definitely displayed in the hand off between the two organizations.  The change over was handled smoothly with little confusion and loss of services.


The above two examples show one of the primary principles in any quality process for any industry: communication.  Without proper communication between different groups of people, the over all level of the quality of products and services offered will suffer a serious decline.  In the software development cycle, from design of a new product or feature all the way through to delivery, communication needs to be handled the whole way down the line.  If the QA team doesn't receive timely and detailed specifications of the product or feature, including user requirements, either something will be missed in the test procedures or considerable overhead for research will be accumulated by the QA team, delaying delivery dates.  If the design team doesn't receive updated technical specifications from the development team, then their expectations at delivery may be skewed from what is actually delivered.  But probably the greatest lesson learned is that of common practices.  If one team is expecting the development process to follow one path and a second team is expecting a different process path, then critical milestones will be missed or fall into extreme delay, overall reducing customer satisfaction and quality of the product.


This idea of a well formed, well communicated process was exemplified in the area where I found myself at the GRB convention center.  One of the services offered to the residents of the shelter was a laundry service where they could drop off their personal clothing items to be washed.  A local hotel offered the services of washing these items.  In order that the guests would make sure they received their items back in good order, a process was developed in which their items were placed in a mesh bag, tagged with their identification information, and then the whole bag and everything was washed together.  Sounds simple, right?


So... how does the bag get tagged?  How do we know what was dropped off by whom?  How do we know if it has come back from the laundry?  Was it picked up yet by the guest?  If so, how many bags did they pick up in comparison with what they dropped off?  When can you expect a guest's laundry back if they drop it off at x time of day?


All these questions and more needed to be known.  After all, for many of the guests, the laundry they dropped off was the entirety of their worldly possessions, everything else being destroyed in the hurricane and subsequent flooding.  In order to make sure that their items were handled and returned to them in a timely fashion, some sort of process needed to be created.  And, not only did it need to be created, it needed to be communicated, not only to the volunteers working the laundry area, but to the supervisors overseeing the whole process.  Centerpoint Energy needed to be able to hand off the process to Second Baptist.


Through trial and error, a well formed process was created with at least a 95% success rate of returning a guest's laundry.  Not only was the process created, but it was communicated both to the incoming volunteers as well as to the various supervisors who oversaw the area.  And, even beyond that, the process was a "living" process.  When a flaw was found, it was evaluated and a modification was made to improve the process.


To extrapolate this to the software QA practices, a well formed, well documented process describing a software product/feature from concept through delivery needs to be established by any software development company.  It also needs to be well communicated and understood by all parties involved.  It needs to be "owned" by all departments in that everyone accepts it as a good process to follow.  And, finally, the process needs to be "living" in that, as it is put to use, it needs to be open to modification to improve timing and correct flaws.


Of course, I could go on and evaluate QA practices in how the government agencies responded to the hurricane, in how recovery efforts are continuing to be conducted in the rebuilding of the damaged areas, in how people are being returned to their lives.  But to summarize this all, QA practices are something that are universal to all areas of life.  Observations of any process (getting the kids ready for school in the morning, performing the weekly cleaning chores in the house, filling a grocery shopping order in the supermarket, etc) will yield examples where the advantages of proper QA practices can be realized in simple daily life. 


By submitting this form, you agree to our
Terms of Use and Privacy Policy

Thanks for Subscribing

Keep an eye on your inbox for more great content.

Continue Reading

Add a little SmartBear to your life

Stay on top of your Software game with the latest developer tips, best practices and news, delivered straight to your inbox