3.

Test Cases and Test Plan

3.0 Introduction
• Test Plan is a detailed document that describes the test strategy,
objectives, schedule, estimation, deliverables, and resources
required to perform testing for a software product.
• Test Plan helps us to determine the effort needed to validate the
quality of the application under test.
• The test plan serves as a blueprint to conduct software testing
activities as a defined process, which is minutely monitored and
controlled by the test manager.
• Definition: “Test Plan is a document describing the scope,
approach, resources, and schedule of intended test activities.”
Types of Test Plan
• Level-specific test plans – unit, integration, system, and acceptance
test plans.
• Type-specific test plans – functional test plan, performance test plan,
usability test plan, automation test plan, etc.
• Master Test Plan – a comprehensive QA Test Plan. It features high-
level information, structures,the testing process in detail, and rarely
undergoes changes or revisions.
What is the Importance of Test Plan?

• Making Test Plan document has multiple benefits

• Help people outside the test team such as developers, business
managers, customers understand the details of testing.
• Test Plan guides our thinking. It is like a rule book, which needs to
be followed.
• Important aspects like test estimation, test scope, Test
Strategy are documented in Test Plan, so it can be reviewed by
Management Team and re-used for other projects.
3.1.1 How to write a Test Plan

• Follow the eight steps below to create a test plan as per IEEE 829
1.Analyze the product
2.Design the Test Strategy
3.Define the Test Objectives
4.Define Test Criteria
5.Resource Planning
6.Plan Test Environment
7.Schedule & Estimation
8.Determine Test Deliverables
• 1. Research and analyze the software
• Before you create a test plan, take some time to study the software and research the type
of people most likely to use it. This can reveal how the end user plans to interact with the
product, which may help you determine the functionalities the team needs to test. It's also
helpful to consider the client's expectations and requirements for the end product so that
you can include those specifications in the test plan.
• The product under test is banking website. You should research clients and the end users
to know their needs and expectations from the application
• Who will use the website?
• For what it is used for?
• How will it work?
• What are software/ hardware the product uses?
• You can use the following approach to analyze the site
•
• You should take a look around this website and also review product
documentation.
• Review of product documentation helps you to understand all the features
of the website as well as how to use it. If you are unclear on any items, you
might interview customer, developer, designer to get more information.
• 2) Develop Test Strategy
• A test strategy details the testing objectives, ways to achieve those goals
and the overall cost associated with testing.
• In this step, it's helpful to identify which type of testing suits the product
or feature your team plans to assess .
• There are many types of testing in software development, including unit,
system and Agile testing methods.
• While each type of test assesses different components of the software,
they all seek to identify and address programming issues before the
software reaches the end user.
• Test Strategy is a critical step in making a Test Plan in Software
Testing. A Test Strategy document, is a high-level document, which
is usually developed by Test Manager. This document defines:
• The project’s testing objectives and the means to achieve them
• Determines testing effort and costs.
• Before the start of any test activity, scope of the testing should be
known. You must think hard about it.
• The components of the system to be tested (hardware, software,
middleware, etc.) are defined as “in scope“
• The components of the system that will not be tested also need to
be clearly defined as being “out of scope.”
• Give everyone a confidence & accurate information of the testing
you are doing
• All project members will have a clear understanding about what is
tested and what is not
• Type of Testing: Describes the types of tests to be used in the project.
This is necessary since each test identifies specific types of bugs.
• Risks and Issues: Describes all possible risks that may occur during
testing -right deadlines, insufficient management, inadequate or
erroneous budget estimate-as well as the effect of these risks on the
product or business.
• Test Logistics: Mentions the names of testers (or their skills) as well as
the tests to be run by them. This section also includes the schedule
laid out for testing and required tools.
3. Defining Objectives
• In this step, we define the goals and expected results of test
execution. Test objective is the overall goal and achievement of the
test execution.
• The objects must include:
✓ A list of all software features - functionality, GUI, performance
standards- that must be tested.
✓ The ideal result or benchmark for every aspect of the software
that needs testing. This is the standard to which all actual results will
be compared with the expected results.
4. Establish Test Criteria
• Test criteria denote to standards or rules governing all activities in a testing
project. The two main test criteria are:
➢ Suspension Criteria: Defines the benchmarks for suspending all tests.
For example, if QA team members find that 50% of all test cases have
failed, then all testing is suspended until the developers resolve all of the
bugs that have been identified so far.
➢ Exit Criteria: Defines the benchmarks that signify the successful
completion of a test phase or project. The exit criteria are the expected
results of tests and must be met before moving on to the next stage of
development. For example, 80% of all test cases must be marked successful
before a particular feature or portion of the software can be considered
suitable for public use.
5. Planning Resource Allocation
• Resource planning includes all types of resources required to
complete project.
• This step creates a detailed breakdown of all required resources for
project completion.
• Resources include human effort, equipment, and all infrastructures
required for accurate and comprehensive testing.
• This also helps test managers to formulate a correctly calculated
schedule and estimation for the project.
6. Planning Setup of Test Environment
• This step refers to software and hardware setup on which software
testing team run their tests.
• Ideally, test environments should be real devices so that testers can
monitor software behavior in real user conditions.
• Whether it is manual testing or automation testing, nothing beats real
devices, installed with real browsers and operating systems.
7. Determining Test Schedule and Estimation
• Break down the project into smaller tasks and allocate time and effort
required for each activity. Then, prepare a schedule to complete
these tasks in the designated time with the specific amount of effort.
Creating the schedule, however, does require input from multiple
perspectives:
• Employee availability, number of working days, project deadlines,
daily resource availability.
• Risks associated with the project which has been evaluated in an
earlier stage
8. Establish Test Deliverables
• Test deliverables imply a list of documents, tools and other equipment that
must be created, provided, and maintained to support testing activities in a
project.
• A different set of deliverables is required before, during and after testing.
These deliverables are given below:
• Deliverables required before testing include Test Plan and Test Design.
• Deliverables required during testing include Test Scripts, Simulators or
Emulators in early stages), Test Data, Error and execution logs.
• Deliverables required after testing include Test Results, Defect Reports and
Release Notes
3.1.2 Test Plan Template
• Test Plan Template is a detailed document that describes the test
strategy, objectives, schedule, estimation and deliverables, and
resources required for testing.
• Test Plan helps us to determine the effort needed to validate the
quality of the application under test.
• The test plan serves as a blueprint to conduct software testing
activities as a defined process which is minutely monitored and
controlled by the test manager.
• Creating a Test Plan is mandatory to ensure success of your
Software testing project
3.1.2 Test Plan Template
• Test plan format/template has following fields
• 1. Test Plan Identifier: Uniquely identifies the test plan and may
include version/release number of the document.
• 2. Introduction: A brief introduction about the project and to the
document.
• 3. Purpose: It defines the purpose of the test plan.
• 4. Objectives and Tasks: Objectives describes the objectives of test
plan like goal of project, resource factors, project scheduling
constraints, quality and cost factors. Tasks lists all tasks identified by
the test plan like problem reporting, post-testing etc.
• 5. Scope: It defines the features, functional or non-functional
requirements of software that will be tested.
• 6. Testing Strategy: It describes overall approach to testing.
• 7. Test Items: A test item is a software item that is the application
under test.
• 8. Software Risk Issues: Software project risks and assumptions.
• 9. Features to be tested: A feature that needs to tested on the test
ware.
• 10. Features not to be tested: Identify the features and the reasons
for not includes as part of testing.
• 16. Environmental Needs: Defining the environmental requirements such a
hardware, software, OS, network configurations, tools required.
• 17. Staffing and Training Needs: Captures the actual staffing requirements
and any specific skills and training requirements.
• 18. Responsibilities: Lists the roles and responsibilities of the team
members.
• 19. Schedule: States the important project delivery dates and key
milestones.
• 20. Planning Risks and Contingencies: Planning for risks and contingencies.
• 21. Approvals: Captures all approvers of the document, their titles and the
sign off date. All the individuals and parties directly and indirectly
associated with the testing process give their agreements in the form of
signed approvals.
• 22. Glossary: Summary or definitions that are used in testing.
Writing Test Cases
• A test case refers to the sequence of actions required to verify a
specific feature or functionalities.
Objective of Writing Test Cases:
• 1. To validate specific features and functions of the software.
• 2. To guide testers through their day-to-day hands-on activity.
• 3. To provide a blueprint for future projects.
• 4. To help detect usability issues and design gaps early on.
The steps for writing test cases
• Step 1: Review the Requirements
• Step 2: Write a Test Plan: A software test plan is a document that describes the
objectives, scope, approach and focus of a software testing effort.
• Step 3: Identify the Test Suite: A test suite, is known as a validation suite, is a collection
of test cases that are intended to be used as input to a software program to show that it
has some specified set of behaviors. Test suites are used to group similar test cases
together.
• Step 4: Name the Test Cases: A name of each test case should be a short phrase
describing a general test situation. Use distinct test cases when different steps will be
needed to test each situation.
• Step 5: Write Test Case Descriptions and Objectives: For each test case, write one or
two sentences describing its purpose and objectives
• Step 6: Create the Test Cases: Next step is to write the test case steps and specify test
data.
• Step 7: Review the Test Cases: The main reason of the reviewing test cases is to increase
test coverage and therefore software product quality
Test Cases for ATM

• Given below are the various test cases for ATM.

• 1) Verify if the card reader is working correctly. A screen should
ask you to insert the pin after inserting the valid card.
• 2) Verify if the cash dispenser is working as expected.
• 3) Verify if the receipt printer is working correctly. Which means it
can print the data on the paper and the paper comes out properly.
• 4) Verify if the Screen buttons are working correctly. For touch
screen: Verify if it is operational and working as per the
expectations.
• 5) Verify if the text on the screen button is visible clearly.
• 6) Verify the font of the text on the screen buttons.
• 7) Verify each number button on the Keypad.
• 8) Verify the functionality of the Cancel button on the Keypad.
• 9) Verify the text color of the keypad buttons. The numbers should be visible
clearly.
• 10) Verify the text color and font of the data on the screen. The user should be
able to read it clearly.
• 11) Verify the language selection option. If the messages or data are displayed in
the selected language.
• 12) Insert the card, the correct pin, and print the receipt for available balance.
• 13) Verify the receipt printing functionality after a valid transaction. Whether
the printed data is correct or not.
• 14) Verify how much time the system takes to log out.
• 15) Verify the timeout session functionality.
• 16) Verify the deposit slot functionality depending on its capability (Cash or
cheque or both) by inserting a valid cheque.
• 17) Verify using different cards (Cards of different banks).
•
• Verifying the Message
• 18) Insert the card and an incorrect PIN to verify the
message.
• 19) Verify the message when there is no cash in the ATM.
• 20) Verify the messages after a transaction.
• 21) Verify if a user will get a correct message if a card is
inserted incorrectly.
• Cash Withdrawal
• 22) Verify the cash withdrawal functionality by inserting
some valid amount.
• 23) Verify if a user can perform only one cash withdrawal
transaction per PIN insert.
• 24) Verify the different combinations of operation and
check if there will be a power loss in the middle of the
operation.
• Negative Test cases(They are designed to ensure that the system
behaves as expected when given invalid or unexpected inputs.)
• 25) Verify the functionality by entering a wrong pin number for 3 or
more times.
• 26) Verify the card reader functionality by inserting an expired card.
• 27) Verify the deposit slot functionality by inserting an invalid cheque.
• 28) Verify the cash withdrawal functionality by inserting invalid numbers
like 10, 20, 50 etc.
• 29) Verify the cash withdrawal functionality by entering an amount
greater than the per day limit,
• 30) Verify the cash withdrawal functionality by entering an amount
greater than per transaction limit.
• 31) Verify the cash withdrawal functionality by entering an amount
greater than the available balance in the account.
• Conclusion
• ATM machines must be tested for accuracy, reliability,
and performance. It should get tested for its response
time per transaction as it works for 24*7.
• All the above-mentioned points should be considered
while testing ATM machines. There should be a
combination of both positive and negative test cases
while writing test cases for any product.
3.3 Prepare Test Report for Test Cases
Executed
• Test Report is a document which contains a summary of all test
activities and final test results of a testing project.
• Test report is an assessment of how well the Testing is performed.
• Based on the test report, stakeholders can evaluate the quality of
the tested product and make a decision on the software release.
• For example, if the test report informs that there are many defects
remaining in the product, stakeholders can delay the release until
all the defects are fixed.
Test Report Template
Example
3.3.1 Test Incident Report
• Test Incident Report is mainly generated during the software
testing stage and it records all the defects, bugs, and any
other discrepancies found by the testers while testing the
software.
• Apart from reporting the defects in the software, the
document also identifies and defines various invents and
incidents in the software, which prevent them from getting
expected results.
 4. Metrix
3. Investigation 5. Disposition
• The Incident Summary Report Identifier uses the organization's incident
tracking numbering scheme to identify this incident and its corresponding
report.
• The Incident Summary is the information that relates the incident back to
the procedure or test case that discovered it.
• The Author of the incident report should include enough information so
that the readers of the report will be able to understand and replicate the
incident.
• Sometimes, the test case reference alone will be sufficient, but in other
instances, information about the setup, environment, and other variables is
useful.
• Inputs : Describes the inputs actually used (e.g., files, keystrokes, etc.).
• Expected Results : Comes from the test case that was running when the
incident was discovered
• Actual Results : Actual results are recorded here.
• Anomalies : How the actual results differ from the expected results.
• Date and Time : The date and time of the occurrence of the incident.
• Procedure Step : The step in which the incident occurred.
• Environment : The environment that was used (e.g., system test
environment acceptance test environment etc.).
• Attempts to Repeat : How many attempts were made to repeat the test?
• Testers : Who ran the test?
• Observers : Who else has knowledge of the situation?
• The Impact of the incident report form refers to the potential impact on
the user, the users or their representative should ultimately decide the
impact of the incident. The impact will also be one of the prime
determinants in the prioritization of bug fixes, although the resources
required to fix each bug will also have an effect on the prioritization.
• The Investigation of the incident report explains who found the incident
and who the key players are in its resolution. Some people also collect
some metrics here on the estimated amount of time required to isolate the
bug.
• The Metrics could be number of incidents, average time to resolve, or
average time between incidents.
• The Disposition (Status) shows the current status of all incidents with log
of incidents. In a good defect tracking system, there should be the
capability to maintain a log or audit trail of the incident as it goes through
the analysis, debugging correction, re-testing and implementation process.
3.3.2 Test Summary Report
• Test summary report summarizes the completion of the respective
test activities and deliverables.
• At the completion of a test cycle, a test summary report is produced
or developed .
• Purpose of the test summary report is to summarize the results of the
testing activity and to provide an evaluation based on these results.
• The summary report provides advice on the release readiness of the
product and should document any known anomalies or shortcomings
in the software product .
• IEEE Std. 829-1998 for Software Test Documentation Template for Test Summary
Report
Contents
• 1.Test Summary Report Identifier
• 2. Summary
• 3. Variances
• 4. Comprehensive Assessment
• 5. Summary of Results
• 5.1 Resolved Incidents
• 5.2 Unresolved Incidents
• 6. Evaluation
• 7. Recommendations
• 8. Summary of Activities
• 9. Approvals
• 1. Test Summary Report Identifier: It is a unique number that identifies the report and is
used to place the test summary report under configuration management.
• 2. Summary: It summarizes what testing activities took place, including the
versions/releases of the software, the environment and so forth. It also supply
references to the test plan, test-design specifications, test procedures and testcases.
• 3. Variances: It describes any variances between the testing that was planned and the
testing that really occurred.
• 4. Comprehensive Assessment: We should evaluate the comprehensiveness of the
testing process against the criteria specified in the test plan. These criteria are based
upon the inventory, requirements, design, code coverage or some combination thereof.
• 5. Summary of Results: It summarizes the results of testing here. Identify all resolved
incidents and summarize their resolution. It identify all unresolved incidents and also will
be contain metrics about defects .
• 6. Evaluation: It provides an overall evaluation of each test item, including its limitations.
This evaluation should be based upon the test results and the item pass/fail criteria.
• 7. Recommendations: It is test manager's job to make recommendations
based on what they discover during the testing.
• 8. Summary of Activities: They summarize the major testing activities and
events Summarize resource consumption data; for example, total staffing
level, total machine time, and elapsed time used for each of the major
testing activities Summary of activities is important to the test manager,
because the data recorded here is part of the information required for
estimating future testing efforts.
• 9. Approvals: They specify the names and titles of all persons who must
approve this report. Provide space for the signatures and dates. Ideally, we
would like the approvers of this report to be the same people who
approved the corresponding test plan, since the test summary report
summarizes all of the activities outlined in the plan. By signing this
document, the approvers are certifying that they concur with the results as
stated in the report, and that the report, as written, represents a
consensus of all of the approvers.