Manual Testing

What is Testing?
* An examination of the behavior of a program by executing on sample data sets.
* Testing comprises of set of activities to detect defects in a produced material.
* To unearth & correct defects.
* To detect defects early & to reduce cost of defect fixing.
* To avoid user detecting problems.
* To ensure that product works as users expected it to.

Why Testing?
* To unearth and correct defects.
* To detect defects early and to reduce cost of defect fixing.
* To ensure that product works as user expected it to.
* To avoid user detecting problems.

Testing Techniques

Black Box Testing -Testing of a function without knowing internal structure of the program.
White Box Testing -Testing of a function with knowing internal structure of the program.

Regression Testing -To ensure that the code changes have not had an adverse affect to the
other modules or on existing functions.

Functional Testing:
* Study SRS
* Identify Unit Functions
* For each unit function
- Take each input function
- Identify Equivalence class
- Form Test cases
- Form Test cases for boundary values
- From Test cases for Error Guessing
* Form Unit function v/s Test cases, Cross Reference Matrix
* Find the coverage

Unit Testing:
* The most 'micro' scale of testing to test particular functions or code modules. Typically done by
the programmer and not by testers .
* Unit - smallest testable piece of software.
* A unit can be compiled/ assembled/ linked/ loaded; and put under a test harness.
* Unit testing done to show that the unit does not satisfy the functional specification and/ or its
implemented structure does not match the intended design structure.

Integration Testing:
* Integration is a systematic approach to build the complete software structure specified in the
design from unit-tested modules. There are two ways integration performed. It is called Pre-test
and Pro-test.
* Pre-test: the testing performed in Module development area is called Pre-test. The Pre-test is
required only if the development is done in module development area.

Alpha testing:
* Testing of an application when development is nearing completion minor design changes may
still be made as a result of such testing. Typically done by end-users or others, not by
programmers or testers.

Beta testing:
* Testing when development and testing are essentially completed and final bugs and problems
need to be found before final release. Typically done by end-users or others, not by
programmers.

System Testing:
* A system is the big component.
* System testing is aimed at revealing bugs that cannot be attributed to a component as such, to
inconsistencies between components or planned interactions between components.
* Concern: issues, behaviors that can only be exposed by testing the entire integrated system
(e.g., performance, security, recovery).

Volume Testing:
* The purpose of Volume Testing is to find weaknesses in the system with respect to its handling
of large amounts of data during short time periods. For example, this kind of testing ensures that
the system will process data across physical and logical boundaries such as across servers and
across disk partitions on one server.

Stress testing:
* This refers to testing system functionality while the system is under unusually heavy or peak
load; it's similar to the validation testing mentioned previously but is carried out in a "high-stress"
environment. This requires that you make some predictions about expected load levels of your
Web site.

Usability testing:
* Usability means that systems are easy and fast to learn, efficient to use, easy to remember,
cause no operating errors and offer a high degree of satisfaction for the user. Usability means
bringing the usage perspective into focus, the side towards the user.

Security testing:
* If your site requires firewalls, encryption, user authentication, financial transactions, or access to
databases with sensitive data, you may need to test these and also test your site's overall
protection against unauthorized internal or external access.

Test Life Cycle

* Identify Test Candidates

* Test Plan
* Design Test Cases
* Execute Tests
* Evaluate Results
* Document Test Results
* Post Shipment Review

Test Plan:
* A Test Plan is a detailed project plan for testing, covering the scope of testing, the methodology
to be used, the tasks to be performed, resources, schedules, risks, and dependencies. A Test
Plan is developed prior to the implementation of a project to provide a well defined and
understood project roadmap.
Test Specification:
* A Test Specification defines exactly what tests will be performed and what their scope and
objectives will be. A Test Specification is produced as the first step in implementing a Test Plan,
prior to the onset of manual testing and/or automated test suite development. It provides a
repeatable, comprehensive definition of a testing campaign.

Testing Process
In a software development process, there are five different phases. They are
-Requirement analysis
-Design
-Development (or) Coding
-Testing
-Maintenance

Here the testing comes in fourth phase. But the actual testing process begins during the first
phase itself i.e. testing process begins during the Requirement analysis phase itself.

The steps in the testing process are as follows.

1. Requirement analysis
Testing should begin in the requirements phase of the software life cycle (SDLC). The actual
requirement should be understand clearly with the help of Requirement Specification documents,
Functional Specification documents, Design Specification documents, Use case Documents etc.

During the requirement analysis the following should be considered.

-Are the definitions and descriptions of the required capabilities precise?
-Is there clear delineation between the system and its environment?
-Can the requirements be realized in practice?
-Can the requirements be tested effectively?

2. Test Planning
During this phase Test Strategy, Test Plan, Test Bed will be created.
A test plan is a systematic approach in testing a system or software.
The plan should identify:
-Which aspects of the system should be tested?
-Criteria for success.
-The methods and techniques to be used.
-Personnel responsible for the testing.
-Different Test phase and Test Methodologies
-Manual and Automation Testing
-Defect Mgmt, Configuration Mgmt, Risk Mgmt. Etc
-Evaluation & identification – Test, Defect tracking tools

3. Test Environment Setup

During this phase the required environment will be setup will be done. The following should also
be taken in account.
- Network connectivity’s
-All the Software/ tools Installation and configuration
-Coordination with Vendors and others

4. Test Design
During this phase
-Test Scenarios will be identified.
-Test Cases will be prepared.
-Test data and Test scripts prepared.
-Test case reviews will be conducted.

5. Test Automation
In this phase the requirement for the automation will be identified. The tools that are to be used
will be identified. Designing framework, scripting, script integration, Review and approval will be
undertaken in this phase.

6. Test Execution and Defect Tracking

Testers execute the software based on the plans and tests and report any errors found to the
development team. In this phase

-Test cases will be executed.

-Test Scripts will be tested.
-Test Results will be analyzed.
-Raised the defects and tracking for its closure.

7. Test Reports
Once testing is completed, testers generate metrics and make final reports on their test effort and
whether or not the software tested is ready for release.

-Test summary reports will be prepared

-Test Metrics and process Improvements made
-Build release
-Receiving acceptance

Testing Templates
Test Plan Template:
The Test Plan describes the overall approach to development, integration, qualification, and
acceptance testing. It describes plans for testing software systems; test environment to be used
for the testing; identifies tests to be performed, and provides schedules for test activities.

The software Test Plan is used by IT Manager, Test Manager, Documentation Manager, System
Administrator, Technical Architect, Development Manager, Project Manager.

The Test Plan is used to perform system testing, subsystem testing, assembly testing,
subassembly testing, module testing, user acceptance testing. The Test Plan includes step by
step instructions for the various types of testing that will occur during the project lifecycle; it also
defines the required test equipment, calibration requirements, test facility requirements, and other
key factors.
This is a sample of an outline for a test plan. It has been designed for medium to small test
projects, and thus is fairly lightweight. It is by necessity general, because each enterprise, each
development group, each testing group, and each development project is different. This outline
should be used as a set of guidelines for creating your own standard template; add to it or
subtract from it as you find appropriate.

Contents of test plan:

Introduction:
This section contains the purpose and objectives of the test plan.
Scope
Items to be tested
Refer to the functional requirements that specify the features and functions to be tested.
Items not to be Tested
List the features and functions that will not be covered in this test plan. Identify briefly the reasons
for leaving them out.

Test Strategy
Testing is the process of analyzing a software item to detect the differences
between existing and required conditions and to evaluate the features of the
software item. This may appear as a specific document (such as a Test
Specification), or it may be part of the organization's standard test approach. For
each level of testing, there should be a test plan and an appropriate set of
deliverables. The test strategy should be clearly defined and the Software Test
Plan acts as the high-level test plan.

Environment Requirements
System Requirements :
This section should be filled out in detail for new projects. For existing maintenance tasks, a
simple cross-reference to the document describing existing system requirements is fine.
Hardware/ software requirements :
This section contains the details of system/server required to install the application or perform the
testing, specific s/w that needs to be installed on the system to get the application running or to
connect to the database, connectivity related issues etc.

Test Schedule
Identify the estimated effort required to execute the test plan. Include a both a range and a
confidence level. Identify the resources available to carry out the test plan.
Identify time or resource constraints that will lead to a risk of the test project falling behind
schedule, below expected scope, or below expected quality.

Resources and Responsibilities

This section will explain the roles and responsibilites of the management team, testing team,
Business team, testing support team and external support team.

Deliverables
This section contains various deliverables that are due to the client at various points of time. i.e.
daily, weekly, start of project, end of project etc. these could include test plans, test procedures,
test matrices, status reports, test scripts etc. templates for all these also be attached.

Suspension / Exit Criteria

This is a particular risk clause to define under what circumstances testing would stop and restart
If any defects are found which seriously impact the test progress, the QA manager may choose to
Suspend testing. Criteria that will justify test suspension are:
Hardware/software is not available at the times indicated in the project schedule.
Source code contains one or more critical defects, which seriously prevents or limits testing
progress.
Assigned test resources are not available when needed by the test team.

Risks
Define in advance what could go wrong with a plan and the measures that will be taken to deal
with these problems
The event causing the risk.
The likelihood of the event happening.
The impact on the plan if the event occurs.

Tools
Apart from manual testing list the tools used for automating the unit testing, functional testing,
performance testing and user interface testing.

Documentation
This section contains the embedded documents or links to document which have been/will be
used in the course of testing. E.g. Templates used for reports, test cases etc. reference
documents can also be attached here.

Approvals
This section contains the mutual agreement between the client and QA team with both leads/
managers signing off their agreement on the test plan.

Test Case:

Test case is a document that describes an input, action or event and an expected
response to determine if a feature of an application is working correctly and meets the
user requirements.

A Good test case is the one that has high probability of finding as yet undiscovered error.

The Test case document contains the following fields:

Test case id:

This is an id given to every test case and it should be unique.

Test case decription:

This field contains the brief description of what we are going to test in that application.

Test input:
This contains the input that we are going to give to test the application or system.

Test Action:
This field explains the action to be performed to execute the test case.

Expected results :
This fielsd contains the description of what tester should see after all test steps has been
completed

Actual results :
This field contains a brief description of what the tester saw after the test steps has been
completed.

Result:
This is often replaced with either pass or fail. If both the expected result and actual result
are same
then the result is pass else the result is fail.