What are different error handling defects?

Errors are a major headache to the software programmers, developers as well as testers. They cause the whole software system or application to falter, produce unexpected results and behave abnormally. Some errors cause more harm while some cause less, some are easy to discover whereas some are hideous, some are as active and disruptive like a volcano and others are dormant. Therefore error handling becomes an important factor in deciding the success of a program.

WHAT IS MEANT BY ERROR HANDLING?
- Error handling is the way of a program to handle the errors that disturb its functioning.
- The error handling procedure should be very strong and smart.
- Error handling requires a lot decision making.
- The error handling process like other processes also is a victim of defects.

STEPS IN ERROR HANDLING PROCESS & DEFECT CAUSING FACTORS

1. The main steps involved in an Error handling process are namely detection, anticipation and resolution of the errors that occur during the execution of the software program or application.

2. Some applications even employ programs called “error handlers” developed specially for handling the errors.

3. A software system or application is said to have good error handling capabilities if it is able to recover from the errors without causing the whole program to terminate or if it is not able to handle that error, properly terminates the program without causing any data loss.

4. Such forceful termination is nothing but an error handling defect.

5. The basic factors causing the run time errors are invalid input data and adverse function parameters.

6. Lack of memory is another defect causing factor.

A Software application comprises of various small programs.These programs may conflict with each other during the run time. Similarly web applications also experience due to electrical noise and malware or undue pressure on the server.

ERROR HANDLING PROCESS
A software system or application can overcome these errors by its error handling process. But this error handling process also faces some risks from any defects in its source code. Thus we can define the error handling defects as the defects that reduce the efficiency of the error handling process.

1. On the initiation of the error handling process, the discrepancy between the expected behavior and actual behavior is identified.
2. Whenever there is some discrepancy in the behavior of the program, a defect is created.
3. The test script that was being executed at the time of encounter of the defect is tested.
4. This process is called defect creation.
5. After this, the discovered defect is verified i.e., whether or not the defect is valid.
6. A severity level is assigned to the defect.
7. This severity level indicates the impact and visibility of the defect on the program.
8. The defect can cause the core functionality to go out of order or stop working.
9. It can affect the operational environment.
10. Such defects prevent the user from accessing the features and functionalities of the software system or application.
11. Incorrect navigation links are also a defect.
12. According to the level of the severity the encountered errors can cause, they are assigned priorities.
13. This process is defect prioritization.
14. Several priority codes have been defined.
15. There are some defects that do not even allow the testing to take place.
16. Defects causing such errors are given the highest priority.
17. The defect is once again confirmed and this process is called defect confirmation.
18. After the defect confirmation the defect is analyzed, the affected code is redesigned, developed and tested again for any shortcomings.
19. This process following the defect confirmation is called defect resolution.
20. The defects after being resolved are once again reviewed by the developer and certain test scripts are run to confirm that the defect has been resolved.
21. After the verification the defect is closed.

Component Level Design - Designing Class based Components - Basic Design Principles

Component level design in object oriented approach focuses on elaboration of analysis classes and the definition and refinement of infrastructure classes.

BASIC DESIGN PRINCIPLES

There are four basic design principles that are adopted to component level design.
Open-Closed Principle
A component or module should be open for extension and closed for modification. It means that the component should be allowed to extend without the need to make any internal changes. Abstractions are created that serve as a buffer between functionality that is expected to be extended and the design class itself.

Liskov Substitution Principle(LSP)

This principle suggests that a component that uses a base class should continue to function properly if a class derived from the base class is passed to the component instead. When a derived class is created, it also conforms to the pre- and post- conditions.

Dependency Inversion Principle(DIP)

This principle depends on abstractions. It does not depend on concretions. The more a component depends on other concrete components, the more difficult it will be to extend.

Interface Segregation Principle(ISP)

This principle suggests that a specialized interface should be designed to serve each major category of clients. Operations relevant to that category of clients should be described in interface. If multiple clients require same operations, they should be specified in each of the specialized interfaces.

Release Reuse Equivalence Principle(REP)

This principle suggests that when classes and components are designed for reuse, an implicit contract is established between the developer and the people who are using it. Older versions of entity are maintained by the developer who establishes a release control system.

Common Closure Principle(CCP)

This principle suggests that classes should address the same functional or behavioral area when they are packaged as part of a design.

Common Reuse Principle(CRP)

This principle suggests that release number of the package changes when one or more classes with a package changes. All other classes or packages that rely on the package that has been changed must now update to the most recent release of the package and be tested to ensure that new release operates without incident.