Quality is never an accident, it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives, rightly stated by William A. Foster.

1. In depth Guide for Manual Testing
Quality is never an accident, it is always the result of high intention, sincere effort, intelligent
direction and skillful execution; it represents the wise choice of many alternatives, rightly
stated by William A. Foster.
Most of the companies today use modern automated testing tools and latest technology for
testing their solution, however the testing cycle does not get complete without manual
testing. If we go through the actual stats, 70-75% of the solution is being tested manually and
only 25% of it is tested using automated testing scripts.
The 25% of software solution covers a business process which deals with huge chunks of
data and verified from multiple sources.
Why Manual Testing is More Important than the
Automation Testing?
Manual testing is the hidden crunch without which a solution cannot be successfully

2. launched in the market. Here are some points why we say so:
•There are so many limitations while the automated testing will detect most bugs in
the software system. For example, the automated tools can’t test for visual
considerations like gestures, image color or font size. It is not possible to test the User
Experience and User Interface through the automation testing. Changes in these can
only be detected and done by manual testing, which means that not all testing can be
done with automatic tools. Manual testing is preferable for products with engineered
user experience and GUIs with constant updates.
•As the name “Automation Testing” which means just refers to “Automatic”. They are
just robotic and can’t act as a real user prospective. Manual testing, on the other end,
allows the developing program to be used as it would be upon launch. Any bugs that
may pop up when a user handles the program in a certain way are more likely to be
caught with manual testing.
•Many times situations arise when there are runtime changes in the functionality of
some modules either as an enhancement or behavior change of the module. In this
case the time and precision of functionality play a major role. Now before starting the
automated testing, the tester has to set up test cases, program it into the automated
tool, and then run the tests. But with manual testing, the QA can quickly test and see
the results. Automatic tests take more time to set up, which doesn’t allow testing
ideas quickly and easily.
•By using the Automation tool, it is impossible to run again the test case of any
application which had already executed before.
•Ad-hoc testing can’t be performed using Automation.
•Manual testing is the only one option during the initial stage of the application.
When the application is in regression phase and stable then the user can automate
the basic functions within the application. In an unstable build if the user automate
something in the next changed builds that will surely break. Moreover, it has been
observed most of good defects are found by doing some exploratory kind of testing
instead of just going through the test steps written as a test case. So test automation
cannot substitute the experience and underlying knowledge of the tester to find good
bugs in the application.
•Negative testing can be done more rigorously via manual testing.

3. •If a test fails the automation test will only result the failure and could not perform a
workaround to test other areas even if one thing fails. In this manual test can only
work that out.
The QA, who tests the software, drafts all the test cases and executes those test cases
manually. One major advantage of manual testing includes ease of testing for customized
modules as per the requirements which are defined and input output deliverable as
discussed. Also, it can be executed with ultimate ease and perfection without fancy coding
and special programs.
Let’s check out the mastermind using which the manual testing is executed:
Test Plan
A Test plan is the blueprint of systematic approach the tester creates before testing the
machine or software. It’s a detailed document which covers below listed information
sections:
•Objective of the software
•Scope
•Approach
•Software testing effort
The test plan is a very needful to think through the efforts needed to validate the
acceptability of a software product. That completed document will help the people outside
the test group to understand the “WHY” and “HOW” of the product validation.

4. Test Strategy
“Specific, Practical, Justified”: These three words belong to a good test strategy which means
how the company is planning to complete the application/product with a proper
development as well as proper assessment of quality. The main aim of preparing the Test
strategy is to clearly mention the important activities and the challenges that need to do for
the test project. By other names the test strategy is known as test Approach and Test
Architecture. Basically the test strategy describes which types of testing should be done for
projects.
It involves User Acceptance Testing (UAT), functional testing, load testing, performance
testing, security testing and lots more.
Steps for Writing Test Cases
Let’s see some tips on how to write test cases, test case procedures and some basic test case
definitions.
Analyzing Requirements: It is the most important steps that the QA needs to understand
the requirement of the product/application while drafting the test cases for the same i.e.
What are the things/steps needs to test, which things are the requirement of the
product/application and what should be the expected results for the executed testing steps.

5. Writing Test cases (Designing the test): Based on the requirement, a test case should be
drafted with high level scenarios. So every requirement should have at least one test or more
than that.
Executing test case (Execution test): Once the test cases are drafted and the testing team
receives the solution built, they should be executed. Development and the testing should be
done by parallel. At the time of testing, always there is a chance that the expected result of
the test cases may differ from the actual results of the test cases. In that scenario, it will be
an issue/Bug. That particular issue/Bug should be reported to the developer/development
team and as per the priority of the issue/bug, that issue should be resolved by the
development team of the project. For each test case, the test cases generally having the
unique test case ID and below mentioned the sequence of the test case details.
•Purpose: Purpose of the test case
•Executed Steps: List of steps that the QA has to follow while executes the test case
while testing.
•Expected results: The results i.e. expected for the test cases after the execution
•Actual result: Actual result of the test case
•Status: Identify the test case whether the test case is passed, failed, Blocked, skipped
or Cancel after the execution.
•Pass: The Actual results is same with the expected results of the test case
•Failed: The Actual results are not matched with the expected results of the test case
and issue found for the same.
•Blocked: QA is not able to continue the testing and execute the test case due to any
issue.
•Skipped: Test case is not executed in the testing round and which is not affected in
any requirement of the product/application.
•Bug ID
QA Matrix (Attach the requirement): QA Matrix refers to a sheet which maintains how
many numbers of requirements are tested and for that how many numbers of test cases are
drafted. It is just a form of an excel sheet where it will show that whether it is covered the
requirement or not. In case, any requirement is missed which needs to be tested and there is
a possibility that issue arising in that case it is better to refer the QA Matrix.
Sample of a QA matrix

6. Test Case:
File Open #
Test Description Test Cases/
Samples
Pass/Fail No. of
Bugs
Bug# Comments
N/A Setup for [Project Name] setup - - -
1.1
Test that file types
supported by the
program can be opened
1.1 P/F # #
1.2
Verify all the different
ways to open file (mouse,
keyboard and
accelerated keys)
1.2 P/F # #
Defect Life Cycle
Raise Defects
The issues can be arises in any stages of the SDLC(Software development life cycle) instead
of during testing cycles. The issue will be arise When the expected results of the test cases is
not same with the actual results of the test case. While executing the test cases for a
product/application, if the expected result of the test case is not same with the actual result
of the test cases, then the issue/defect/bug can be raised against the development team. At
the first time of reporting the issue, the status of the issue should be in “Open/New”. The
Developer/development team will verify whether that reported issue is valid or not and can
change the status of issue to reject or fixed of cancelled. After they verify the issue from the
development team, the status of the issues should change to “Cancelled” or “Pending” up to

7. that time until the issues is fixed. When the issue/bug is fixed, then the status can be changed
to “Resolved” by the development team and assigned to the QA to verify the issues either it is
solved or not.
•Open Defects: The issues which are listed out in the bug tracking system without
resolve status. There should be the access of the bug tracking system to the
development team. There should be an issue ID, title of issue, issue found area, any
attached image for which it should be easy to track the open issue.
•Cancelled Defects: The issues which are reported by mistakely on the bug tracking
system or the issues which are reported out of the requirement should be listed out
in the cancelled status.
•Pending Defects: The list of defects remaining in the defect tracking system with a
status of pending. Pending refers to any defect waiting on a decision from the project
manager or Business Analyst before a developer addresses the problem.
•Fixed Defects: The issues which are resolved from the development team and
waiting for the verification from the QA side should be categories under the fixed
defects.
•Closed Defects: The issues which are verified by the QA side and fixed by the QA
during the project life cycle must be listed out in closed defect list.
•Retest and correct defects: Once the issues are resolved from the development
team, the test cases which are failed initially need to be retested and check for any
new defects.
To conclude the blog on Manual testing, there should always need for manual testing in the
software Industry. I hope I have given the brief overview on Manual testing, which gives an
understanding on software manual testing as well as the importance of manual testing. Share
your thoughts on manual testing by commenting below.