We are surrounded by shapes and scapes that stipulate the assimilation of good design and architecture that in turn make up the desired output – based on the need and wants created by the crave of the word called ‘DEMAND’.

So are your software needs too!

A good software design is one that incorporates the latest, but proven technology. It possesses,

* a scalable structure

* facilitates easy integration with other systems, and

*is flexible to allow incorporating changes in requirements.

If the design is suited on par with an older technology, then the system might turn out obsolete within a very short time-frame!

For example, using mainframe technology on balance with other state-of-the-art technologies is not appropriate. Similarly if the design team thinks of employing some new unproven technology, then it could be a great risk that the application after development may become obsolete as soon as the new technology fails.

Businesses are always expanding, and any system deployed should also scale up to the extent that the ‘never compromising’ needs of the customer are incorporated in the application when they arise in the future.

Nowadays, there are too many legacy systems applied to fulfill business needs of different sorts within the customer’s location, as well as the core application that requires integration with the customer’s suppliers, contractors, third parties, and so on.

Ultimately, the application should easily integrate with these myriad of systems.

“Change is the essence of development” and so do requirements keep changing very often. The design you desire should be flexible enough to take care of these changes within the portal of ‘requirements’.

Murugan

eGrove Systems

Web Applications can have a lot of variables affecting them such as:

- Numerous Application Usage (Entry – Exit) Paths are possible
Due to the design and nature of the web applications it is possible that different users follow different application usage paths.

For example in an online banking application a user may directly go to “Bill Pay” page and other users may check account balances, view previous transactions and then “Pay the Bills”.
Generally a large number of usage paths are possible and all are supposed to work well.
All these Permutations and Combinations need to be tested thoroughly

- People with varying backgrounds & technical skills may use the application
Not all applications are self explanatory to all people. People have varying backgrounds and may find the application hard to use. For instance a Business Intelligence application with “Drill-Down-Reports” may work out for certain users but not for others.

Although this affects the design of the applications, but these factors should be tested in usability testing of the applications

- Intranet versus Internet based Applications
Intranet based applications generally cater to a controlled audience. The developers and architects can make accurate assumptions about the people accessing the apps and the hardware/software/technical specifications of the client machines.

While it may be difficult to make similar assumptions for Internet Based Applications
Also the intranet users can generally access the app from ‘trusted’ sources whereas for internet applications the users may need to be authenticated and the security measures may have to be much more stringent.

Test Cases need to be designed to test the various scenarios and risks involved.

- The end users may use different types of browsers to access the app
Typically for Internet based applications users may have different Browsers when accessing the apps. This aspect also needs to be tested. If we test the app only on IE then we cannot ensure if works well on Netscape or Fire-Fox. Because these browsers may not only render pages differently but also have varying levels of support for client side scripting languages such as java-script.

- Even on similar browsers application may be rendered differently based on the Screen resolution/Hardware/Software Configuration

- Network speeds:
Slow Network speeds may cause the various components of a Webpage to be downloaded with a time lag. This may cause errors to be thrown up.

The testing process needs to consider this as important factor specially for Internet based Applications

- ADA ( Americans with Disabilities Act)
It may be required that the applications be compliant with ADA. Due certain disabilities, some of the users may have difficulty in accessing the Web Applications unless the applications are ADA compliant. The Application may need to be tested for compliance and usability

- Other Regulatory Compliance/Standards:
Depending on the nature of the application and sensitivity of the data captured the applications may have to be tested for relevant Compliance Standards. This is more crucial for Web Based Applications because of their possible exposure to a wide audience.

- Firewalls:
As mentioned earlier Applications may behave differently across firewalls. Applications may have certain web services or may operate on different ports that may have been blocked. So the apps need to be tested for these aspects as well.

- Security Aspects:
If the Application captures certain personal or sensitive information, it may be crucial to test the security strength of the application. Sufficient care need to be taken that the security of the data is not compromised.

Murugan
eGrove Systems



Testing web applications is different because of many factors scenarios affecting the performance and user experience.
Web applications can typically cater to a large and a diverse audience. Web Applications can also be exposed to wide range of security threats. Web applications may open up illegal points of entry to the databases and other systems holding sensitive information.

To ensure that the web application works reliably and correctly under different situations these factors need to be accounted for and tested.

Hence a lot of effort needs to put in for Test Planning and Test Design.
Test Cases should be written covering the different scenarios not only of functional usage but also technical considerations such as Network speeds, Screen Resolution, etc.

For example an application may work fine on Broad Band internet users but may perform miserably for users with dial up internet connections.
Web Applications are known to give errors on slow networks, whereas they perform well on high speed connections.
Web pages don’t render correctly for certain situations but work okay with others.

Images may take longer to download for slower networks and the end user perception of the application may not be good.

A software bug may be defined as a coding error that causes an unexpected defect, fault, flaw,
or imperfection in a computer program. In other words, if a program does not perform as
intended, it is most likely a bug.
There are bugs in software due to unclear or constantly changing requirements, software
complexity, programming errors, timelines, errors in bug tracking, communication gap,
documentation errors, deviation from standards etc.

• Unclear software requirements are due to miscommunication as to what the software should

or shouldn’t do. In many occasions, the customer may not be completely clear as to how the
product should ultimately function. This is especially true when the software is a developed for
a completely new product. Such cases usually lead to a lot of misinterpretations from any or
both sides.

• Constantly changing software requirements cause a lot of confusion and pressure both on the

development and testing teams. Often, a new feature added or existing feature removed can
be linked to the other modules or components in the software. Overlooking such issues causes
bugs.

• Also, fixing a bug in one part/component of the software might arise another in a different or

same component. Lack of foresight in anticipating such issues can cause serious problems and
increase in bug count. This is one of the major issues because of which bugs occur since
developers are very often subject to pressure related to timelines; frequently changing
requirements, increase in the number of bugs etc.

• Designing and re-designing, UI interfaces, integration of modules, database management all

these add to the complexity of the software and the system as a whole.

• Fundamental problems with software design and architecture can cause problems in

programming. Developed software is prone to error as programmers can make mistakes too.
As a tester you can check for, data reference/declaration errors, control flow errors, parameter
errors, input/output errors etc.

• Rescheduling of resources, re-doing or discarding already completed work, changes in

hardware/software requirements can affect the software too. Assigning a new developer to the
project in midway can cause bugs. This is possible if proper coding standards have not been
followed, improper code documentation, ineffective knowledge transfer etc. Discarding a
portion of the existing code might just leave its trail behind in other parts of the software;
overlooking or not eliminating such code can cause bugs. Serious bugs can especially occur
with larger projects, as it gets tougher to identify the problem area.

• Programmers usually tend to rush as the deadline approaches closer. This is the time when

most of the bugs occur. It is possible that you will be able to spot bugs of all types and
severity.

• Complexity in keeping track of all the bugs can again cause bugs by itself. This gets harder

when a bug has a very complex life cycle i.e. when the number of times it has been closed, reopened,
not accepted, ignored etc goes on increasing.

Murugan
eGrove Systems

Quality can briefly be defined as a degree of excellence. High quality software usually

conforms to the user requirements. A customers idea of quality may cover a breadth of

features – conformance to specifications, good performance on platform(s)/configurations,

completely meets operational requirements (even if not specified!), compatibility to all the

end-user equipment, no negative impact on existing end-user base at introduction time.

Quality software saves good amount of time and money. Because software will have fewer

defects, this saves time during testing and maintenance phases. Greater reliability contributes

to an immeasurable increase in customer satisfaction as well as lower maintenance costs.

Because maintenance represents a large portion of all software costs, the overall cost of the

project will most likely be lower than similar projects.

Following are two cases that demonstrate the importance of software quality:

Ariane 5 crash June 4, 1996- Maiden flight of the European Ariane 5 launcher crashed about

40 seconds after takeoff

- Loss was about half a billion dollars

- Explosion was the result of a software error

- Uncaught exception due to floating-point error: conversion from a 64-bit integer to a 16-bit

signed integer applied to a larger than expected number

- Module was re-used without proper testing from Ariane 4

- Error was not supposed to happen with Ariane 4

- No exception handler

Mars Climate Orbiter – September 23, 1999 – Mars Climate Orbiter, disappeared as it began to

orbit Mars.

- Cost about $US 125-million

- Failure due to error in a transfer of information between a team in Colorado and a team in

California

- One team used English units (e.g., inches, feet and pounds) while the other used metric

units for a key spacecraft operation.

Murugan

eGrove Systems