System testing

A type of testing to confirm that all modules work as specified, and that the system as a whole performs adequately as per the design and the requirements on the platform on which it will be deployed.

(Note) The major difference between integration testing and system testing is that, Integration testing is carried out on independent modules as well as combination of the modules, where as system testing, all modules are combined together and tested

Specific tests that are to be performed during system testing:-

a) Installation Testing

b) Performance Testing

c) Load testing

d) Stress Testing

a) Installation Testing: -

Testing the application by full installation, partial installation, or upgrading, uninstallation of the product on the specified operating system(s) to ensure that all above activities will work fine with the application/system/product

(Note) In case of a web application apart from the installation test, check the

Browser compatibility on different versions of browsers.

Performance Testing: -

Performance Testing deals with, how fast application/system/product

Will respond to user input.

a) Specify the bench marks for the application to determine the application

    Performance

b) Best method to determine an applications performance is through a tool only

c) If no tool is used and manually we have to determine, then do like this, for example If    25 records are to be displayed for user input in 25seconds- to test this, Use a stop watch to test the performance of the application by clicking the corresponding button/link and notice the time in the stop watch .

C) Load Testing: -

Testing an application under heavy loads, to determine at what point of time the system response time degrades or fails. For example write a script Which will create 100 virtual users and pulls the data to an web application by opening 100 browses versions, wait and see the response if it Works fine or not then increase it to an extent, at certain point of time it will not respond or degrades or fails, this is the point that is the maximum load that The application can accept.

D) Stress Testing: -

This term often used interchangeably with 'load' and 'performance' testing. Also used to describe such tests as system functional testing while under unusually heavy loads, heavy repetition of certain actions or inputs, input of large numerical values, large complex queries to a database system, etc. for example write a script which will repeatedly do the same kind of action by sending different type of input data the application and see the behavior of the application

What is stub/Driver

A stub or a driver can be defied as a program or a method that simulates The activity of a missing subsystem which is suppose to provide a specific Functionality depending on the design. The basic advantage of this is, if any modules is expecting or suppose to receive data from other module and that module is not ready, by writing the stubs/driver we can provide fake data to the module and can test its functionality.

Levels of Software testing

Following are the different levels of testing

1) Unit testing

2) Integration testing

3) System testing

4) Acceptance testing

1) Unit Testing:-

Unit Testing is the first level of testing which is the first responsibility of the developers and then of the testers. It is generally seen as a "white box" test class. That is, it is based to looking at and evaluating the code as implemented, rather than evaluating performance to some set of requirements.

It has the following advantages

a) Does the code implemented what the designer intended

b) For each conditional statement, is the condition correct?

c) Do all the special cases work correctly?

d) Are error cases correctly detected?

2) Integration Testing:-

Is a testing of combined parts of an application to determine if they function together correctly? The 'parts' can be code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems.

For example if an application has 5 modules (A, B, C, D, E) first A+B modules combinded and tested then A+B+C… it goes for All of the pending module combinations. Integration testing identifies problems that occur when units are combined.

Following are the main reasons for doing integration testing

a) To find faults that could not have been found in the component testing because, they only become apparent when components are integrated

b) To generate credible information about the software under test, so that technical and business decisions can be made

c) Confirm that as the system grows risk of failures are being diminished

Types of Integration testing: -

1) Bottom up integration

2) Top down integration

3) Umbrella approach

1) Bottom up integration:-

Integrating from the last module of an application to first module of the application. Bottom-Up Integration testing is particularly suited to Concurrent Programming. The slow build-up will introduce processes to one another in a controlled manner which allows the consequences of their interactions to be fully determined

Following are pros and cons of button up integration

a) Bad for functionally decomposed systems

b) Use full for integrating systems like, object oriented, real time systems etc

c) Systems that are specifically developed for performance requirements

2) Top down integration: -

Integrating the modules as per the priority which is derived from the design of an application. The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers.

Following are pros and cons of button up integration

a) Test cases can be defined in terms of functionality of the system

b) Sequence of the test data flow will be clear

c) Most common/frequently used integration technique

d) Writing stubs can be difficult, if modules are not ready

3) Umbrella Approach: -

Testing along functional data and control-flow paths. First, the inputs for functions are integrated in the bottom-up pattern. The outputs for each function are then integrated in the top-down manner. The primary advantage of this approach is the degree of support for early release of limited functionality. It also helps minimize the need for stubs and drivers. The disadvantage of this model is it is less systematic than the other two approaches, because of which more regression testing is required

Testing methodologies

Following are the most common test methodologies that are followed to test

A product

1) Black box testing

2) White box testing

3) Gray box testing

Black box testing:-

Is the most common test methodology which is very frequently used to test the Product Testing is done with out knowing the internal structure of the application or the code. Black box testing can be considered testing with respect to the specifications.

Advantages of black box testing:-

1) More effective on larger units of code than white box testing

2) Tester needs no knowledge of implementation, including specific programming Lang.

3) Tester and programmer are independent of each other

4) Tests are done from a user's point of view

5) Will help to expose any ambiguities or inconsistencies in the specifications

6) Test cases can be designed as soon as the specifications are complete

White box testing:-

Examines the program structure and derive test data from the program logic. Structural testing is sometimes referred to as clear-box testing since white boxes are considered opaque and do not really permit visibility into the code.

Advantages of White Box Testing

1) Forces test developer to reason carefully about implementation

2) Approximates the partitioning done by execution equivalence

3) Reveals errors in "hidden" code

4) Beneficent side-effects

5) Optimizations (e.g. chartable that changes reps when size > 100)

Few of the white box testing techniques are

1) Syclomatic complexity

2) Branch coverage

3) Path coverage

4) Statement coverage

Gray box testing:-

Is a combination of black box and white box testing. In this type of test approach Part of the application will be tested with white box testing and remaining application features are tested with black box testing methodology.

(Note)Selection of the module which has the maximum impact on other modules of the

Application should be considered for white box testing and rest of the modules Should be tested with black box testing.

Test Report

Test report is a document which will be prepared at the end of the project or at the End of the build. It contains over all project proceedings along with the entire Project details .it has the following information

a) Test phase actual start date & end date (this can be for build wise also)

b) Environment (all operating systems & software’s)

c) Total Number of builds

d) Total number of Test cases executed (this can be for build wise also)

e) Total number of test cases passed

f) Total number of test cases failed

g) Total number of test cases blocked

h) Total number of bugs reported

i) Total number of major, minor, trivial bugs (this can be given build wise also)

j) Total effort (calculating in man hours)

          (Here ends the testing life cycle)

Regression Testing

Regression testing is a process, which tests a system once again to ensure that it still functions as expected / as per specifications or its requirements. In brief we can say Regression testing as verification of a bug when it has been fixed

(Note1) for example, If a bug is fixed in a module called “User” and if that bug has an impact on the other module called “report” then execute all the test cases of both modules to ensure that Functionality remains same

(Note2) if a module has 50 test cases and only one test case found to be failed and same has been logged as a bug, when it fixed and reverts back for verification you have to

Execute all the 50 cases.

Preparation of bug tracing report

By preparing defect tracking report for each build or cycle, it becomes easy to Estimate the bug density which is generally calculated as

                              “Number of defects/Lines of code”

This will help us in estimating the time requirement for the next build or cycle. Apart from this, it gives a clear view of the project bug tracking