Introduction

Manual Day 1
 Company Types
Service Based[Third party]
– TCS
– CTS
– Maveric
– Hexaware,Accenture,indium
• Product Based----->[Client and team members direct]
– Google
– Flipkart
– Paypal
– Microsoft
– Amazon
 Product Based Company

Client Direct Employees

Eg:Pepsi
 Service Based Company

Requirement Request,
Client CTS cost Employees
(Pepsi) TCS
Quotation,
Duration Work ,Time
 Employees
• Permanent
• Vendor
Working Employee
• Contractor from other
company
• Third Party 1.Pacific
2.Crown
• Payroll
 Direct and Payroll

Vendor CTS
Contractor TCS
1.Pacific
Third 2.Crown
Party Permanent
Payroll
 Application Development
Devolpment:
-Web Application/UI--->Web Developer
-Mobile Application-->Mobile Developer

Developer:
-Front end Developer
-Backend Developer
-API Developer
-Database Developer
 UI
UI Front End DB Back End
PVR
Book my
Java
show
API Cinemas
Phython DB
DB
Angular js
Node js
React Js Oracle
Php SQL
.net
NoSQL
Book My show Ticket new API MangoDB
DB
 Testing
Types:
1.UI Testing--->Auto/Manual(Core Java & Selenium)
2.Mobile Testing--->Auto/Manual(Java & appium)
3.API Testing--->Auto/Manual(Java & Rest Assured)
4.Performance Testing-->Tools(Jmeter)
5. (ETL –Extract Transform Load Testing)DB Testing-->Tools
 IT
• Technical Team
– DeveloperDevelope
– TesterTesting
• Non-Technical Team
– Networking
– Support
– IT Team- We need to raise a request.1 ticket
– BA-Business Analyst(Application Knowledge)
– Product Specialist
 Domain
• Types:
– Banking
– Insurance
– Health care
– E commerce
– Travel
– E learning
SDLC Stages Software Development Life
Cycle
Requirement

Design

Development

Testing

Release

Maintanance
 SDLC Types
• Waterfall methodology
– Small scale Project
– When the client freezes the requirement
– Disadvantages:
• Less Flexible for changes
• Agile methodology
 Day 2

Manual Testing
 Types of Testing
• White box Testing-->Developer
– Code Level Check
• Black Box Testing-->Tester
– Functionality check
– Without having the code knowledge.
• Functional
– Actions done
• Non-Functional
– Performance Testing-->Tools(Jmeter)
– Load
– Volume
Non Functional Testing
Functional testing
 Releases
• Release Period:
– Version 1.0 Eg : First 6month[Home
page,Courses ,Equity form , Online Classes book]
– Version 2.0 Eg: Second 6month [Staff Attendance,
Salary, Student details and Fees]
 White Box Testing
White Box Testing:
• Developers:
– Unit Testing
• Small units like login, modules
– Integration Testing
• Collection of Small Units
 Black Box Testing
Tester:
• System Testing
• UAT (User Acceptance Testing)
 Environment
• Development—https:www.flipkartdev.com/
New Build

• Testinghttps:www.flipkarttest.com/
• https:www.flipkartqa.com/

– To check the developer developed the application as per the client

requirement.
• UAThttps://www.flipkartuat.com/
10000(BA,Support,testing)End user
• ProductionLivehttps://www.flipkart.com/->10
Lakh
• Smoke-New build early stageday 0 testing
• SanityMain functionality
• RegressionAll functionality
 Testing Techniques
• Boundary Value analysis
• Equivalence Partitioning
• Decision Table
• State Transition
• Error Guessing
 Boundary Value Analysis & Equivalent
Partitioning
• Eg: 1 Lakh details Verification
• 1 – 10000 (1,2,3 -9999,10000,10001)6
5000(4999,5000,5001)3
• 10003-20000 (10002,10003,10004 -
19999,20000,20001)65000

• 20002-30000
• 90002-100000
• Boundary-60
• Equivalent3+3
 Decision Table
• Login Functionality
– Valid Username and Valid Password
– Invalid username and Valid Password Error
message
– Valid User name and Invalid password
State Transition and Error guessing
• User Pin Number
– Valid-1234
– Invalid-2356Repeat (State will change from
incorrect to Try after sometime)
 7 Principles of Testing
• Testing shows Presence of defect
• Early Testing reduces cost and time
• Defect clustering(Small Module Contain large
number of Bugs)
• Pesticide paradox
• Exhaustive testing is impossible
• Testing is context dependent
• Absence of error is fallacy
 Day 3

Software Testing life Cycle

STLC- Software Testing Life Cycle
Requirement Analysis

Test Planning

Test case Development

Environment

Test Execution

Test closure
 Roles and Responsibilities
• Application Understanding-KT session(Knowledge Transfer)10
days-1Month
• Test PlaningTL
• Prepare Testcase , Test steps , Testdata [Test design Template]
• Test Execution[UAT or Testing/QA]
• Track the Defects and Retesting
• Test ClosureSign off
• Git code MaintenanceSource code management or version
control tool
• Participate meetings & Sharing valuable Thoughts
• Checking mail
• Prioritize work
 Test Design Template
• Requirement
– 1.1 Login
– 1.2 Home
– 1.3 Product
– 1.4 Payment
1.4.1 online payment
• 1.4.2 Credit cards
• 1.4.3 Cash on delivery
– 1.5 Services
 Scenario
• Scenario:
– Is used to perform test flow or combination of
tests.
Eg: Booking Ticket
1.Login page
2.Search theatre and movie
3.Select Seat and Payments
4.Seat confirmed message
– Peer review[Need to verify test case with TL and
teammates]
 Test Scenario Template
• Requirement ID
• Test Scenario Description
• Test Case
Req.no
Testcase_ID
Module
Testcase
Pre-conditions
Testcase Description
Test Steps
Test data
Expected Result
Actual Result
Pass/Fail
• Normal test case
• Technical testcase
• 200 testcase [Tech and normal]
• Per day count[4-8 Testcases][2,1-2days]
• Impacted Modules
 Test Case
• Test Case ID-TC-1001-Verify User able to login with valid
credentials.
Testcase description-User able to login by username and password.
Pre requisite-,URL,Credentials
Testdata->Url,username and password
Test steps- Launch the application in chrome
Click on sign In button
Enter username and Password
Click on login button
Expected result:User should able to login to login page
Actual result:not able to login Test case fail
Day 4

JIRA
• Atlassian:
– JIRA
– Confluence
• POC Possible of Contact
• Task assign
• Word Document
– Table
– Resource
– Module
– Target
– Status
– Tracking

– Time sheet
 JIRA
• Defect tracking tool
– Epic
– Task
– Story

– Bug
• Project management tool
– Product Backlog
– Sprint Backlog
Bug Life Cycle
 Jira
• Project
• Issue Type
• Summary
• Description
• Priority
• Attachment
• Version
• Assignee
• Label
Priority and Severity
• Module:
ThemeElectronics
EpicLarge(Mobiles)
Storysmall(MI)
MIStory points
Day -5

Projects
 Types of Domain
• E commerce
• Travel
• E booking
• Insurance
• Banking
 Ecommerce
• Buy a Product
• Validate a Product
• Search a Product
• Filters
• Add to cart page
 Travel
• Search the availabilty route for travel
• Check vehicle available in that route and date
• Seat booking and validate
 E booking
• Shows going
• Seat availability
• Confirmation
• Seat booked or not
 Insurance
• Search insurance type
• Time period
• Self or Third party
• Claimable amount
Day - 6

Agile
 Agile
• To develop SDLC types
– Login-Release
– Home-Release 2Client suggestion
– Product--Release 3 (Home changes)
– Services
 Agile methodology types
• Scrum
• Kanban
• Crystal
 Scrum
• Intermediate person-BA
– BA[Business Analyst]Scrum master
– Product owner
– Scrum members  Developers , Testers
– Scrum
• 1Sprint- 2 weeks(2 Sprint1 month)
• 1 Year24 Sprint(72)67 th sprint
• 1month80k5lakh
 Time Sheet DSR(Daily Status Report)
• 1Day 8hours + 1 hour (Lunch or tea)
• Access will be denied (If we forget to fill time
sheet)
• Per hour Time sheet
• I will be ooo[Out Of Office] today.
• DSRDaily Status Report
 Agile meetings
• Sprint planning
• Daily scrum meeting
• Sprint review
• Sprint Retrospective
 Sprint Planning
• We will discuss what are the modules we going to
test
• Sizing the User stories based on the Fibonacci
series[1 2 3 5 8 13 21]
• Participants:
– Product Owner + Scrum Master + Scrum Members

Once planning done Stories moved from Product Backlog

– Sprint Backlog and will be assigned to Scrum
Members by Scrum Masters.
 Daily Scrum call or Daily Standup call
• Discussing about the task we have completed
so far
• Discussing about what task is planned to do
today
• Discussing about the Bugs Raised
• Any issues faced while doing testing[Server
down, VPN issues, No access][10-30mins]
 Sprint Review
• We will give demo to the customer about
what we have done so far.
• If any changes needed by customer we will
change and modify.
• Participants:
– Product Owner + Scrum Master + Scrum Members
 Sprint Retrospective
• We will be discussing what when well and
What not went well.
• What are challenges you have faced while
testing.
• What solutions can be found to achieve this.
• Sprint ->2 weeks 3 weeks
 Day to Day Activities
• Login
• Check Email(Bug fixed waiting for Retesting)
• Daily Standup call
• Git Pull(latest code)
• Current task
• Defect tracking and retesting
• Meetings(Release and KT session)
• Git code maintanence(Push)
• Send the DSR(Daily Status Report)Mail
• Sign out
 Flowchart

Scrum master
Daily
Scrum
Product Team 24 hrs
Owner member
Sprint
1-4
Weeks
Product Sprint Sprint
Backlog Planning Backlog Finished
Work

Sprint review and retrospective