Manual testing is the process of manually testing software
It requires a tester to play the role of an end user, and use
most of all features of the application to ensure correct
To ensure completeness of testing, the tester often follows a
written test plan that leads them through a set of important
Levels of testing
Unit Testing: This initial stage in testing normally
carried out by the developer who wrote the code and
sometimes by a peer using the white box testing
Integration Testing: This stage is carried out in two
modes, as a complete package or as an increment to the
earlier package. Most of the time black box testing
technique is used. However, sometimes a combination of
Black and White box testing is also used in this stage.
System Testing: In this stage the software is tested from
all possible dimensions for all intended purposes and
platforms. In this stage Black box testing technique is
User Acceptance Testing : This testing stage carried out
in order to get customer sign-off of finished product. A
'pass' in this stage also ensures that the customer has
accepted the software and is ready for their use.
It is used in both big and small projects.
The test cases can be added or removed
according to the movement of the project.
Within a limited cost budget you can finish this
Manual testing is better than automated
testing in terms of reliability.
Tester can execute additional ad-hoc. You will
find that more bugs and errors are found with
adhoc than the automation.
By using manual testing, you cannot find the size
difference of the GUI object and color combination
In this type of testing, the real performance and
load cannot be determined for a huge number of
Manual testing is time consuming.
Planning is most appropriate step when you have
to start the testing. You need to carry on with
manual testing or automated testing easily.
Whether you go for any one of the types of
testing, you need to follow the following
Writing test cases
Executing test cases
Reporting results of test cases
The test plan describes the testing objectives, the testing
scope, the testing approach, and the methodology used
to conduct testing.
Any hardware, software, and other tools required for
testing should be included in the document.
Test coverage in the test plan states what requirements
will be verified during what stages of the product life.
Test methods simply states how the test coverage will be
Test plans also indicate which group or groups within
the organization will be responsible for performing the
A test case is usually a single step, or
occasionally a sequence of steps, to test the
correct behavior/functionalities, features of an
application. An expected result or expected
outcome is usually given.
Test cases are often referred to as test scripts,
particularly when written.
Written test cases are usually collected into test
Analyzing requirements: To write a good test case,
a tester needs to understand the requirement. In
what context the requirement is described and what
needs to be tested and how. What must be the
expected result etc?
Writing test cases (test designing): A test case is
developed based on the high level scenarios, which
are in turn developed from the requirement. So,
every requirement must have at least one test case.
This test case needs to be wholly concentrated on the
Executing test cases (test execution): Once all the
test cases are written, they need to be executed.
Execution starts only after the testing team receives
the build from the development. Development and
testing has to go parallel. While executing test cases,
there will always a possibility that the expected
result can vary from the actual result while testing.
In this case, it is a defect/bug. A defect needs to be
raised against the development team, and this defect
needs to be resolved as soon as possible based on the
schedule of the project.
A test case is identified by ID number and
prioritized. Each test case has the following
Purpose - Reason for the test case
Steps - A logical sequence of steps the tester must
follow to execute the test case
Expected Results - The expected result of the test
Actual Result - What actually happened when the
test case was executed
Status - Identifies whether the test case was
passed, failed, blocked or skipped.
Pass - Actual result matched expected result
Failed - Bug discovered that represents a failure of
Blocked - Tester could not execute the test case
because of bug
Skipped - Test case was not executed this round
Bug ID - If the test case was failed, identify the
bug number of the resulting bug.
Attaching requirements (QA Matrix): QA matrix is
used to assess how many requirements have been
tested and have test cases written for them. It is in
the form of a excel sheet, which shows whether a
requirement is covered or not.
Set up for [Product
Test cases/ Pass
Test that file types
supported by the
program can be
Verify all the
different ways to
open file (mouse,
Verify files can be
open from the local
drives as well as