In depth Guide for Manual Testing - PowerPoint PPT Presentation


PPT – In depth Guide for Manual Testing PowerPoint presentation | free to download - id: 8705eb-OTVkO


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

In depth Guide for 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 – PowerPoint PPT presentation

Number of Views:13
Slides: 23
Provided by: AzilenTech
Tags: guide | manuel | testing


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: In depth Guide for Manual Testing

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 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 cant
    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
    cant 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 doesnt 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 cant be performed using
  • 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

  • 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.

  • Lets 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. Its 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

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
  • Lets see some tips on how to write test cases,
    test case procedures and some basic test case
  • 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

  • Purpose Purpose of the test case
  • Executed Steps List of steps that the QA has to
    follow while executes the test case while
  • 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//

Thanks You Let us know if you
have any Question!