Software Testing -Tutorial

Even the most carefully planned and designed software, cannot possibly be free of defects. Your goal as a quality engineer is to find these defects. This requires creating and executing many tests.

In order for software testing to be successful, you should start the Software Testing process as soon as possible. Each new version must be tested in order to ensure that "improvements" do not generate new defects.

If you begin Software Testing only shortly before an application is scheduled for release, you will not have time to detect and repair many serious defects. Thus by Software Testing ahead of time, you can prevent problems for your users and avoid costly delays.

Let us derive the main definition for Software Testing.

The main purpose of Software Testing is to identify the defects.

Defect:-A flow in a component or system that can cause the component or system to fail to perform its required function.

Fault:- Fault is similar to a defect.

Failure:-Deviation of the component or system from its expected delivery,service or result.

Error:-A human action that produces an incorrect result.

Bug:- Bug is similar to that of an defect.

Isolating means seperation or dividing the defects.

These isolated defects are collected in the Defect Profile

Defect Profile Document

a.Defect Profile is a document with many columns in Software Testing.

b.This is a template provided by the company.

Subjected for rectification

The Defect Profile is subjected for rectification that means it is send to developer

Defects are rectified

After getting from the developer make sure all the defects are rectified,before defining it as a Quality product.

What is Quality in Testing?

Quality is defined as justification of user requirements or satisfaction of user requirements.

Here are some of the terminology that has to be learned as part of Software Testing:-
First of all let us know the major difference between the project and product in Software Testing.

1.Project:It means that exact rules i.e the customer requirements must be followed.
2.Product:This is based on the general requirements i.e on our own requirements.
3.Quotation in Software Testing: Estimating the cost of the project.
4.Bidding of the Project:

Consider for example:-
If any bank want to Automate its procedures then that would bid or would call for various
IT development companies.


5.Key Process Areas in Software Testing:-Instead of repeating the same process again and again we can keep out of them.

Consider for example:-The login page for different projects would be the same.

6.Project Initiation Note(PIN) in Software Testing:-This is nothing but a mail to the Company Director.

Software Testing-COMPANY STRUCTURE

This is the basic Structure that is followed by most of the Companies.

Now let us see the category of Human Resources in Software Testing

QA:-Quality Assurance.

CEO:-Chief Executive Officer.

D:-Directors.

HTL:-Head Team Leader.

TM:-Technical Manager.

QM:-Quality Manager.

QTL:-Quality Team Leader.

PM:-Project Managers.

QL:-Quality Leader.

TL/PL:-Team Leader/Project Leader.

TL:-Test Leader.

SSE:-Senior Software Engineer.

STE:-Senior Test Engineer.

SE:-Software Engineer.

TE:-Test Engineer.

Software Testing-Testing Process

1.The Application we are testing is called as Application Under Testing.

2.The Application is divided into 2 parts:-

a)Structure:-

b)Functional:-

3.The Structural part is tested by Developer.

4.The Structural part is called as Invisible.

5.The Functional part is tested by Test Engineer.

6.The Functional part is called as Visible.

Fundamental Test Process in Software Testing

The fundamental test process in Software Testing comprises planning, specification, execution, recording and checking for completion.

You will find organizations that have slightly different names for each stage of the process and you may find some processes that have just few stages for example. However, you will find that all good test processes adhere to this fundamental structure.

Test specification in Software Testing (sometimes referred to as test design) involves designing test conditions and test cases using recognized test techniques identified at the planning stage.

Here it is usual to produce a separate document or documents that fully describe the tests that you will carry out. It is important to determine the expected results prior to test execution.

Test execution involves actually running the specified test on a computer system either manually or by using an automated test tool

Test recording involves keeping good records of the test activities that you have carried out. Versions of the software you have tested and the test specifications are software you have tested and the test specifications are recorded along with the actual outcomes of each test

Checking for test completion involves looking at the previously specified test completion criteria to see if they have been met. If not, some test may need to be re-run and in some instances it may be appropriate to design some new test cases to meet a particular coverage target.

Successful tests detect faults

As the objective of a test should be to detect faults, a successful test is one that does detect a fault.

This is counter-intuitive, because faults delay progress; a successful test is one that may cause delay.

The successful test reveals a fault which, if found later, may be many more times costly to correct so in the long run, is a good thing

Meaning of completion or exit criteria in Software Testing

Completion or exit criteria are used to determine when testing (at any stage) is complete. These criteria may be defined in terms of cost, time, faults found or coverage criteria.

Coverage criteria in Software Testing

Coverage criteria are defined in terms of items that are exercised by test suites, such as branches,user requirements, most frequently used transactions etc

Testing and Expected Results in Software Testing

The specification of expected results in advance of test execution is perhaps one of the most fundamental principles of testing computer software. If this step is omitted then human subconscious desire for tests to pass will be overwhelming and tester may perhaps interpret a plausible, yet erroneous result, as correct outcome.

As you will see when designing test using black box and white box techniques in Software Testing there is ample room within the test specification in Software Testing to write down you expected results and therefore no real excuse for not doing it.

If you are unable to determine expected results for a particular test that you had in mind then it its not a good test as you will not be able to

(a) determine whether it has passed or not and

(b) you will never be able to repeat it.

Even with a quick and dirty ad-hoc test it is advisable to write down beforehand what you expect to happen. This may all sound pretty obvious but many test efforts have floundered by ignoring this basic principle.

" The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong does go wrong it usually turns out to be impossible to get at or repair."

Chapter 2

Software Testing-Testing Requirements

Software testing is not an activity to take up when the product is ready. An effective Software Testing begins with a proper plan from the user requirements stage itself. Software testability is the ease with which a computer program is tested. Metrics can be used to measure the testability of a product. The requirements for effective Software Testing are given in the following sub-sections.

* Operability in Software Testing:

1. The better the software works, the more efficiently it can be tested.

2. The system has few bugs (bugs add analysis and reporting overhead to the test process)

3. No bugs block the execution of tests.

4. The product evolves in functional stages (allows simultaneous development & testing)

* Observability in Software Testing:

1. What is seen is what is tested

2. Distinct output is generated for each input

3. System states and variables are visible or queriable during execution

4. Past system states and variables are visible or queriable (eg., transaction logs)

5. All factors affecting the output are visible

6. Incorrect output is easily identified

7. Incorrect input is easily identified

8. Internal errors are automatically detected through self-testing mechanism

9. Internally errors are automatically reported

10. Source code is accessible

* Controllability in Software Testing:

1. The better the software is controlled, the more the testing can be automated and optimised.

2. All possible outputs can be generated through some combination of input in Software Testing

3. All code is executable through some combination of input in Software Testing

4. Software and hardware states can be controlled directly by testing

5. Input and output formats are consistent and structured in Software Testing

6. Tests can be conveniently specified, automated, and reproduced.

* Decomposability in Software Testing:

1. By controlling the scope of testing, problems can be isolated quickly, and smarter testing can be performed.

2. The software system is built from independent modules

3. Software modules can be tested independently in Software Testing

* Simplicity in Software Testing:

1. The less there is to test, the more quickly it can be tested in Software Testing

2. Functional simplicity

3. Structural simplicity

4. Code simplicity

* Stability in Software Testing:

1. The fewer the changes, the fewer the disruptions to testing

2. Changes to the software are infrequent

3. Changes to the software are controlled in Software Testing

4. Changes to the software do not invalidate existing tests in Software Testing

5. The software recovers well from failures in Software Testing

* Understandability in Software Testing:

1. The more information we have, the smarter we will test

2. The design is well understood in Software Testing

3. Dependencies between internal external and shared components are well understood.

4. Changes to the design are communicated.

5. Technical documentation is instantly accessible

6. Technical documentation is well organized in Software Testing

7. Technical documentation is specific and detailed

8. Technical documentation is accurate

Chapter -3

In this section we will discuss the necessity of Software Testing

Errors,Faults and Failures are occurred while developing the Software Project.

We can illustrate these points with the true story Mercury spacecraft.

The computer program ABOA spacecraft contained the following statement with the FORTRAN programming language.

.DO 100 I = 1.10

The programmer's intention was to execute a succeeding statements up to line 100 ten times then creating a loop where the integer variable I was using the loop counter, starting 1 and ending at 10.

Unfortunately, what this code actually does is writing variable I do to decimal value 1.1 and it does that once only. Therefore remaining code is executed once and not 10 times within the loop. As a result spacecraft went off course and mission was abort considerable cost!).

The correct syntax for what the programmer intended is:--

.DO 100 1=1,10

So a small mistake make a very big thing.

We would see how do Errors occur in Software Testing:-

Why do we make errors that cause faults in computer software leading to potential failure of our systems? Well,firstly we are all prone to making simple human errors. This is an unavoidable fact of life. However,this is compounded by the fact that we all operate under real world pressures such as tight deadlines, budget restrictions, conflicting priorities and so on

Cost of errors in Software Testing

The cost of an error can vary from nothing at all to large amounts of money and even loss of life. The aborted Mercury mission was obviously very costly but surely this is just an isolated example. Or is it? There are hundreds of stories about failures of computer systems that have been attributed to errors in the software. A few examples are shown below:

A nuclear reactor was shut down because a single line of code was coded as X = Y instead of X=ABS (Y) i.e. the absolute value of Y irrespective of whether Y was positive or negative.

Reliability in Software Testing

Reliability is the probability that software will not cause the failure of a system for a specified time under specified conditions. Measures of reliability include MTBF (mean time between failure), MTTF (mean time to failure) as well as service level agreements and other mechanisms.

Exhaustive testing why not test everything?

It is now widely accepted that you cannot test everything in Software Testing. Exhausted testers you will find, but exhaustive testing you will not. Complete Software Testing is neither theoretically, nor practically possible.

Consider a 10 character string that has 280 possible input streams and corresponding outputs. If you executed one test per microsecond it would take approx. 4 times the age of the Universe to test this completely.

Software Testing and risk

How much testing would you be willing to perform if the risk of failure were negligible? Alternatively, how much Software Testing would you be willing to perform if a single defect could cost you your life's savings, or, even more significantly

Software Testing and quality

Software Testing identifies faults whose removal increases the software quality by increasing the software's potential reliability. Software Testing is the measurement of software quality. We measure how closely we have achieved quality by testing the relevant factors such as correctness, . reliability, usability, maintainability,reusability, testability etc

How much Software Testing is enough?

It is difficult to determine how much Software Testing is enough. Software Testing is always a matter of judging risks against cost of extra testing effort. Planning test effort thoroughly before you begin, and setting completion criteria will go some way towards ensuring the right amount of Software Testing is attempted. Assigning priorities to tests will ensure that the most important tests have been done should you run out of time.

Software Testing can be performed in either the two types:-

1.Conventional:-In this Software Testing is started after the Coding.

2.UnCoventional:-In this Software Testing is done from the Initial Phase.

Before that we need to know couple of main definitions regarding the terminology in the company

PROJECT in which exact rules must be followed that is customer requirements

PRODUCT which are based on general requirements that is on our own requirements

Chapter -4

Software Testing Development Life Cycle

Life Cycle of Software Testing Process
The following are some of the steps to consider:

• Obtain requirements, functional design, and internal design specifications and other necessary documents
• Obtain schedule requirements
• Determine project-related personnel and their responsibilities, reporting requirements, required standards and processes (such as release processes, change processes, etc.)
• Identify application's higher-risk aspects, set priorities, and determine scope and limitations of tests
• Determine test approaches and methods - unit, integration, functional, system, load, usability tests, etc.
• Determine test environment requirements (hardware, software, communications, etc.)
• Determine testware requirements (record/playback tools, coverage analyzers, test tracking, problem/bug tracking, etc.)

• Determine test input data requirements

• Identify tasks, those responsible for tasks

• Set schedule estimates, timelines, milestones

• Determine input equivalence classes, boundary value analyses, error classes

• Prepare test plan document and have needed reviews/approvals

• Write test cases

• Have needed reviews/inspections/approvals of test cases

• Prepare test environment and testware, obtain needed user manuals/reference documents/configuration guides/installation guides, set up test tracking processes, set up logging and archiving processes, set up or obtain test input data

• Obtain and install software releases

• Perform tests

• Evaluate and report results

• Track problems/bugs and fixes

• Retest as needed

• Maintain and update test plans, test cases, test environment, and testware through life cycle

This is the basic diagram of Software Testing Development Life Cycle.

Chapter 5

Software Testing-Testing Life Cycles

Before going to the Testing Life Cycle in Software Testing,
we need to know how the software is developed and its Life Cycle in Software Testing.
The Software Development Life Cycle (SDLC) is also called as
the Product Development Life Cycle (PDLC) in Software Testing.

The SDLC in Software Testing has 6 phases:-
They are:-
a)Initial Phase in Software Testing
b)Analysis Phase in Software Testing
c)Design Phase in Software Testing
d)Coding Phase in Software Testing
e)Testing Phase in Software Testing
f)Delivery & Maintenance Phase in Software Testing

Now let Us discuss each phase in detail:--
a)Initial Phase in Software Testing:-
(i)Gathering the Requirements:-
The Business Analyst(BA) will gather the information of the company through one template which is predefined and goes to client.
He would collect all the information of what has to be developed and in how many days and all the basic requirements of the company.
For the proof of his collection of information the Business Analyst(BA) would prepare one document called as either
BDD in Software Testing:--Business Development Design
BRS in Software Testing:--Business Requirement Specification
URS in Software Testing:--User Requirement Specification
CRS in Software Testing:--Customer Requirement Specification
All are the same.

(ii)Discussing the Financial Terms and Conditions:--
The Engagement Manager(EM) would discuss all the Financial Matters.

b)Analysis Phase in Software Testing:-

In this phase the BDD document is taken as the input.

In this phase 4 steps are done.

(i)Analyse the requirements in Software Testing:-In this step all the requirements are analysed and studyed.

(ii)Feasibility Study in Software Testing:-Feasibility means the possibility of the project developing.

(iii)Deciding Technology in Software Testing:-Deciding which techonology has to be used for example:

Either to use the SUN or Microsoft Technology etc:

(iv)Estimation in Software Testing:-Estimating the resources.for example:-Time,Number of people etc:

During the Analysis Phase the Project Manager prepares the PROJECT PLAN.

The output document for this phase is the Software Requirements Specification(SRS).

And this document is prepared by Senior Analyst(SR).Go to Top

c)Design Phase in Software Testing:-

The designing will be in 2 levels:-

(i)High Level Designing in Software Testing:-In this level of Designing the project is divided into number of modules.

The High Level Designing is done by Technical Manager(TM) or Chief Architect(CA).

(ii)Low Level Designing in Software Testing:-In this level of Designing the modules are further divided into number of submodules.

The Low Level Designing is done by Team Lead(TL).

In this Phase the Cheif Architect would prepare the Technical Design Document or Detail Design Document.Go to Top

d)Coding Phase in Software Testing:-

In this Phase the Developers would write the Programs for the Project by following the Coding standards.

In this phase the Developers would prepare the Source Code.Go to Top

e)Testing Phase in Software Testing:-

1.In the first phase when the BDD is prepared the Test Engineer would study the document, and send a Review Report to Business Analyst(BA).

2.Review Report in Software Testing is nothing but a document prepared by the Test Engineer while studying the BDD document and the points which he cannot understand and not clear are written in that report and sent to BA.

3.And the Test Engineer would write the Test Cases of application.

4.In Manual Testing there would be upto 50% defect free and in Automation Testing it would be 93% defect free.

5.In this Phase Testing people document called as Defect Profile DocumentGo to Top

f)Delivery & Maintenance Phase in Software Testing:-

1.In this Phase after the project is done a mailis iven to the client mentioning the completing of the project.

2.This is called as the Software Delivery Note.

3.The project is tested by client and is called as the User Acceptance Testing.

4.The project is installed in client environment and there testing is done called Port Testing in Software Testing

while installing if any problem occurrs the maintenance people would write the Deployment Document(DD) to Project Manager(PM).

5.After some time if client want to have some changes in the software and software changes are done by Maintenance.

Chapter 6

Software Testing-Testing Life Cycles

The internal processes in each of the following software lifecycle stage descriptions are Kickoff Process in Software Testing,Informal iteration Process,Formal iteration Process,In Stage assessment Process,and Stage exit Process

Kickoff Process in Software Testing:

• Each stage is initiated by a kickoff meeting, which can be conducted either in person, or by Web teleconference.
• The purpose of the kickoff meeting is to review the output of the previous stage, go over any additional inputs required by that particular stage, examine the anticipated activities and required outputs of the current stage, review the current project schedule, and review any open issues.
• The Primary Developer Representative is responsible for preparing the agenda and materials to be presented at this meeting.
• All project participants are invited to attend the kickoff meeting for each stage.

Informal Iteration Process:

• Most of the creative work for a stage occurs here. Participants work together to gather additional information and refine stage inputs into draft deliverables.
• Activities of this stage may include interviews, meetings, the generation of prototypes, and electronic correspondence.
• All of these communications are deemed informal, and are not recorded as minutes, documents of record, controlled software, or official memoranda.
• The intent here is to encourage, rather than inhibit the communication process.
• This process concludes when the majority of participants agree that the work is substantially complete and it is time to generate draft deliverables for formal review and comment.

Formal Iteration Process

• In this process, draft deliverables are generated for formal review and comment. Each deliverable was introduced during the kickoff process, and is intended to satisfy one or more outputs for the current stage.
• Each draft deliverable is given a version number and placed under configuration management control.
• As participants review the draft deliverables, they are responsible for reporting errors found and concerns they may have to the Primary Developer Representative via electronic mail.
• The Primary Developer Representative in turn consolidates these reports into a series of issues associated with a specific version of a deliverable.
• The person in charge of developing the deliverable works to resolve these issues then releases another version of the deliverable for review.
• This process iterates until all issues are resolved for each deliverable. There are no formal check off / signature forms for this part of the process. The intent here is to encourage review and feedback.
• At the discretion of the Primary Developer Representative and Primary End-user Representative, certain issues may be reserved for resolution in later stages of the development lifecycle.
• These issues are disassociated from the specific deliverable, and tagged as "open issues." Open issues are reviewed during the kickoff meeting for each subsequent stage.
• Once all issues against a deliverable have been resolved or moved to open status, the final (release) draft of the deliverable is prepared and submitted to the Primary Developer Representative.
• When final drafts of all required stage outputs have been received, the Primary Developer Representative reviews the final suite of deliverables, reviews the amount of labor expended against this stage of the project, and uses this information to update the project plan.
• The project plan update includes a detailed list of tasks, their schedule and estimated level of effort for the next stage.
• The stages following the next stage (out stages) in the project plan are updated to include a high level estimate of schedule and level of effort, based on current project experience.
• Out stages are maintained at a high level in the project plan, and are included primarily for informational purposes; direct experience has shown that it is very difficult to accurately plan detailed tasks and activities for out stages in a software development lifecycle.
• The updated project plan and schedule is a standard deliverable for each stage of the project.
• The Primary Developer Representative then circulates the updated project plan and schedule for review and comment, and iterates these documents until all issues have been resolved or moved to open status.
• Once the project plan and schedule has been finalized, all final deliverables for the current stage are made available to all project participants, and the Primary Developer Representative initiates the next process.

In-stage Assessment Process:

• This is the formal quality assurance review process for each stage in Software Testing.
• This process is initiated when the Primary Developer Representative schedules an in-stage assessment with the independent Quality Assurance Reviewer (QAR), a selected End-user Reviewer (usually a Subject Matter Expert), and a selected Technical Reviewer.
• These reviewers formally review each deliverable to make judgments as to the quality and validity of the work product, as well as its compliance with the standards defined for deliverables of that class.
• Deliverable class standards are defined in the software quality assurance section of the project plan.
• The End-user Reviewer is tasked with verifying the completeness and accuracy of the deliverable in terms of desired software functionality.
• The Technical Reviewer determines whether the deliverable contains complete and accurate technical information.
• The QA Reviewer is tasked solely with verifying the completeness and compliance of the deliverable against the associated deliverable class standard.
• The QAR may make recommendations, but cannot raise formal issues that do not relate to the deliverable standard.
• Each reviewer follows a formal checklist during their review, indicating their level of concurrence with each review item in the checklist.
• Refer to the software quality assurance plan for this project for deliverable class standards and associated review checklists.
• A deliverable is considered to be acceptable when each reviewer indicates substantial or unconditional concurrence with the content of the deliverable and the review checklist items.
• Any issues raised by the reviewers against a specific deliverable will be logged and relayed to the personnel responsible for generation of the deliverable.
• The revised deliverable will then be released to project participants for another formal review iteration.
• Once all issues for the deliverable have been addressed, the deliverable will be resubmitted to the reviewers for reassessment.

Once all three reviewers have indicated concurrence with the deliverable, the Primary Developer Representative will release a final in-stage assessment report and initiate the next process.

Stage Exit Process in Software Testing:

• The stage exit is the vehicle for securing the concurrence of principal project participants to continue with the project and move forward into the next stage of development.

• The purpose of a stage exit is to allow all personnel involved with the project to review the current project plan and stage deliverables, provide a forum to raise issues and concerns, and to ensure an acceptable action plan exists for all open issues.

• The process begins when the Primary Developer Representative notifies all project participants that all deliverables for the current stage have been finalized and approved via the In-Stage Assessment report.

• The Primary Developer Representative then schedules a stage exit review with the project executive sponsor and the Primary End-user Representative as a minimum.

• All interested participants are free to attend the review as well. This meeting may be conducted in person or via Web teleconference.

• The stage exit process ends with the receipt of concurrence from the designated approvers to proceed to the next stage.

• This is generally accomplished by entering the minutes of the exit review as a formal document of record, with either physical or digital signatures of the project executive sponsor, the Primary End-User Representative, and the Primary Developer Representative.

The initial steps to get a project is one of our Organization Business Analysts will go to Client place and he collects all the requirements and negotiate with the Clients regarding project and once it is approved he prepares documents like Project Proposal, Statement of Work, User Requirements Document and Business Rules. So these are the initial documents for any project.

Chapter 7

Software Testing-Stages of Testing Life Cycle

The following diagram is the Requirements Management Stage.

Project development will start from the Requirement Management stage with the Documents like Project Proposal, Statement of Work, User Requirement Document, Business Rules and Software works product. Development team analyzes and manages the requirements and final output of Requirements Management stage is System Requirement Specification Document, Requirements Traceability Matrix and Updated Project Data Collection Sheet

The Design stage will start has the inputs Software Requirement Document, Detailed Design Document Template, Requirements Traceability Matrix, Software Project Plan, Software Configuration Management Plan, Software Measurements/Metrics Plan and Software Quality Assurance Plan. Based on these documents he will develop and maintain Software Design according to the Software process and software Requirements and they will verify and document Software Design. Final output of this Design stage in SDLC is Detailed Design document, Updated Requirements Traceability Matrix, Unit Test Cases Document, Integration test cases document, System test plan document, Review and SQA audit reports for all test cases and Updated Project Data Collection Sheet.

this stage is pure technical in SDLC where Development Team use their skills in programming to implement the project. Implementation Plan/Programming Specification, Detailed Design Document, Software Project Plan, Software Configuration Management Plan, Software Measurement/Metrics plan, Software Quality Assurance Plan, Naming & coding conventions/standards, Unit Test Cases, Code Review Checklists, Utilities and Tools are the inputs for this stage and based on that they will Develop, maintain and verify the Software code. Final output of this stage is Executable Code, Unit Test Reports, Code Review Reports and Project Data Collection Sheet and source code for all individual modules. Peer Reviews conducted on source code and Unit testing will be completed. Some times the unit testing will be done by the Developers, who develop the code for the Modules(that based on Organization). In some organizations there is separate White-box testing team they will test the Logic, Error handling paths, all possible paths, Data Structures.

Chapter 8

Software Testing-Stages of Testing Life Cycle

The output of Unit Testing stage will be the input for this Integration Testing stage as shown in Fig. 3.5. here we will have Unit Test Modules, Detailed Design Document, Integration Test Cases, Software Project Plan, Software Configuration Management Plan, Software Measurements/Metrics Plan and SQA Plan as the inputs for this stage. The main task of this stage is Integrate all modules after that perform Integration Testing against Integration Test Cases and report and track the bugs. The final output of this stage is Integrated and baselined product, Integration Test Reports and Updated Project Data Collection Sheet. This testing done by Developers and sometimes by White-box Testers (based on the Organization).

It is pure black-box testing. As shown in the Fig. 3.6. System Test Plan, System Test Cases, Software Project Plan, Software Configuration Management Plan, Software Measurements/Metrics Plan and SQA Plan are the inputs for this stage here testing is performed as per the schedule and different tests depend upon the client requirement. After testing report and track the bugs. The final output of this System Testing is Integration Test Reports and Updated Data collection Sheet. Different type of tests like Compatibility testing, documentation Testing, Facility Testing, Installability Testing, Performance Testing, Procedure Testing, Recovery Testing, Security Testing, Serviceability Testing, Storage Testing, Functional Testing, Regression Testing, Load Testing, Stress Testing, Usability Testing, Link Testing and Volume Testing.

After completion of System Testing, we will have Software Requirement Specification Document, Detailed Design Document, Professional Service Agreement, System Tested Software Product and Software Project Plan documents as input for this phase. And in this stage the Information system will go live into production. Testing team installs the application in Production Environment and they will do some Client Acceptance Testing against User Requirements. Generally Alpha Testing and Beta Testing comes under Acceptance Test. The client in the presence of Developer at Developer Site will do alpha Testing. But beta Testing is done at the User end Client will distribute the application to the end-users and he will collect the feedback and bug reports from them. The final output of this stage gives a full-fledged User Manual, Installation Instructions, Release Notes and Updated Project Data Collection Sheet.

Once the application has been deployed successfully it needs 24 X 7 support provided to the customer so that the customer does not come across major problems in operating the system. It depends on the Organization to decide the strength of the support team. Generally supporting is done in three levels: 1. First Level Support (FLS)

2. Second Level Support (SLS)

3. Third Level Support (TLS)

First Level Support deals with logging of complaints that are explained by the Customers, it is the primary duty of the FLS professionals to keep track of the timing that has been taken to solve the issue. FLS professionals log the tickets and store it in an Open Server accessed by Second Level Support Professionals.

Second Level Support deals with the solving of the issue in an accurate way and also in a very short span of time. Once the SLS professionals find the issue complex and not solvable, it will be escalated to the Third Level Support.

Third Level Support is generally the high level professionals, who are well versed of the technology that has been used in the product and they are the professionals who take care of all complex issues. TLS Professionals would be concentrating on the time that required solving the issues.

In case the issue is a bug and has to be escalated to the Development Team then it is the duty of the TLS Unit to decide whether the bug has to be addressed early or not