Manual Testing
Session 8
[Link]
Test Plan Contents
▪ A Test Plan is a document that describes the test scope, test strategy, objectives, schedule, deliverables and
resources required to perform testing for a software product.
▪ Test plan template contents:
▪ Overview
▪ Scope
▪ Inclusions
▪ Test Environments
▪ Exclusions
▪ Test Strategy
▪ Defect Reporting Procedure
▪ Roles/Responsibilities
▪ Test Schedule
▪ Test Deliverables
▪ Pricing
▪ Entry and Exit Criteria
▪ Suspension and Resumption Criteria
▪ Tools
▪ Risks and Mitigations
▪ Approvals
[Link]
Use case, Test Scenario & Test Case
▪ Use Case:
– Use case describes the requirement.
– Use case contains THREE Items.
▪ Actor, which is the user, which can be a single person or a group of people, interacting with a
process.
▪ Action, which is to reach the final outcome
▪ Goal/Outcome, which is the successful user outcome.
▪ Test Scenario:
– A possible area to be tested (What to test)
▪ Test Case:
– Step by step actions to be performed to validate functionality of AUT (How to test).
– Test case contains test steps, expected result & actual result.
[Link]
Sample Use Case
[Link]
Use Case V/s Test Case
▪ Use Case – Describes functional requirement, prepared by Business
Analyst(BA).
▪ Test Case – Describes Test Steps/ Procedure, prepared by Test Engineer.
[Link]
Test Scenario V/s Test Case
▪ Test Scenario is ‘What to be tested’ and Test Case is ‘How to be tested’.
▪ Example:-
▪ Test Scenario: Checking the functionality of Login button
– TC1: Click the button without entering user name and password.
– TC2: Click the button only entering User name.
– TC3: Click the button while entering wrong user name and wrong password.
[Link]
Test Suite
▪ Test Suite is group of test cases which belongs to same category.
[Link]
What is Test case?
▪ A Test Case is a set of actions executed to validate particular feature or
functionality of your software application.
[Link]
Test Case Contents
▪ Test Case ID
▪ Test Case Title
▪ Description
▪ Pre-condition
▪ Priority ( P0, P1,P2,P3) – order
▪ Requirement ID
▪ Steps/Actions
▪ Expected Result
▪ Actual Result
▪ Test data
[Link]
Test Case Template
[Link]
Requirement Traceability Matrix(RTM)
▪ What is RTM (Requirement Traceability Matrix)?
▪ RTM describes the mapping of Requirement’s with the Test cases.
▪ The main purpose of RTM is to see that all test cases are covered so that no functionality
should miss while doing Software testing.
▪ Requirement Traceability Matrix – Parameters include
– Requirement ID
– Req Description
– Test case ID’s
[Link]
Sample RTM
[Link]
Test Environment
▪ Test Environment is a platform specially build for test case execution on the software product.
▪ It is created by integrating the required software and hardware along with proper network
configurations.
▪ Test environment simulates production/real time environment.
▪ Another name of test environment is Test Bed.
[Link]
Test Execution
▪ During this phase test team will carry out the testing based on the test plans and the test cases
prepared.
▪ Entry Criteria: Test cases , Test Data & Test Plan
▪ Activities:
– Test cases are executed based on the test planning.
– Status of test cases are marked, like Passed, Failed, Blocked, Run, and others.
– Documentation of test results and log defects for failed cases is done.
– All the blocked and failed test cases are assigned bug ids.
– Retesting once the defects are fixed.
– Defects are tracked till closure.
▪ Deliverables: Provides defect and test case execution report with completed results.
[Link]
Guidelines for Test Execution
– The Build being deployed to the QA environment is the most important part of
the test execution cycle.
– Test execution is done in Quality Assurance (QA) environment.
– Test execution happens in multiple cycles.
– Test execution phase consists Executing the test cases + test scripts( if
automation).
[Link]
Defects/Bugs
▪ Any mismatched functionality found in a application is called as
Defect/Bug/Issue.
▪ During Test Execution Test engineers are reporting mismatches as defects
to developers through templates or using tools.
▪ Defect Reporting Tools:
– Clear Quest
– DevTrack
– Jira
– Quality Center
– Bug Jilla etc.
[Link]
Defect Report Contents
▪ Defect_ID - Unique identification number for the defect.
▪ Defect Description - Detailed description of the defect including information about the module in which defect was found.
▪ Version - Version of the application in which defect was found.
▪ Steps - Detailed steps along with screenshots with which the developer can reproduce the defects.
▪ Date Raised - Date when the defect is raised
▪ Reference- where you Provide reference to the documents like . requirements, design, architecture or may be even
screenshots of the error to help understand the defect
▪ Detected By - Name/ID of the tester who raised the defect
▪ Status - Status of the defect , more on this later
▪ Fixed by - Name/ID of the developer who fixed it
▪ Date Closed - Date when the defect is closed
▪ Severity which describes the impact of the defect on the application
▪ Priority which is related to defect fixing urgency. Severity Priority could be High/Medium/Low based on the impact urgency at
which the defect should be fixed respectively
[Link]
Defect Classification
Defects Categorization
Severity Priority
Blocker P1
Critical P2
Major P3
Minor
[Link]
Defect Severity
▪ Severity describes the seriousness of defect and how much impact on Business workflow.
▪ Defect severity can be categorized into four class
– Blocker(Show stopper): This defect indicates nothing can proceed further.
▪ Ex: Application crashed, Login Not worked
– Critical : The main/basic functionality is not working. Customer business workflow is broken.
They cannot proceed further.
▪ Ex1: Fund transfer is not working in net banking
▪ Ex2: Ordering product in ecommerce application is not working.
– Major: It cause some undesirable behavior, but the feature/application is still functional.
▪ Ex1: After sending email there is no confirm message
▪ Ex2: After booking cab there is no confirmation.
– Minor: It won't cause any major break-down of the system
▪ Ex: Look and feel issues, spellings, alignments.
[Link]
Defect Priority
▪ Priority describes the importance of defect.
▪ Defect Priority states the order in which a defect should be fixed.
▪ Defect priority can be categorized into three class
– P0 (High) : The defect must be resolved immediately as it affects the system severely and
cannot be used until it is fixed.
– P1 (Medium): It can wait until a new versions/builds is created
– P2 (Low): Developer can fix it in later releases.
[Link]
High severity, priority and low severity, priority defects
Priority
High Low
High
Login is taking to the blank page. About Us link is going to blank page.
Severity
After user is logged into User opened contact page.
application, he can see Home Email ID has spelling mistake.
Low
Page. But there is spelling mistake
in Home Page.
[Link]
More examples…
▪ Low priority-Low severity - A spelling mistake in a page not frequently navigated by users.
▪ Low priority-High severity - Application crashing in some very corner case.
▪ High priority-Low severity - Slight change in logo color or spelling mistake in company name.
▪ High priority-High severity - Issue with login functionality.(user is not able to login to the
application)
▪ High Severity- Low Priority - Web page not found when user clicks on a link (user does not visit
that page generally)
▪ Low Priority- Low Severity - Any cosmetic or spelling issues which is within a paragraph or in the
page
[Link]
Defect Resolution
▪ After receiving the defect report from the testing team, development team conduct a review
meeting to fix defects. Then they send a Resolution Type to the testing team for further
communication.
▪ Resolution Types:-
– Accept
– Reject
– Duplicate
– Enhancement
– Need more information
– Not Reproducible
– Fixed
– As Designed
[Link]
