A classic example of skimping on test
Some bright spark in the marketing department thought it would be a good idea if you could force owning accounts to pay if a child account did not.
So Imagine this scenario
- Dad has the owning account
- Dad has 3 children and a wife as sub accounts all happily using their mobiles
- One of his children does not pay the bill
- The whole account gets barred thus bringing t dads attention that one of the child sub accounts has not paid the bill.
- Dad takes action, the bill is settled and all the accounts are unbarred.
So that was the basic development brief and in principle a good idea had it been tested. In order to “Save” money the project team decided to develop it and put it into production without going through test. A bad mistake always but especially so in this case.
So what happened. Essentially one of the largest companies in the country in question got all their accounts barred because some of the sub child accounts had not paid the bill. This included the CEO of said company who was not best pleased about this as you can imagine. Several phone calls later and of course a few sackings from the project team involved the change was pulled out of production and re written and of course tested before being deployed again.
The moral of this story is that when dealing with software and especially customer facing software part of your development lifecycle MUST involve testing and not doing this is of course at your peril