Complete QA

Date November 18, 2008 by Isaac

Most of the time we think about QA we think in terms of software QA.  However, there is much more to the QA realm than just software.  Let me illustrate...

A year or so ago I bought a prepaid Net 10 phone.  During this year I have had numerous support phone calls, web site issues, and billing issues.  First, the Net 10 web site does not work with Firefox, which is my browser of choice.  Since I only use Windows when necessary this causes me problems when I need to log on and recharge my phone.  Most of the time I bought phone refill cards from the store, however, the two times that I tried recharging the phone online I had to fight with customer service to get my minutes.  This defeats the reason to allow people to recharge their phones online.  The 2nd time I tried recharging my phone via the web site it failed and I was told to call customer service.  After a while on the line I finally got the answer that I needed a new SIM card.  The card arrived a week or so later and I installed it.  I then called customer service back and they were able to activate the card, however, from there it was all down hill.  When they activated the phone they changed my phone number to a Texas phone number.  I don't live in Texas.  Where did that come from?  To top that off the phone didn't even work.  I could not place calls.  After two weeks of trying to get this issue resolved with them unable to change my phone number back, or get my phone working I asked for a refund of my money.  That's the last time they talked to me.  To this day I am out $30 on my refill.

OK, stepping off my soap box.... What does this have to do with QA?  Someone tested the telephone software.  I am sure QA was performed on the customer management software that Net 10 uses, and doubtless audits have been performed on the customer support team.  Someone has surely also tested the web site.

So, if these pieces were tested separately then what exactly went wrong?  The customer management software obviously didn't give the support reps the info or power they needed to be able to fix my phone and I was never able to get routed to anyone who had the needed power.  I don't think the problem was that the management software was defective, but it did not fill the role it needed to fill.

This is one of the fundamental problems in software QA; a piece of software can meet all the requirements and it can be user friendly, but can still fall short.  This is because it did not meet the need.  In this case the software prompted them with all the normal troubleshooting tips, but didn't give the service reps the power they needed to dig into the problem and fix it.  Having said that they should have been able to transfer me to someone who could help, but they didn't.

The problems with the web site were twofold: First, it did not work across browsers.  Second, it may be functional by itself but it did not integrate well with the phone crediting system.  Integration testing is another issue that comes up a lot.  Whenever you have one system that talks to another system there is bound to be a whole swarm of bugs waiting to be discovered.

Of course I need to add the disclaimer that this post represents my opinion and my experiences and that your experiences and opinions may vary.

Comments are closed.