Software Testing-

Manual Testing-
1. Manual part 1-
 Different types of Process
A. SDLC – Software development life cycle
B. Waterfall module/ process
C. V-module / Process
D. Agile Module / Process (In 80 to 90% project) – Real / Practically – Scrum/
Kanaba/ Lean/ FDD/ XP, etc

 Different types of Testing-

A. Sanity & Smoke Testing
B. System & Functional Testing – 80% work
1. Functionality (BIEBSC) &
2. Non- Functionality (RCCIISPG)
C. Re-testing
D. Regression Testing
E. UAT Testing
F. Prod/ Live Testing
G. Approach based testing / Scenario based testing – Monkey Testing, Ad-hoc Testing,
exploratory testing, etc

2. Manual part 2 - Real work experience for a Tester

 Requirement understand
 Test cases design
 Test cases review
 Test cases execution
 Defect report/ raised
 Different report In Testing

Data Base testing (SQL languages)-

 Tool used -

API testing / Web service testing –

 API testing – manual part throw the Tool – Postman, SOAPUI tool

2 Live Bug tracking tool- Work Tacking

 JIRA tool – test cases design, Test cases review, defect, report
 Azure DevOps tool - test cases design, Test cases review, defect, report

https://vctcpune.com/ 1
2 projects –
 Different types testing in Project

Automation testing- (Web based application – Chrome browser)

 Basic Java
 Selenium tool
 Framework structure – Data driven
 GitHub
 Jenkins job – Deployment
 Extra/ New topics - API Automation - (BDD/ cucumber Framework + Rest-assured)

Extra Topics – Performance Testing/ Cypress Testing/ Mobile Testing/ BDD Framework

https://vctcpune.com/ 1
Manual Part 1-
Development
Client – HSBC Requirement Company –
bank, USA - TCS, Wipro, etc
Application Requirement (Wireframe) –
Deploy Project Testing

Lunch

Application-
End user/ HSBC
bank employees

 Software – soft (soft for change) + ware (product) = Software/ application

 Soft = Simple / Change according to requirement
 Ware = Product

 Software Testing – It is task to check/ verify that software developed that will be
correct / accuracy as per requirement. OR It is activity to check the functionality of
application/ software as per requirement OR It is process to find out/ check bug/ error/
issue present in the developed application.

 Company –
1. Service based company – Company will provide service to clients. Ex. TCS, Infosys, etc

https://vctcpune.com/ 1
 2. Product based company – Company will sell their product/ Company will have their
own produced and give/ sell to clients. Ex. PTC, PWC, etc

https://vctcpune.com/ 1
Project –
 2 types of team will in the project –
1. Project team – New requirement / functionality/ feature/ module add into application.
 Ex. Paytm – New feature / functionality/ module - pocket box used by delivery boy,
Auto driven, etc
 Ex. Groww – New feature - F&O, IPO, Intraday, Screener, etc

https://vctcpune.com/ 1
  Support team – Exiting functionality /application- issue / bug/ error/ end user quires/
Ticket raised – resolved and deployed.

 In my last project/ last organization, I have worked in Project team.

Project Team size – 15 peoples OR 24 peoples

https://vctcpune.com/ 1
  Client – Client will give requirement to build application/ software.
 Business analyst (BA) (1 people) – BA will always to communication with client.
Project related requirement need to collect and provide to these requirement to company
peoples (developer & tester).
 Delivery Manager (DM) – DM will check delivery process which we are providing to
client.
 Project Manager (PM) (1 people) – PM will assign work/ task allocation or to check
work has been done or not. PM is boss of project.
 Solution architecture / Designer (8 to 10+ year exp. Developer) (1 people) – Software
requirement / Business requirement against prepared Prototype/ Wireframe.
 Developer (3 to 5 exp.) (8 to 9 people) – Developer will do coding against the prototype/
Wireframe. Developer will do small part of development.
 Tester led (6 to 8 exp.) (1 people) – Tester work will assigned. Testing different report
will prepared.
 Tester (3 to 5 exp.) (2 to 3 people) – Tester will do the testing/ checking/ verification
against the software / application with respect to requirement.

Support Team size –

 Customer support Manager (PM) (1 people) – PM will assign the ticket, End user
quires, existing bug/ issue, etc.
 Developer (3 to 5 exp.) (3 to 4 people) – Developer will do coding against ticket, End
user quires, Bug/ Issue, etc.
 Tester (3 to 5 exp.) (1 to 2 people) – Tester will do the testing/ checking/ verification
functionality which fixed by the developer.

 In my Project, we have project team size – 14 to 15 people.

Different types of Process

 Process decided
1. If Client has not own IT department – Process decide by Company.
 Ex. Cred – Cred (TCS company will deiced process)
2. If Client has their own IT department – Process decide by Client.
 Ex. HSBC bank, Barclays bank, JP Morgan, NSDL, etc – TCD company not decided the
process

SDLC (Software development life cycle)-

 SDLC will consist of different stage
1. Information gathering (BRS)

https://vctcpune.com/ 1
 2. Analysis (SRS/ FRS)
3. Design (HDL)
4. Coding (LLD)
5. Testing (TCD, TCE)
6. Support

Information gathering-
 In Information gathering stage, BA will work.
 BA will communication with client and prepare a documents for business related
requirement.
 These businesses relate documents are called as BRS (business requirement
specification) documents.
 Ex. Client - business requirement – Create Platform (application) – end user used these
platform for bidding purpose – Cricket, Football, Rummy, etc – For the use of these
platform for Bidding against games then client will charge for platform used to end user
– Chagares = 10% total amount. – Application – Dream11, rummy, My11cricle, etc
 When BA will prepare the documents, then he will send to project team.

Analysis –
 In analysis stage, BA will work
 BA will against communicate with client and prepared a documents related to software/
application requirement.
 These software/ application relate documents are called as SRS (software/ system
requirement specification) documents
 SRS also called FRS ( functionality requirement specification)/ CRS (customer
requirement specification)
 Ex. SRS –
 Ex. Dream11- Requirement 1- Login page – Mobile No. / Email ID, Forgot button,
Create account, Error message, etc
 Ex. Dream11- Requirement 2- In 11 player, Max point elated, etc
 Ex. Dream11- Requirement 3- Payment different – Credit, debit, Wallet etc

 SRS will generated or provided by BA for respective functionality/ module

 Ex. Paytm – FastTag functionality/ module = SRS1,

Recharge module = SRS2,
Movies ticket module = SRS3, etc

https://vctcpune.com/ 1
  SRS will has 4 contains/part- (Module / Book- History)
a. Functional requirement (1 module = 10 requirement) (10 charter)
b. Functional flow diagram (1 requirement 2 requirement  3 requirement)
c. Use case – Use cases it is called as single specific requirement. (1 charter)
1. Description – Defines detail description about that single requirement
2. Acceptance criteria – Does & Don’t about that single requirement
d. Screenshot/ Snapshot/ Prototypes – Image/ Screenshot without any functionality

 After completion of These SRS documents, BA will sent these documents to the project
team, then project team will read or understand these documents.
 If we have doubt in SRS documents then developer & tester will arranger one meeting
with BA. These meting are called as grooming meeting.

Design-
 In design stage, Solution architecture / Designer will present.
 Designer will prepared HLD (high level design) & LLD (Low level design)
 Ex. Paytm – Recharge module – HDL – Functionality Mobile no. detail frame = GUI/ UI
(User interface)/ Frond End, API (Application program interface), DB(database), etc
 Ex. Paytm – Recharge module HDL = Mobile no. details frame, Browser plane enter
frame, Payment gateway  API service  DB (store produced, Function), etc
 Ex. Mobile no. detail frame  LLD = Mobile no. text 10 digits, operator drop done,
Circle drop down, Amount – Text box/ Selected box, etc

Coding-
 In coding stage, developer will work
 Developer will do the coding against the LLD (Designer will provide explain about
these LLD)
 Ex. LLD = Mobile no. detail frame  Mobile no. text 10 digits, Mobile 9 digits -error1,
Null/blank mobile no- error2, Mobile series (9, 8, 7, 6).
 Ex. Paytm – Recharge module HDL =
Mobile no. details frame- coding (logic) - Frond end developer,

https://vctcpune.com/ 1
 Browser plane enter frame – coding (logic) - API developer
Payment gateway - coding (logic) - API service
DB (store produced, Function) – coding (logic) - ETL developer, etc

Testing –

https://vctcpune.com/ 1
  In testing stage, Tester will work.
 Tester will write the test cases against requirement/ Use cases, Execute the test cases on
application/ software, Bug/ Issue found / raised, functionality demo, report, etc
 TCD – test cases design
 TCE – test cases execution

 After completion module, Project teams’ developer will do deployed these modules to
end user.
 In company, Project team will give 1 month warrant support (Module- recharge/
Movies/ FastTag, etc)
 After completion, 1 month warrant support then any issue present in these module
these will handle by support team.

Support-
 In support, Customer support manager, developer & tester
 In Support team will work on issue/ bug, Ticket, End user quires, etc

Payment - Max–
Movies – Class1 Hind- Email/ SMS-
200rs – Class3
Debit -10% dis. Class2 Class4
Credit - 20% dis.

Debit card Credit card

– class10 – – class11 –
10% 20%

Recharge- Prepared – Payment -

class1- 5% dis. class2-Union Max –Class3
terriers - 50rs
exclude

Waterfall module/ process-

 Waterfall module/ process, it is sequential process (one after another) of software
development.
 Sequential stages means – After completion of development then only testing will start.

https://vctcpune.com/ 1
  In Waterfall process, Developer / Deployment time is not fixed.

Information
Gathering (BRS)

Analysis (SRS1-Recharge module, SRS2- Movies module + Last Bug)

Design – HLD- SRS2

Coding – LLD X (note down)

Testing – TCD, TCE - Bug

Support

 In information gathering stage, BA will communicate with client and prepare business
related requirement in the from documents BRS.
 In Analysis stage, BA will communicate with client and prepare software/ system related
requirement and these requirement will stored in documents, it is called SRS/ FRS.
 After completion of these documents, BA will sent these SRS/ FRS to project team
(developer & tester).
 In design stage, Designer will work and prepare HDL (Frond end/ GUI/ UI, API,
Database)
 In Coding stage, developer will do the coding against LLD (Frond end/ GUI/ UI = 2
developer, API= 3 developer, Database= 2 developer)
 In testing stage, tester will work test cases design, Test cases execution.
 In TCE, if tester found then bug/ defect then tester will note down and when we got new
requirement then these bug/ defect will be fixed
 After completion, Of these module these module will delivery to client
 After warrant period, support will work on these modules.

 Dis-advances-
1. Delivery/ deployment timeline not fixed (sequential process)
2. Backtracking not possible (If bug found the immediate will not fixed)

V-Module/ process-
 In V-module stands for Verification & Validation
 In V-module/ process, we will parallel i.e. Development & Testing will work parallel
 In V-module/ Process delivery/ deployment time, it will be 3 month.
 V-module also called as Plan driver module.

https://vctcpune.com/ 1
 LCD (Life cycle development) LCT (Life cycle testing)

Information gath. (BRS) Assessment of dev plane

Analysis (SRS/FRS/CRS) Prepare test plane
(SRS1- 1module, SRS2- 2module) Requirements testing/ Doubt clear

Design – HLD Design phase testing

Coding – Developer -LLD Program Phase testing/ WBT
Test case design (TCD against SRS)

Install Build (Functionality) TCE- System & fun. Testing /BBT-

Pune- FIS
User acceptance testing (UAT) - Client- USA
Knowledge transfer (KT)

Maintains DRE (defect removable efficiency) /

/Support CR (change request)/ RFC/ postmortem testing

 In V-module, verification & validation will do parallel

 2 stages – Development & testing
 In development stage, BA will collect requirement from client (BRS & SRS)
 In testing stage, Developer, Tester will prepared plane for developer & testing

 In development stage, Designer will design – HLD & Developer will the coding against
LLD. Designer & Developer will do one round of testing.
 In testing stage, Tester will do the TCD against requirement/ Use Cases

 After completion of testing of developer then developer will deployed the build
 In testing stage, tester will do the TCE (In pune company)

 After completion of testing in pune environments, Developer will sent these build into
client environments (UAT- )
 In UAT, Testing will do and after completion of testing these build will sent to end user.

DRE (defect removable efficiency) –

 DRE will be decided how much deeply the testing done. DRE only calculated by PM.
 DRE = A /(A+ B) A= No. of defect found in Pune, B = No. of defect found in USA
 Ex. A= 10 defect, B = 2 defect  DRE = 10/ (10+2) = 10/12 = 84% = good testing
 Ex. A= 5 defect, B = 5 defect  DRE = 5/ (5+5) = 5/10 = 50% = Medium testing

https://vctcpune.com/ 1
  Ex. A= 1 defect, B = 10 defect  DRE = 1/ (1+10) = 1/11 = 4% = Very Low testing

CR (change request)/ RFC (request for change)-

 If any CR comes from client (Throw mail to PM/ BA/ delivery manager). PM/ BA will
check what is CR. CR will consider (development & testing) with the current work.
 Ex. Paytm – Recharge module – Initially Payment tab – 3 feature = Debit card (10 bank),
credit card (10 bank), Net Banking (10 bank), etc. deployed to client.
 CR/ RFC = Extra requirement/ feature = Client will demand for extra requirement/
feature in developed in functionality (addition 30 bank).
 For every CR/ RFC, Company will take extra charge from the client

Postmortem testing-
 In V-module/ process, we are development a module with the 3 month & after 3 we will
deploy to client. Before deploy to client, company will test the functionality/ build. These
testing will called as postmortem testing.
 Before deploying to production/ Live environments, company will test the
functionality/ build. These testing will called as postmortem testing. In postmortem
testing, tester will check important feature/ functionality development in current
module/ functionality.

Dis-Advanced-
1. In V-module, Deployed/ delivery within 3 moth.
2. In V-module, for every CR/ RFC, Company will take extra charge from the client.

Basic SDLC -
Information Analysis Design Coding Testing Support
Gathering (BRS) (SRS) (HLD) (Developers- LLD) TCD, TCE

Review (BA) Review (BA) Review (Design) WBT (White BBT (Black
Box testing) box testing)

https://vctcpune.com/ 1
 Static testing/ Verification / Dynamic testing / Validation /
Quality assurance Quality Control

 Review – Review it is a process, where documents/ design/ code/ Test cases will check
either it is correct & completed or not.

White Box testing (WBT) Black Box testing (BBT)

WBT will performed by developer BBT will performed by Tester
In WBT, developer will check code coverage, In BBT, Tester will check application/
Loop statement, Condition statement, software functional - Behavioral coverage,
Branching statement, etc error handling coverage, etc
(functionality & Non-functionality)
In WBT also called as code level testing. BBT also called as system & functional
Testing.
Developer will check the code these testing Tester will check the functional of the
will called as white box application so it is called as blank box (we
can’t see code for the functional)
In WBT, types In BBT types,
1. Unit Testing 1. Functionality
2. Integration Testing 2. Non-functionality

Verification/ Static testing Validation/ Dynamic testing

In Verification, BA will check their own In Validation, Tester will do test cases
documents, Designer will check their design, execution as per requirement (present in SRS)
and Developer will check their code.
Verification also called as static testing Validation also called as Dynamic testing
Verification also called as In-progress testing Validation also called as End-progress testing
In Verification, we will check application/ In Validation, we will check application/
software/ build Quality assurance software/ build Quality Control

Interview Question-
1. What is your team size in last project?
2. How many developer/ tester are present in your last project?
3. What is SDLC?
4. What is a SRS document & what it will continent?
5. What is a Use case?
6. What is the different between WBT & BBT
7. What is the different between verification & validation?
8. What is the CR/ RFC & what is process if CR comes in current work?
9. What is V-module and what are dis-advances?

https://vctcpune.com/ 1
Agile Process/ Module**-
 Agile it is iterative process/ Continue process, where development, testing &
deployment will done continues.
 Agile process also called as Values driver process (Client priority).
 In Agile, delivery/ deployed will be done to client within 2 week/ 3 week.
 In Agile, if any CR/RFC comes from client side then we will accept then PM will
check their impact current development, testing and application present in production/
live.
1. If this CR/RFC has been more impact on current development, testing and
application present in production/ live, these CR will be consider on next work.
2. If this CR/RFC has been less impact on current development, testing and application
present in production/ live, these CR will be consider in current work.

 Agile have different types Methodology /Frameworks/ Sub-types

1. XP (Extreme programming) – Only coding and No testing
2. Scrum – Sprint (bunch of US) wise delivery / deployment within 2 week
3. Lean – Follow for support team
4. kanban - Follow for support team
5. FDD (future driver development) – future consider working

 I have worked in Scrum Agile Methodology/ Frameworks/ Sub-types

Agile architecture –
SDLC Agile Process

Information Product Backlog (3 module = 140 US)

Gathering (BRS)

Analysis Sprint Backlog (Client priority)

(SRS1- Recharge module = 10 req.) Sprint 1= 8 US – 2week Dev + test +delivery
(SRS2- Movies module= 9 req.) Sprint 2= 9 US – 2week Dev + test +delivery
(SRS3- Electricity module= 10 req.) Sprint 3= 7 US – 2week Dev + test +delivery
Sprint 4= 8 US – 2week Dev + test +delivery

Use Cases BA will convert User Story (Small piece of work)

(1 specific requirement) (Use Cases = 6 US/ 7 US)
a. Description – a. Description –
b. Acceptance criteria – b. Acceptance criteria –

https://vctcpune.com/ 1
 Designer – against US

Developer – against US

Tester – against US

Product Backlog-

https://vctcpune.com/ 1
Sprint Backlog-

User Story-

https://vctcpune.com/ 1
Agile meeting/ ceremonies** –
 In Agile we have different meeting/ ceremonies
1. Sprint planning meeting
2. Grooming meeting
3. Daily stand-up meeting/ Scrum meeting
4. Sprint review meeting
5. Sprint retrospective meeting

Meeting Purpose Involved

Sprint planning - Current sprint work will be decided 1hr – Client, PM,
meeting ex. Current Sprint 2 = 10US BA, Designer, Dev
team, Testing Team
1st day of Sprint - Current sprint US – Task or work assign /
allocation to developer & tester (Tester = 3US)
- Estimation/ Time to completed the work
(ex. 1US = 26hr Development + 14hr Testing)
Grooming meeting - US related if we doubt / clarification then 30hr/ 1hr – BA, PM,
we will conduct these meeting with BA Designer, Dev team,
In 2 week any time Testing Team
Daily stand up Daily work progress - 15min/ 30min - PM,
meeting/ Scrum 1. What you have done yesterday BA, Designer, Dev

https://vctcpune.com/ 1
meeting 2. What are you doing today team, Testing Team
3. Issue/ Roadblock
Every Daily
Time – 10 am to
10.15 am
Sprint review - Current sprint work, these work will demo/ 1hr/ 2hr – Client/
meeting reviewed by Tester to Client/ UAT member / UAT Members/ BA,
BA PM, Designer, Dev
Last day of Sprint team, Testing Team
Sprint retrospective - Discussion on current sprint related Good 30min- PM, BA,
meeting & Bad things Designer, Dev team,
Testing Team
Last day of Sprint Current Sprint 2 Next Sprint 3

Agile Peoples-
Client  Stake holder
Delivery Manager  Solution master
PM  Scrum master
BA  Product Owner
Designer  Designer
Dev & Tester  Dev & Tester

Agile Days Wise -

 In Scrum Agile framework – Sprint = 2 week = 2 * 5 = 10 days * 8hr = 80hr
 Team Size = 18 people = 10 Developer + 3 Tester + etc
 Sprint 2 = 8 US (8US of 3 module US will present)
 Team 1 = 3 developer (Frond, API, DB) + 1 Tester (Me) = Recharge module = 3US
 Team 2 = 4 developer (Frond, API, DB) + 1 Tester = Movies Module = 3 US
 Team 3 = 3 developer (Frond, API, DB) + 1 Tester = Electricity module = 2 US

1 week (Monday to Friday)

Monday (Start of Sprint- 1 day of sprint, Office Time = 9 to 6 pm)
1. Sprint planning meeting – 1hr/2hr (10 am to 11am)
 In Current Sprint 2 = 8 US, we will work
 Task/ Work assign - Team 1 = 3US, Team 2 = 3US, Team 3 = 2US
 Estimation/ Time define = 1US = 28hr Development + 14hr Testing, etc

2. Grooming meeting – 30 min (11.30 am to 12 am)

 US doubt / clarification

https://vctcpune.com/ 1
 3. Work starts – Team 1
 1US  Developer – Coding (15hr) – In-progress
 1US  Tester – TCD against 1 US (4hr) – Complete

Tuesday – (Office Time = 9 to 6 pm)

1. Daily stand up/ Scrum meeting (Time 10 am to 10.15am)
 What you have done yesterday (1US – TCD – Complete)
 What are you doing today (2US – TCD- Start)
 Issue/ Roadblock

2. Work starts – Team 1

 1US  Developer – Coding (18hr) – Complete + 1US build sent for Testing
 2US  Tester – TCD against 2 US (6hr) – Complete

Wednesday - (Office Time = 9 to 6 pm)

1. Daily stand up/ Scrum meeting (Time 10 am to 10.15am)
 What you have done yesterday (2US – TCD – Complete)
 What are you doing today (1US – TCE- Start)
 Issue/ Roadblock - NA

2. Work starts – Team 1

 2US  Developer – Coding (16hr) – In-progress
 1US  Tester – TCE against 1 US (6hr) – In-progress

Thursday - (Office Time = 9 to 6 pm)

1. Daily stand up/ Scrum meeting (Time 10 am to 10.15am)
 What you have done yesterday (1US – TCE – In-progress)
 What are you doing today (1US – TCE – try to complete)
 Issue/ Roadblock - NA

2. Work starts – Team 1

 2US  Developer – Coding (18hr) – In-progress
 1US  Tester – TCE against 1 US (5hr) – Complete

Friday - (Office Time = 9 to 6 pm)

1. Daily stand up/ Scrum meeting (Time 10 am to 10.15am)
 What you have done yesterday (1US – TCE – Complete)
 What are you doing today (3US – TCD – Start)
 Issue/ Roadblock - NA

2. Work starts – Team 1

https://vctcpune.com/ 1
  2US  Developer – Coding (14hr) – Complete + 2US sent to Testing
 3US  Tester – TCD against 3 US (4hr) – In-progress

2 weeks (Monday to Friday)

Monday - (Office Time = 9 to 6 pm)

1. Daily stand up/ Scrum meeting (Time 10 am to 10.15am)
 What you have done yesterday (3US – TCD – In-progress)
 What are you doing today (3US – TCD – will Completed and 2US – TCE - Start)
 Issue/ Roadblock - NA

2. Work starts – Team 1

 3US  Developer – Coding (17hr) – In-progress
 3US  Tester – TCD against 3 US (2hr) – Complete + 2US – TCE (4hr) – In-progress

Tuesday - (Office Time = 9 to 6 pm)

1. Daily stand up/ Scrum meeting (Time 10 am to 10.15am)
 What you have done yesterday (3US – TCD – Completed & 2US – TCE - Started)
 What are you doing today (2US – TCE – try to completed)
 Issue/ Roadblock - NA

2. Work starts – Team 1

 3US  Developer – Coding (20hr) – In-progress + 2US  2 bug/ defect fixed (2hr)
 2US  TCE (5/6hr) – In-progress
 2US  In TCE found 2 Bug/ Defect & Inform to developer + 2 bug Teste(1hr) -
completed

Wednesday - (Office Time = 9 to 6 pm)

1. Daily stand up/ Scrum meeting (Time 10 am to 10.15am)
 What you have done yesterday (2US – TCE – In-progress & 2 Bug raised & test)
 What are you doing today (2US – TCE – try to completed)
 Issue/ Roadblock - NA

2. Work starts – Team 1

 3US  Developer – Coding (18hr) – completed + 3US Sent to Testing
 2US  TCE (4/5hr) – completed

Thursday - (Office Time = 9 to 6 pm)

https://vctcpune.com/ 1
 1. Daily stand up/ Scrum meeting (Time 10 am to 10.15am)
 What you have done yesterday (2US – TCE – Completed)
 What are you doing today (3US – TCE – start)
 Issue/ Roadblock - NA

2. Work starts – Team 1

 3US  Developer – waiting for bug + 4 bug fixed & 2 defect developer not accepting
 3US  TCE (6/7hr) – In-progress
 3US – 6 defect/ bug raised & inform to developer + 4 bug (1hr) - Completed

Friday - (Last day of Sprint) (Office Time = 9 to 6 pm)

1. Daily stand up/ Scrum meeting (Time 10 am to 10.15am)
 What you have done yesterday (3US – TCE – In-progress)
 What are you doing today (3US – TCE – remain work 2hr we will be completed)
 Issue/ Roadblock – 2 bug/ defect developer not accepting

2. Work starts – Team 1

 3US  Developer –2 defect developer fix
 3US  TCE (2/3hr) – completed + 2 bug tested 30min- completed

3. Sprint review meeting (1hr/2hr) (Time 2pm to 3 pm)

 Tester (Me) – 3 US – Recharge module – 3 US demo / review

4. Sprint retrospective meeting (30min/ 1hr) (4 to 4.30 pm)

 Current 2 = Good things and Bad things need to discuss

OR

https://vctcpune.com/ 1
 1 Week
Day Monday Tuesday Wednesday Thursday Friday
Meeting Sprint Daily stand Daily stand Daily stand Daily stand
Planning up- up- up- up-
meeting – Work progress Work Work Work
Sprint 4= 9US to individual progress to progress to progress to
Task/Work- person individual individual individual
Team person person person
Estimation/
Time

Grooming-
Doubt
Developer 1US – Coding – 1US – Coding 1US – Coding 1US – 2US – Coding
In-progress – In-progress – In-progress Coding – – In-progress
Completed
Tester 1US – TCD - 1US – TCD - 2US – TCD – 3US – TCD – 3US – TCD –
In-progress Completed Start & Start & In- Completed
Completed progress
2 Week
Day Monday Tuesday Wednesday Thursday Friday
Meeting Daily stand up- Daily stand Daily stand Daily stand Daily stand
Work progress up- up- up- up-
to individual Work progress Work Work Work
person to individual progress to progress to progress to
person individual individual individual
person person person

https://vctcpune.com/ 1
 Sprint
Review

Sprint
Retrospective
Developer 2US – Coding – 2US – Coding 3US – Coding 3US – 3US – Coding
In-progress – Completed – In-progress Coding – In- – Completed
progress
Tester 1US – TCE – 1US – TCE – 2US – TCE – 3US build 3US- TCE –
In-progress Completed + 4 Start & (can’t start Start &
Bug raised Completed + testing) + 6 Completed +
2 bug raised Bug will be 4 Bug raised
test + Tested

OR

1 Week
Day Monday Tuesday Wednesday Thursday Friday
Meeting Sprint Daily stand Daily stand Daily stand Daily stand
Planning up- up- up- up-
meeting – Work progress Work Work Work
Sprint 5= 12US to individual progress to progress to progress to
Task/Work- person individual individual individual
4US Team person person person
Estimation/
Time

Grooming-
Doubt
Developer 1US – Coding – 1US – Coding 1US – Coding 2US – 2US – Coding
In-progress – In-progress – Completed Coding – In- – In-progress
progress
Tester 1US – TCD – 2US – TCD - 3US – TCD - 3US – TCD – 1US – TCE-
Start & Start & In-progress Completed + Completed
Completed Completed 1US – TCE-
Start & In-
progress
2 Week
Day Monday Tuesday Wednesday Thursday Friday
Meeting Daily stand up- Daily stand Daily stand Daily stand Daily stand
Work progress up- up- up- up-
to individual Work progress Work Work Work

https://vctcpune.com/ 1
 person to individual progress to progress to progress to
person individual individual individual
person person person

Sprint
Review

Sprint
Retrospective
Developer 2US – Coding – 3US – Coding 3US – Coding 4US – 4US – Coding
Completed – In-progress – Completed Coding – In- – Completed
progress
Tester 4US – TCD – 2US – TCE – 2US – TCE – 3US – TCE – 4US – TCE –
Completed In-progress Completed & Completed Start &
3US – TCE – Completed
Start & In-
progress

Agile related Terms-

Epic-

Product Backlog-

Sprint Backlog-

https://vctcpune.com/ 1
https://vctcpune.com/ 1