0% found this document useful (0 votes)
30 views114 pages

Manual Testing Preparation 1.0

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
30 views114 pages

Manual Testing Preparation 1.0

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 114

Manual

Testing
Preparation
By Suresh Thirumalai
Index
SN Slide
O Topic Number
1 SDLC 99
2 STLC 100
3 Manual Testing 110
4 Agile 137
5 JIRA 160
6 Interview Questions 163

Sensitivity: Internal & Restricted


16. SDLC
Software Development Life Cycle

Sensitivity: Internal & Restricted


17. STLC
Software Testing Life Cycle

Sensitivity: Internal & Restricted


Phase 1:
Requirement
Analysis

Test Team studies the requirements to identify the testable
requirements
 QA team interact with Client, BA, Tech Leads, System
architects
 To understand the requirements in detail

 Deliverables
RTM
Automation Feasibility Report

Sensitivity: Internal & Restricted


Requirements Traceability Matrix
(RTM)
 It is a document that maps and traces the user requirement with test
cases.

 It is used to track the requirements and to check the current project


requirements are met

Sensitivity: Internal & Restricted


Advantage of RTM
 It confirms 100% test coverage

 It highlights any requirements missing or document inconsistencies

 It shows the overall defects or execution status with a focus on


business requirements

 It helps in analyzing or estimating the impact on the QA team's work


with respect to revisiting or re-working on the test cases

Sensitivity: Internal & Restricted


Business Requirement Document
(BRD)

Sensitivity: Internal & Restricted


Technical Requirement Document
(TRD)

Sensitivity: Internal & Restricted


RTM

RTM Table

Sensitivity: Internal & Restricted


Types:

 Forward Traceability
 Backward Traceability

Sensitivity: Internal & Restricted


Phase 2:
Test
Planning 
Senior QA Manager determines Effort & Cost estimates
 Preparation of Test Plan Document for various types of
testing
 Tool selection
 Resource planning and determining R&R
 Training Requirements

 Deliverables:
Test Plan Document
Effort Estimation Document

Sensitivity: Internal & Restricted


Test Plan Document

 Test Plan is a document describing the

scope,

approach,

resources, and

schedule of planned test activities.

 it deals with test coverage, features to be tested, features not to


be tested, estimation, scheduling and resource management.

Sensitivity: Internal & Restricted


Create Test Plan Document
Follow the below steps below to create a test plan.

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

Sensitivity: Internal & Restricted


Sensitivity: Internal & Restricted
Phase 3:
Test Case
Development
Create test Cases, Automation Scripts
 Review and Verify test cases & test scripts
 Create Test Data

 Deliverables
Test Cases/Scripts
Test Data

Sensitivity: Internal & Restricted


Phase 4:
Environment Setup
 Understand required architecture, environment set-up
 Prepare H/W , S/W requirement list
 Setup Test Environment and test data
 Perform Smoke Test on the build to do a readiness check
of the given environment

 Deliverables
Environment Ready with Test Data Setup
Smoke Test Results

Sensitivity: Internal & Restricted


Phase 5:
Test Execution
 Execute tests as per Plan
 Document test results and log defects for failed cases
 Bugs will be reported to dev team for correction
 Retest the Defect fixes
 Track the defects to closure

 Deliverables
Test Cases – Updated
Result
Defect Reports

Sensitivity: Internal & Restricted


Phase 6:
Test Cycle Closure
 Prepare Test closure report
 Evaluate cycle completion criteria
 Prepare test metrices.
 Test Result analysis

 Deliverables
Test Closure Report

Sensitivity: Internal & Restricted


Bug
Report

Sensitivity: Internal & Restricted


Test Summary Report: Testing Metrics

Sensitivity: Internal & Restricted


Test Strategy

 A strategy plan for defining the testing approach, what you want to
accomplish and how you are going to achieve it.

 Writing a Test Strategy effectively is a skill every tester should


achieve in their career. It initiates your thought process which helps
to discover many missing requirements. Thinking and test planning
activities help a team to define the Testing scope and Test coverage.
 It helps Test managers to get the clear state of the project at any
point. The chances of missing any test activity are very low when
there is a proper test strategy in place.

Sensitivity: Internal & Restricted


Feasibility Study

 Feasibility Study:
Feasibility study explores system requirements to determine project
feasibility. There are several fields of feasibility study including
economic feasibility, operational feasibility, technical feasibility. The
goal is to determine whether the system can be implemented or not.
The process of feasibility study takes as input the requirement details
as specified by the user and other domain-specific details. The output
of this process simply tells whether the project should be undertaken
or not and if yes, what would the constraints be. Additionally, all the
risks and their potential effects on the projects are also evaluated
before a decision to start the project is taken.

Sensitivity: Internal & Restricted


Types of feasibility Study

Sensitivity: Internal & Restricted


Story Point Estimations

 Story point Estimations are done in Agile projects using different


techniques like
 Planning Poker,
 Bucket System,
 Affinity Mapping,
 T-Shirt Sizes (sizes: XS (Extra Small), S (Small), M (Medium), L
(Large), XL (Extra Large))
 Dot Voting

Sensitivity: Internal & Restricted


Important Questions in STLC

1. How to create RTM?

2. How to create Test Plan?

3. How to prepare Feasibility Report?

4. How to estimate Effort?

5. What is Test Strategy?

Sensitivity: Internal & Restricted


Software Testing
 The process, to evaluate the functionality of a software application.

 Activity to check whether the actual results match the expected


results and to ensure that the software system is defect/bug free

 It can be done manually or using automated tools

Sensitivity: Internal & Restricted


Types of Testing
(Manual/Automation)

Sensitivity: Internal & Restricted


1. Functional Testing
 Checks whether the application is providing all the functionalities that
were mentioned in the functional requirement of the application.

Sensitivity: Internal & Restricted


2. Non-Functional Testing
 To check non-functional aspects (performance, usability, reliability, etc) of a
software application.

 It is designed to test the readiness of a system as


per nonfunctional parameters which are never addressed by
functional testing
3. Maintenance

 Regression Test
Slide No: 182

Sensitivity: Internal & Restricted


18. Manual Testing
(Functional)
 It is a type of software testing where testers manually test cases
without using any automation tools.

 It is most primitive of all testing types and helps to find bugs in the
software system.

 Any new application must be manually tested before its testing can
be automated.

 Manual testing requires more effort but is necessary to check


automation feasibility.

Sensitivity: Internal & Restricted


Techniques in Manual testing

Sensitivity: Internal & Restricted


How to perform a Test:

 1. Read and understand the software project documentation / guides

 2. Draft Test cases that cover all the requirements mentioned in the
documentation

 3. Review the test cases with Team Lead, Client

 4. Execute the test cases

 5. Report Bugs

 6. After bugs fixed, execute failed test cases.

Sensitivity: Internal & Restricted


Software Testing Levels (Hierarchy)

Sensitivity: Internal & Restricted


1. Unit Testing

 Individual units or components of a software are tested

 It is done during the development of application by developers

 A unit may be an individual function, method, procedure, module, or


object

Tools

JUnit

NUnit

Sensitivity: Internal & Restricted


2. Integration Test

 Software modules are integrated logically and tested as a group

 It focuses mainly on the interfaces and flow of data/information


between the modules

Example:

 An application has 3 modules:

 Login Page, Mail box, Delete emails

Sensitivity: Internal & Restricted


3. System Testing
 It validates the complete and fully integrated software product

 Purpose is evaluate the end-to-end system specifications

Different Types of System Testing


Smoke Test,
Sanity Test,
Regression Test,
Black Box,
White Box,
User Acceptance Test,
Black Box Testing
 It is tested without looking
at the internal code structure,
implementation details and
knowledge of internal paths of the software.

 This type of testing is based entirely on


software requirements and
specifications.

Sensitivity: Internal & Restricted


White box testing
 Testing software’s internal structure, design, and coding.

 In this type of testing, the code is visible to the tester.

 It focuses primarily on verifying


the flow of inputs & outputs through the
application,
improving design and usability,
strengthening security.

Sensitivity: Internal & Restricted


Black Box Vs White Box

Sensitivity: Internal & Restricted


Grey box testing
 Gray-box testing is a combination of white-box testing and black-box
testing.

 Grey box testing is when the tester has a partial understanding of


the internal structure in the system under test.

 Grey box testing is a process for debugging software applications


by making an input through the front-end, and verifying the data on
the back-end

Sensitivity: Internal & Restricted


Smoke Testing

To confirm that the critical functionalities of the program

are working fine after software build

Sensitivity: Internal & Restricted


When Smoke Testing?
 "before" any detailed functional or regression tests are
executed on the software build.
 To decide if a build is stable enough to proceed with further
testing

 Why?
- If the build is imperfect/defective, further testing
would be waste of time and resources.
- To detect early major issues.

Sensitivity: Internal & Restricted


Sanity Testing?

To check the new functionality/bugs have been fixed.

Sensitivity: Internal & Restricted


Smoke vs Sanity

Smoke Test Sanity


Test

It is like General Health Check


Up It is like specialized health check
up

Sensitivity: Internal & Restricted


Ad-hoc Testing

 When a software testing performed without proper planning and


documentation, it is said to be Adhoc Testing. Such kind
of tests are executed only once unless we uncover the
defects. Adhoc Tests are done after formal testing is
performed on the application.

Sensitivity: Internal & Restricted


Regression Testing
 It is done to verify that a code change in the software

does not impact the existing functionality of the product.

 This is to make sure the product works fine with new

functionality, bug fixes or any change in the existing

feature.

 Previously executed test cases are re-executed in order

to verify the impact of change.

Sensitivity: Internal & Restricted


Regression

Sensitivity: Internal & Restricted


When Regression Testing?
 After the changes in requirements and code modified according to the
requirement

 After new feature added to the software

 After defect fixed

 After performance issue fixed

 After alterations to an application's hosting environment.

Sensitivity: Internal & Restricted


Selecting Test Cases for Regression Testing

1. Select test cases for Regression; there are recent code changes /functional changes

2. Select test cases that map to the business requirements

3. Select test cases for Regression testing in areas with frequent bugs/defects

4. Select test cases for Regression testing of the areas which are visible to the user

5. Select all integration test cases for Regression testing

6. Select all complex test cases for Regression testing

7. Select test cases based on priorities for Regression testing

8. Select test cases for Regression testing based on criticality and impact of bug fixes

9. Select a sample of successful and failed test cases for Regression testing

10. Functionalities which are more visible to the users

Sensitivity: Internal & Restricted


Regression check is covered under
two categories:

Sprint Level Regression


End to End Regression

1) Sprint Level Regression


 It is done mainly for the new functionality or the enhancement that is done in
the latest sprint. Test cases from the test suite are selected as per the newly
added functionality or the enhancement that is done.

2) End-to-End Regression
 End-to-End Regression includes all the test cases that are to be re-executed
to test the complete product end to end by covering all the core
functionalities of the Product.

Sensitivity: Internal & Restricted


Regression Testing Steps:

• Select the Tests for Regression.

• Choose the apt tool and automate the Regression Tests

• Verify applications with Checkpoints

• Manage Regression Tests/update when required

• Schedule the tests

• Integrate with the builds

• Analyze the results

Sensitivity: Internal & Restricted


UAT – User Acceptance
Testing
 Testing a software by the user or client
to determine whether it can be accepted
or not.

 This is the final testing performed


once the functional, system &
regression testing
are completed
After UAT…

Sensitivity: Internal & Restricted


Non-Functional Testing

Sensitivity: Internal & Restricted


TESTING Description Tools

Performance
To Verify Speed, response time, reliability
Test

How application behaves when multiple users


Load Test
access simultaneously

Stress Test To verify the stability and reliability

To analyse the system performance by


Volume Test
increasing the volume of data in DB

To check if the app will crash at any point of


Stability Test
time

Compatibility Software should be installable on all versions of


Test OS
 sdsd
How to write a Test Scenario?

 Test Scenario

 Test Case

 Test Step

 Actual Result

 Expected Result

 Status

 Comment

Sensitivity: Internal & Restricted


Test Scenario and Test cases
 Test Scenario:
It is one liner statement which tell us about what to test
Ex: Check Login functionality

 Test Case:
Test scenario consists of a detailed test procedure
Here Login Test Scenario has 4 test cases.

Ex: Check Using valid User Id and valid Password


Check Using Invalid User Id and valid Password
Check Using valid User Id and Invalid Password
Check Using Invalid User Id and Invalid Password

Sensitivity: Internal & Restricted


Test Scenario vs Test cases

 Test Scenario
" What to be tested“

 Test case
" How to be tested“

 Test Script:
Test scripts are used in
automated testing.
Sometimes, a set of instructions
(written in a human language), used in
manual testing.
Sensitivity: Internal & Restricted
Test
Scenario Test Case Test Test Step Expected Actual Commen
Case Test Case Status
Id Description Step Description Result Result t
Id
Test the login
functionality of
Checking login
Amazon application to Application Application
function using Launch the
TS001 TC001 make sure user is 1 launched launched Pass
valid Login and application
allowed to the site properly successfully
valid Username
using valid user name
and password
Username Username
and and
Navigate to
2 password password Pass
the login Page
fields are fields are
displayed displayed
Username
Enter valid field accepts Username

t
3 username in input value input Pass

ta n username field as valid accepted

r
username

p o Enter valid
Password

Im
field accepts Password
password in
4 input value input Pass
the password
as valid accepted
field
Password
Navigated to
Name of the
HomePage
user is
Click on Login and shows
5 displayed in Pass
Button name of the
Sensitivity: Internal & Restricted the
Negative Test case:

Sensitivity: Internal & Restricted


Verification vs Validation

 Verification:
The verifying process includes checking documents, design, code, and
program.
(Ex: Spelling mistake)

 Validation:
It is a dynamic mechanism of Software testing and validate the actual
Product.
(Ex: Actual meets Expected)

Sensitivity: Internal & Restricted


Entry Criteria :
 Test environment availability

 Test scope definition and finalization

 Types of testing defined & finalized

 Test cycles & schedule is planned & Signed off

 test resources available

 Software under test knowledge is available

 Stakeholders are identified and involved

 Code is deployed in test environment

 Test data is available in the test environment.

 Exit criterias are signed off Sensitivity: Internal & Restricted


Exit Criteria:
The following exit criteria should be considered for completion of a testing
phase:

 Ensuring all critical Test Cases are passed

 Achieving complete Functional Coverage.

 Identifying and fixing all the high-priority defects

 Deadlines meet or budget depleted.

 Desired and sufficient coverage of the requirements and functionalities under the test.

 All the identified defects are corrected and closed.

 No high priority or severity or critical bug has been left out.

 Testing de-scoped due to any reason.

 Sign-off received from all stakeholders


Sensitivity: Internal & Restricted
Testing can be stopped when: 1
Requirements:
 100% Requirements coverage is achieved.

Defects:
 Defined / Desired Defect count is reached.
 All Show Stopper defects or Blockers are fixed and No known Critical /
Severity 1 defect is in Open Status.
 All High Priority defects are identified and fixed.
 Defect Rate falls below defined acceptable rate.
 Very few Medium Priority defects are open and have a workaround in
place.
 Very few low priority open defects that do not impact software usage.
 All High Priority defects are re-tested and closed and corresponding
Regression scenarios are successfully executed.
Sensitivity: Internal & Restricted
Testing can be stopped when: 2
Test Coverage:
 Test Coverage should be 95% achieved.
 Test case Pass Rate should be 95%. This can be calculated by formula
 ( Total No of TCs Passed / Total number of TCs ) * 100.
 All critical Test cases are passed.
 5% Test cases can be failed but the Failed Test cases are of low
priority.
 Complete Functional Coverage is achieved.
 All major functional / business flows are executed successfully with
various inputs and are working fine.

Deadlines:
 Project Deadline or Test Finish deadline is reached.

Sensitivity: Internal & Restricted


Testing can be stopped when: 3
Test Documents:
 All Test Documents / deliverables (Example – Test Summary Report)
are prepared, reviewed and published across.

Budget:
 Complete Testing Budget is exhausted.

“Go / No Go” Meetings:


 “Go / No Go” meeting has been conducted with stakeholders and a
decision is made whether the project should go to production or not.

Sensitivity: Internal & Restricted


Sample Test Cases

1. OTP

2. ATM

3. Add to Cart

Sensitivity: Internal & Restricted


Scenarios to Test OTP (One-Time Password)

1) OTP should be generated within time period.


2) Limitations of number of OTP generation for single authentication.
3) It is received only on registered Mobile Number / E-mail Address.
4) Network delay for expiry of One-Time Password.
5) Verify that once expired, it should not be used for any authentication.
6) Verify that once used, it should not be allowed to use again.
7) Verify that resend OTP functionality is working properly.
8) Verify that once user resent the OTP, the old one should be of no use.
9) Availability of Help and Documentation Link for OTP usage.
10) Verify for Case Sensitiveness.
11) Check for types of characters OTP supports: Only Digits, Only Alphabets, Alphanumeric.
12) How many times user can provide invalid OTP?
13) After multiple invalid try, verify that system temporarily blocks the account.
14) Verify that after temporary blocking of account, system does not send the one-time password.
15) Provide an invalid Phone Number or E-Mail address and submit the OTP. Check the validation.
16) Are the one-time password patterns are predictable?

Sensitivity: Internal & Restricted


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.

Messages for each and every scenario should be verified.


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.

Sensitivity: Internal & Restricted


Negative Test cases
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.

Sensitivity: Internal & Restricted


E-commerce Websites: Shopping cart
 Add one item to the cart and verify.
 Increase the quantity of the item from the cart and verify.
 Add the same item multiple times and verify.
 Add multiple items of different types and verify.
 Remove some items from the cart and verify.
 Remove all items from the cart and then verify.
 Click on an item in the cart and verify that the user is redirected to the product detail page.
 Check that the price of the cart is discounted when we apply a valid coupon.
 Check that the price of the cart is not discounted when we apply an invalid coupon.
 Add item(s) to the cart, close the browser and reopen the same site.
 Add item(s) to the cart, close the browser and reopen the same site.
 Verify the product QTY field when the product is out of stock.
 Verify that the user is able to add a text note for all products.
 Verify that the user is able to add any or all products to his wishlist by clicking on the wishlist
link.
 Verify that the user is able to mark his order as a gift.
 Verify that the user is able to add any a gift message.
 Verify that the user is redirected to the checkout page after clicking on the checkout button.
 Verify the cart total when the exclusive tax is enabled from the admin end.
 Verify the cart total when the inclusive tax is enabled from the admin end.
Sensitivity: Internal & Restricted
Checkout flow
 Ensure that user can access the Checkout Page only after  Verify the error message for the invalid coupon.
adding the product to the cart.  Check that user is able to make his order as a gift.
 Ensure that Checkout Address Page consists of all the details of
 Ensure that the user is able to add any gift message.
the product such as Name, Quantity, Amount, etc.
  Check order price when gift and wrapping charges are
Ensure that only registered users are allowed to access the
Checkout Address Page. applicable.
  Check the shipping price.
Ensure that Name, Street Address, City, State, Country, Postal
code is the mandatory field in the Checkout Address page  Check the shipping price tax.
(Shipping Address).
 Check the payment options.
 Ensure that Name, Street Address, City, State, Country, Postal
code is the mandatory field in the Checkout Address page  Ensure that Name on Card, Card Number, Expiration date,
(Billing Address). CWW2 are mandatory fields in the Payment Page.
 Ensure that error message is displayed when the user enters  Ensure that error message is displayed when the user enters
invalid input in all the mandatory field in the checkout address invalid input in all the mandatory field on the Payment Page.
page.  Ensure that error message is displayed when the user leaves
 Ensure that Back to cart link is available so that user can modify any one of the mandatory fields in the Payment Page.
the cart content if needed.
 Ensure that the user is redirected to the third party (Vender)
 Ensure that user is redirected to Checkout payment page only page.
after entering valid mandatory details in the checkout Address
 Ensure that the user is redirected to the third party (PayPal)
page.
page if he is going to pay through a third party payment
 Ensure that error message is displayed when the user leaves gateway (PayPal).
any one of the mandatory fields in the checkout Address page.
 Place an order where order total price is Zero (0).
 Ensure that Next Button and Cancel Button are available in the
Checkout Address Page.  Place an order where the total discount is more than the
 entire order.
Check that a user is able to apply a valid coupon.
 Place an order by double clicking on the submit Button.
Modules for E-Commerce site

Sensitivity: Internal & Restricted


Test Cases

Sensitivity: Internal & Restricted


Skills required to become a Software
Tester

Sensitivity: Internal & Restricted


Software Tester Career Path

Sensitivity: Internal & Restricted


Software Methodologies

Waterfall Model

Sensitivity: Internal & Restricted


Agile Methodology

Sensitivity: Internal & Restricted


Agile – Scrum Methodology
19. Agile
 It is a practice that promotes continuous iteration of development
and testing throughout the software development lifecycle of project.

 Both Dev and testing activities are concurrent unlike Waterfall model.

Agile emphasizes on 4 core values:

 Individual and team interactions over processes and tools

 Working software over comprehensive documentation

 Customer collaboration over contract negotiation

 Responding to change over following a plan

Sensitivity: Internal & Restricted


Agile Waterfall

 Sequential from start to end point


 Incremental and iterative approach
 Not broken into individual
 It is broken into individual models
 Customer can only see the product at end of the
 Customer see the product frequently--can make project
the changes to the project  Whole product is tested in end.
 Error can be fixed in

middle of the project itself


If error is
 Regression testing is implemented in Every found, the project has to start from the beginning
Iteration as new functions or logic are released  Only after the development phase, the testing phase is
 Testers and developers work together executed

 Testers and developers work separately


 It requires close communication with developers
 Developers does not involve in requirement and
and tester together to analyse requirements
planning process. Usually, time delays between tests
and planning
Agile Waterfall
 At the end of every sprint, UAT is performed  At the end of the project only UAT is

 When an iteration end, Shippable features performed


of the product is delivered to the customer.  All features developed are delivered at
New features are usable right after once after the long implementation phase.
shipment
 Too planned and secured
It is useful when you have good
 All sorts of project can be estimated and
Contact with customers
completed
 Unstructured
 Documentation is a top priority and can
 Small projects can be implemented quickly.
even use for upgrade the software with
Large projects is difficult to estimate time
another team
 Documentation attends less priority than
software development
Scrum is an agile development
method
Sensitivity: Internal & Restricted
Scrum Framework

Sensitivity: Internal & Restricted


1. Roles

Sensitivity: Internal & Restricted


Role: 1
Scrum master

Responsibilities

 1. He setting up the team and look after the team’s productivity

 2. Invites to the daily scrum, sprint meetings

 3. Removing obstacles to progress

 4. Coordinates with all roles and functions

Sensitivity: Internal & Restricted


Role: 2
Product Owner

Responsibilities

 1. He defines features of the Product

 2. Creates product backlog

 3. Decides the release date and corresponding features

 4. Prioritizes the backlog (features) according to the market value

 5. Getting delivery of the functionality at each iteration from scrum


team
Sensitivity: Internal & Restricted
Role: 3
Scrum Team

Responsibilities

 1. Manages its own work

 2. Organizes the work to


complete the sprint or cycle
Sensitivity: Internal & Restricted
2. Artifacts

Sensitivity: Internal & Restricted


Sprint
 It is a set period of time to complete the user stories, decided by the
product owner and developer team, usually 2-4 weeks of time.

Sensitivity: Internal & Restricted


User stories
 They are short explanation of functionalities of the system under test

Sensitivity: Internal & Restricted


1. Product Backlog

 This is a repository where requirements are tracked with details on


the no of requirements (user stories) to be completed for each
release.

 It should be maintained and prioritized by Product Owner, and it


should be distributed to the scrum team.

Sensitivity: Internal & Restricted


2. Sprint backlog

 It is a set of user stories to be completed in a sprint

 During the sprint backlog, work is never assigned, and the team signs
up for work on their own.

 It is owned the estimated work remaining is updated daily.

 It is the list of task that has to be performed in sprint

Sensitivity: Internal & Restricted


3. Burndown chart

 A burndown chart is a graphic representation of how quickly the


team is working through a customer's user stories, an agile tool that
is used to capture a description of a feature from an end-user
perspective.

 The burndown chart shows the total effort against the amount of
work for each iteration

Sensitivity: Internal & Restricted


How to create Burndown chart

Sensitivity: Internal & Restricted


Process flow of scrum
 Each iteration of a scrum is known as Sprint

 Product backlog is a list where all details are entered to get end-
product

 During each sprint, top user stories of Product backlog are selected
and turned into sprint backlog

 Team works on the defined sprint backlog

 Team checks for the daily work

 At the end of the sprint, team delivers product functionality

Sensitivity: Internal & Restricted


3. Ceremonies

Sensitivity: Internal & Restricted


1. Sprint Planning Meeting
 Tester should pick a user story from product
backlog that should be tested

 Tester should decide how many hours (Effort


Estimation) it should take to finish testing for each
of selected user stories.

 As a tester, He/she must know what sprint goals


are.

 Tester should contribute to the prioritizing process

Sensitivity: Internal & Restricted


Sprint
 Support developers in unit testing

 Test execution is performed in a lab where both tester and developer work hand in hand.

 Defects are analysed during scrum meeting.

 Defects are retested as soon as it is resolved and deployed for testing

 Attend all daily standup meeting to speak up

 Schedule testing with CI system.

 Accomplish the automation test by utilizing various open source or paid tools available in the
market.

 Review CI automation results and send the Reports

 At the end of the sprint, the tester also does acceptance testing (UAT) in some case and
confirms testing completeness for the current sprint
2. Daily Scrum Meeting

Participants –

Client, (Product
owner)

Scrum Master,
(Lead)

Dev Team,

Automation Team

Functional Team
(Manual)

Sensitivity: Internal & Restricted


3. Sprint Review Meeting

 The sprint review is an informal meeting which


the development team, the scrum master, the
product owner and the stakeholders will attend.

 The team gives a demo on the product and will


determine what are finished and what aren’t.

 It is mandatory to deliver a potentially shippable


product increment at the end of every Sprint. So,
Sprint Review meeting is held at the end of
each Sprint.

Sensitivity: Internal & Restricted


4. Sprint Retrospective Meeting

 As a tester, He will figure out what went wrong


and what went right in current sprint

 As a tester, He identifies lesson learned and best


practices.

Sensitivity: Internal & Restricted


Sprint of our Project

 2 weeks of sprint

 1.5 years – 35 sprint

 Last Sprint 35

 Current Status:

 First Sprint?

POC

Sensitivity: Internal & Restricted


20. JIRA
Defect Tracking Tool
To create a issue,
1. Project : Name of the Project
2. Issue Type : Bug/Epic/Story/Task/Subtask/New
Feature
3. Summary : One line summary
4. Description : Details of the issue
5. Priority : High/Medium/Low/Lowest
6. Labels : Specific type of issue
7. Issue(Related To) : User can link the Issue ID to the linked
issue
8. Assignee : Who is responsible to fix this
issue.
9. Epic Link : If the issue belongs to any of
those Epic Link
10. Sprint : In which Sprint, this issue addressed
Sensitivity: Internal & Restricted
Defect Life Cycle

Sensitivity: Internal & Restricted


Priority vs
Severity

Severity:
How severe defect is
affecting the
functionality.

Priority:
How fast defect has
to be fixed
What is Deffered
 Deferred:
The bug, changed to deferred state means the bug is expected
to be fixed in next releases. ...

If the tester feels that the bug no longer exists in the software, tester
changes the status of the bug to “closed”.

 Low priority and low severity

Sensitivity: Internal & Restricted


You are

You might also like