CALL WAITING….. ??? – Costly Miss Costly Fix

On Jan. 15, 1990, around 60,000 AT & T long-distance customers tried to place long-distance calls as usual — and got nothing. Behind the scenes, the company’s 4ESS long-distance switches, all 114 of them, kept rebooting in sequence. AT&T assumed it was being hacked, and for nine hours, the company and law enforcement tried to work out what was happening. In the end, AT&T uncovered the culprit: an obscure fault in its new Oracle Software.

Here’s how the switches were supposed to work: If one switch gets congested, it sends a “do not disturb” message to the next switch, which picks up its traffic. The second switch resets itself to keep from disturbing the first switch. Switch 2 checks back on Switch 1, and if it detects activity, it does another reset to reflect that Switch 1 is back online. So far, so simple.

The month before the crash, AT & T Tweaked the code to speed up the process. The trouble was, things were too fast. The first server to overload sent two messages, one of which hit the second server just as it was resetting. The second server assumed that there was a fault in its CCS7 internal logic and reset itself. It put up its own “do not disturb” sign and passed the problem on to a third switch.

The third switch also got overwhelmed and reset itself, and so the problem cascaded through the whole system. All 114 switches in the system kept resetting themselves, until engineers reduced the message load on the whole system and the wave of resets finally broke.

In the meantime, AT&T lost an estimated $60 million in long-distance charges from calls that didn’t go through. The company took a further financial hit a few weeks later when it knocked a third off its regular long-distance rates on Valentine’s Day to make amends with customers

Thanks For Reading This Blog. Know More: About Call Waiting

Pre-requisites for General Automation

Automation testing is the most preferred way to achieve our testing goals on time. But it is in turn has lots of dependencies on other parameters. We will see below some of them.

Why Test Automation?


Below are some reasons on why to go for automation:

• New releases and bug fixes in working module

So automate your testing procedure when you have lot of regression work.

• Testing web applications with multiple users simultaneously

Automate your load testing work for creating virtual users to check load capacity of your Web Application.

• Testing application where code is changing frequently

Automate your testing work when your GUI is almost frozen but you have lot of frequently functional changes.

Risks associated with Automation:


There are lots of risks associated with test automation. We need to give importance to each one of the below to reap the benefits out of automation.

• Skilled resources:

For automation you need to have resources having some programming knowledge.

“Do resources have sufficient programming knowledge for automation testing? “


If not, do they have technical capabilities or programming background that they can easily adapt to the new technologies?

• Initial cost for Automation is very high:

Automation cost is too high for initial setup i.e. cost associated to automation tool purchase, training & maintenance of test scripts are very high.

• Do not think to automate your UI if it is not fixed:

Beware before automating user interface. If user interface is changing extensively, cost associated with     script maintenance will be very high. Basic UI automation is sufficient in such cases.

• Is your application stable enough to automate?

It would be bad idea to automate testing work in early development cycle (unless it is agile environment). Script maintenance cost will be very high in such cases.

• Are you thinking of 100% automation?

You cannot 100% automate your testing work. Certainly you have areas like performance testing, regression testing, load/stress testing where you can have chance of reaching near to 100% automation. Areas like User interface, documentation, installation, compatibility and recovery where testing must be done manually.

• Do not automate tests that run once:

Identify application areas and test cases that might be running once and not included in regression.

• Will your automation suite be having long lifetime?

Every automation script suite should have enough life time that its building cost should be definitely less than that of manual execution cost.

This is bit difficult to analyze the effective cost of each automation script suite. Approximately your automation suite should be used or run at least 15 to 20 times for separate builds (General assumption. depends on specific application complexity) to have good ROI.

Conclusion:


Automation testing is the best way to accomplish most of the testing goals and effective use of resources and time. But you should be cautious before choosing the automation tool.
Be sure to have skilled staff before deciding to automate your testing work. Otherwise your tool will remain on the shelf giving you no ROI. Handing over the expensive automation tools to unskilled staff will lead to frustration.
Before purchasing the automation tools make sure that tool is a best fit to your requirements. You cannot have the tool that will 100% match with your requirements. So find out the limitations of the tool that is best match with your requirements and then use manual testing techniques to overcome those testing tool limitations. Open source tool is also a good option to start with Automation.