In Depth Guide For Manual Testing

In depth Guide for Manual Testing
Intro
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 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.
• 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.
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.
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
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 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.
Original Source :
http://www.azilen.com/blog/guide-for-manual-testing/
Thanks You
www.azilen.com
Let us know if you have any Question!
info@azilen.com | +1-972-325-2243

In Depth Guide For Manual Testing

Uploaded by

Copyright:

Available Formats

In Depth Guide For Manual Testing

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

In Depth Guide For Manual Testing

Uploaded by

Copyright:

Available Formats

In depth Guide for Manual Testing

Manual testing is the hidden crunch without which a solution cannot be

• Ad-hoc testing can’t be performed using Automation.

• Objective of the software

“Specific, Practical, Justified”: These three words belong to a good test

It involves User Acceptance Testing (UAT), functional testing, load testing,

Analyzing Requirements: It is the most important steps that the QA needs to

QA Matrix refers to a sheet which maintains how many numbers of

You might also like