Introduction
The success and failure of a project is heavily based on the fault tolerance mechanism it applied. In this article we will focus on the introduction of those different agents, which combines to become failures of an enterprise application.
It is beyond the scope of this article to cover all possibilities, however I will try to put together the most common aspects. If you are new to Managing Projects or SQA, this introduction will help you to understand the following:
- What is a failure.
- How a fault induct in the application.
- Faults in an enterprise application.
- Faults by Data Errors.
- Replication Role in Data Errors.
- Faults by Network or Configurations.
What is a Failure
According to a standard definition, a failure is a guarantee that a fault has occurred.
Fault tolerance is the capability to prevent failures even when some of the system component fails to perform its functions.
Failure will not happen if there is no fault, an entire application cannot be faultless. However, listing down all of the possible faults and handling them piece by piece can reduce a good number of failures.
It is too difficult to predict the failures. A small potential defect in the way a programmer code can cause the underlying component to fail to perform. However there is never guarantee when this failure happens.
The problem is that, the client will not pay for your fixes if some component breaks after the delivery. This means that all the work you will do to fix the fault will not be billable.
Testing is the likely solution. It is the combination of domain expert, SQA manager and the Project manager who will decide what to test.
How a fault induct into the application
There are many possible reasons of this:
- Finishing of a use cases in a tight delivery schedule while new user requirements creeping in with new relationships and dependencies may cause the team loose focus on the quality of the code.
- The team members ignore the company development guidelines of quality assurance or it is not forced for them to follow.
- Inexperienced team members implementing some programming logic while not considering the design impact.
- Implementation of a wrong application design with lots of hard code patches to fix the design errors.
Or maybe some other reasons I missed here but the faults started sleeping in the code, waiting for their wake up calls.
Quality Assurance Manager and Project Manager both are different roles and jobs. It is a common mistake to expect the QA properties in a Project Manager. However you should expect the worse.
Faults in Enterprise Applications
Unfortunately, enterprise application architecture provides many doors for a possible fault to penetrate. The entire engine requires thorough testing with maximum possible cases to reveal any bugs. We will start the discussion with the following:
- Faults by data errors.
- Faults by network or configurations.
Faults by Data Errors
In an enterprise application, data is moving from the presentation layer to business logic layer, then to database or vice versa. Presentation layer is responsible for soft validating of the data before the data moves to business component. The business rules validation is in the business layer, this check is usually the validity of business rules data, before the persistence logic is executed. If you apply this practice, then it does not matter if the presentation layer is a web, win32, mobile or some other interface. If any of the above combination did not qualify all required checks, then a single wrong value can cause the failure.
A fault can also come if some of the old testing data is not being removed and is referenced by current application and the data was not correct.
The data errors can propagate and can produce other unrelated faults or failures. They are most difficult to be detected by the testers. Only the expert business user can detect them.
Always careful about the validity, calculations and formula logic of business data; consult with business user often for the validity and verification of the data.
Replication Role in Data Errors
If the application data is distributed and replicated across different locations, make sure that the validation checks for data is being implemented before the data is persisted from any place.
If you replicate data through application, then make sure that the replication component in one location uses the same business layer component of the other location. Same like the presentation.
Faults by Network or Configurations
During the business logic execution, sometimes your code refers to a resource like exchange server, mail server or to some other URL resource. There is no 100% up time guarantee of any network resources. The code snippet, which is referencing the resource eventually, will fail; which results in breaking the entire following code.
It is being observed in general programming practices that when an object is to be created with a not valid URL resource, the object fails to be created, therefore referencing null value that will eventually break the code.
Most of the enterprise applications get their resource paths and parameter details from the configuration files. During the long period of application execution the network paths changes often, domain changes, User Id expires, IP address changes and several others. Always coordinate with your network administrator for these kinds of changes.
Always specify the specific error messages in response of particular resource failure. This will help to debug the problem.
Summary
Create a list of possible faults of the system while considering the business logic, network resources and database. Provide this list to the testing team. The testers cannot independently test the system without knowing the constraints of the application.
