It was great to make this presentation to the Utah QA User Group! Thanks to everyone who was there.
Here are the slides in PDF:
http://www.softwaretestingtrainingonline.com/cc/public_pdf/How%20to%20Be%20a%20Testing%20Rock%20Star2.pdf
Here is the recorded session:
https://www.fuzemeeting.com/replay_meeting/4402ce5c/2379285
Enjoy!
Randy
Friday, May 25, 2012
Friday, May 04, 2012
Software Defects of the Week
This has been one of crazy weeks, but I have to write about these two incidents. I'm one of those people who, like a bug collector, love to study these problems to learn from them for future prevention.
The first one happened right here in my home city of Oklahoma City. We have this awesome NBA team, The Thunder, that is in the playoffs.
When the tickets went on sale online, some people in Oklahoma City were not allowed to buy a ticket. They received an error message to the effect they didn't live in Oklahoma, Kansas or Arkansas. OK....Turns out, there is a business rule that said priority for tickets go to people who live in the area. Fine. But, these people live in OKC. What happened was that the front office used a file from the U.S. Postal Service to validate the zip codes from customers. I mean, who better to know which zip codes are valid, right? However, there were a few zip codes missing.
This brings up an interesting and common testing problem. How does one find such a defect? In this case, it's a conundrum.
You could say, use equivalence partitioning and test each zip code as a class. But, how do you identify all the zip codes? Especially, if the postal service info is incomplete to begin with! Plus, that would take a long time to do manually. Automation could do the job quickly, but you need a secondary source to compare the correct codes.
My solution would be to either 1) do an automated test using the known customer zip codes (like from a mailing list), or 2) do a manual test that samples from the customer list. This still would not assure the defect would have been found.
In the end, the team did the right thing and sold the affected people seats at a discounted price, once they learned of the problem. Now, perhaps, hopefully, this can be a test case for the future!
The second issue occurred in Auburn, California. Here's the account according to NPR:
"Traffic jams in California - well, they're nothing new. But one recent tie-up on Interstate 80 was noteworthy since it was caused by a computer glitch. The Placer County court accidentally summoned 1,200 people to jury duty on the same morning. Taking their duty seriously, residents tried to be on time at 8:00 a.m. and were in a line of traffic with other would-be jurors. The court apologized but said a real jury summons could be coming soon."
"We apologize profusely," court executive officer Geoff Brandt said of the error.
My take: I'm skeptical. Sounds like there could be some human error involved! I mean, if I input the wrong selection criteria in for the summons, I wouldn't want to take the blame either.
I doubt we will hear of the root cause, but it would be interesting to know.
Keep taking those backups!
The first one happened right here in my home city of Oklahoma City. We have this awesome NBA team, The Thunder, that is in the playoffs.
When the tickets went on sale online, some people in Oklahoma City were not allowed to buy a ticket. They received an error message to the effect they didn't live in Oklahoma, Kansas or Arkansas. OK....Turns out, there is a business rule that said priority for tickets go to people who live in the area. Fine. But, these people live in OKC. What happened was that the front office used a file from the U.S. Postal Service to validate the zip codes from customers. I mean, who better to know which zip codes are valid, right? However, there were a few zip codes missing.
This brings up an interesting and common testing problem. How does one find such a defect? In this case, it's a conundrum.
You could say, use equivalence partitioning and test each zip code as a class. But, how do you identify all the zip codes? Especially, if the postal service info is incomplete to begin with! Plus, that would take a long time to do manually. Automation could do the job quickly, but you need a secondary source to compare the correct codes.
My solution would be to either 1) do an automated test using the known customer zip codes (like from a mailing list), or 2) do a manual test that samples from the customer list. This still would not assure the defect would have been found.
In the end, the team did the right thing and sold the affected people seats at a discounted price, once they learned of the problem. Now, perhaps, hopefully, this can be a test case for the future!
The second issue occurred in Auburn, California. Here's the account according to NPR:
"Traffic jams in California - well, they're nothing new. But one recent tie-up on Interstate 80 was noteworthy since it was caused by a computer glitch. The Placer County court accidentally summoned 1,200 people to jury duty on the same morning. Taking their duty seriously, residents tried to be on time at 8:00 a.m. and were in a line of traffic with other would-be jurors. The court apologized but said a real jury summons could be coming soon."
"We apologize profusely," court executive officer Geoff Brandt said of the error.
My take: I'm skeptical. Sounds like there could be some human error involved! I mean, if I input the wrong selection criteria in for the summons, I wouldn't want to take the blame either.
I doubt we will hear of the root cause, but it would be interesting to know.
Keep taking those backups!
Subscribe to:
Posts (Atom)