In depth Guide for Manual Testing

1
In depth Guide for Manual Testing
2
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.

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

4

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

5

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

6

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

7

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

8

• Lets check out the mastermind using which the
  manual testing is executed

9
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
  validation.

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

11
Steps for Writing Test Cases

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

12

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

13

• 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

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

15
Sample of a QA matrix
16

• Defect Life Cycle

17

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

18

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

19

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

20

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

21

• Original Source
• http//www.azilen.com/blog/guide-for-manual-testin
  g/

22
Thanks You www.azilen.com Let us know if you
have any Question! info_at_azilen.com
1-972-325-2243