Software Manual Testing PDF

2016
Manual Testing
Prepared by Anil Kumar

Teacher by Nageswara Rao Pusuluri
Mindq System pvt ltd
3/10/2016
Contents
Lesson 1 ............................................................................................................................................... 4
Software........................................................................................................................................... 4
A set of executable programmes in an electronic device is called as software... 4
Project VS Product ....................................................................................................................... 4
Quality Software ........................................................................................................................... 4
SDLC.................................................................................................................................................. 4
Types of SDLC Models ................................................................................................................ 4
OLD SDLC Models............................................................................................................................. 4
A. Waterfall Model ................................................................................................................. 4
B. Prototype Model ................................................................................................................ 6
Advanced SDLC (Software Development Life Cycle) Models ........................................ 12
Old SDLC models with V-Model ................................................................................................ 16
Lesson 2 ............................................................................................................................................. 22
Agile scrum model ......................................................................................................................... 22
Lesson 3 ............................................................................................................................................. 30
Testing Stages/Phases ................................................................................................................. 30
I. Documents Testing ............................................................................................................ 30
II. Unit Testing ...................................................................................................................... 31
III. Integration Testing ........................................................................................................ 34
IV. Sprint or Software Testing .......................................................................................... 36
1) Functional Testing .......................................................................................................... 36
2) Non-Functional Testing ................................................................................................ 38
V. Acceptance Testing ........................................................................................................ 41
VI. Release Testing ............................................................................................................... 41
VII. Testing during Maintenance ....................................................................................... 42
Lesson 4 ............................................................................................................................................. 43
STLC: (Software testing life cycle) .......................................................................................... 43
I. Test Initiation: ..................................................................................................................... 44
Optimal test strategy in IEEE829 format .......................................................................... 45
II. Test Planning.................................................................................................................... 48
III. Test design........................................................................................................................ 51
Test cases document format in IEEE829 .......................................................................... 54
2
Case study (Online Insurance system).................................................................................. 55
User story1:- (IEEE830) .......................................................................................................... 55
Q) Prepare test scenarios cases for registration module functional testing in
OIS? ................................................................................................................................................. 55
Test cases document (IEEE829) .......................................................................................... 56
W3C Rules on email id:* ......................................................................................................... 61
Characteristics of testers......................................................................................................... 61
Using regular expression in test design ............................................................................ 61
Regular expression for pan card number.......................................................................... 62
Regular expression for mobile number in India ............................................................. 62
Regular expression for email ................................................................................................. 64
User Story 2 ................................................................................................................................. 65
Q) Prepare test scenarios and cases for login module functional testing in OIS
site? ................................................................................................................................................. 65
User story 3 .................................................................................................................................. 68
Q) Prepare test scenarios and cases for policy creation module functional
testing in OIS?............................................................................................................................. 69
Usability Test design ................................................................................................................. 86
Comparability Test Scenario .................................................................................................. 88
Hardware configuration Testing............................................................................................ 89
Performance Testing ................................................................................................................. 90
IV. Test Execution ................................................................................................................. 94
a) Formal meeting ............................................................................................................... 95
b) Levels of Test Execution .............................................................................................. 96
c) Establish Test Environment ............................................................................................ 97
d) Smoke Testing or Testability Testing or Verification Testing ........................ 97
e) Real Testing ...................................................................................................................... 98
f) Error, Defect, Bug, Failure .............................................................................................. 98
g) Defect Report ................................................................................................................... 98
h) Defect tracking process ............................................................................................. 100
i) Bug Life Cycles .................................................................................................................. 100
j) Test ........................................................................................................................................ 100
3
Lesson 1
Software
A set of executable programmes in an electronic device is called as software.
Project VS Product
 A software was developed depends on specific customer or client requirements
called as project or application.
Ex: ICICI Bank application
 A software was developed depends on overall requirements in market is called
as product.
Ex: Windows, OS, Ms-Excels……..
Quality Software
When one software maid customer requirements and expectations, a software
called as a quality software.
 Here requirements mean functionality.
 Expectations means user-friendliness, performance, comparability,
security...etc
SDLC
It’s transfer software development life cycle.
SDLC is the process of to develop new software. They are different SDLC models
to develop software in IT organizations.
Types of SDLC Models

OLD SDLC Advanced SDLC
Waterfall Model(WF) V-Model
Prototype Model Agile Model
Incremental Model Fish Model
Spiral Model Devops
RAD Model
OLD SDLC Models

A. Waterfall Model
Before learning the waterfall model let you know about:
Software bidding: A proposal to develop new software is called as 'software bidding'
 If a proposal came from the customer point of view then it is called as "software
project bidding".
 If a company will study the needs of the market and develop the software then
that type of proposal is called as "software product bidding"
4
Note: The above waterfall model is also called as the "Linear Sequential Model"
When requirements are clear, organization can follow waterfall model.
Explanation of above diagram:
1. From the above diagram at first software bidding will be done between the CEO of
company and customer or client. Then after bidding, the CEO will conduct the
meeting with all the project managers (PM) in the company called as "kick of
meeting"(KIM).
2. In that meeting CEO will make an announcement about that new project to
handle that project any one of the project manager will be selected. Then that
project manager will give a project initiation note (PIN) to CEO.
3. Then PM will assign the work to the business analyst (BA) to gather all the
requirements from the customer.
5
4. Then BA will submit all the gathered requirements to the system analyst (SA) to
design in order to do the analysis or detailed planning which is going to submit it
to the PM. Then PM will approve that planning done by SA.
5. Then SA will submit that document to the technical architect (TA).
6. Then designers will do the design which consists of HLD and LLD's.
7. Based on that design programmers will do the coding and that corresponding
programmers will test the developed code.
8. Then after testing that s/w few programmers will be selected for onsite and
release the s/w.
9. Then change for control board (CCB) people will do the maintenance/support of
that s/w.
Advantages of waterfall model:

1. The main strength of waterfall model is its simplicity and it is very easy to use.
2. Output generated at the end of each phase is reviewed and approved and hence
it has high visibility.
3. Minimal resources are required.
4. It is less expensive as minimal resources are required.
5. This model is preferred for smaller projects where requirements are well clear.
6. Time spent early on making sure that requirements and design are absolutely
correct saves much time and effort later.
Disadvantages of waterfall model:

1. It is difficult to implement any changes in the requirement.
2. No working software is produced until the last stage of the life cycle.
3. It is expensive to incorporate any changes once the project is in to testing phase.
4. Not suitable for complex projects, long term projects.
5. Not suitable when requirement are not clear.
B. Prototype Model
Whenever the customer requirements are not clear, organizations can goto develop
model software to show to customers and to get clear requirements. This sample
software is called as "prototype"/Sample screens are prototype to customer for clear
requirements gathering.
6
Note: In above diagram identify new requirements means Collect clear requirements.

1. From the above diagram at first software bidding will be done between the CEO of
company and customer or client. Then after bidding, the CEO will conduct the
meeting with all the project managers (PM) in the company called as "kick of
meeting"(KIM).
2. In that meeting CEO will make an announcement about that new project, to handle
that project any one of the project manager will be selected. Then that project
manager will give an project initiation note (PIN) to CEO.
3. Then PM will assign the work to the business analyst (BA) to gather all the
requirements from the customer. If customer requirements are not clear then
company will develop a model s/w and show to the customer. At that time customer
will identify the new requirements and those requirements will be gathered by BA.
7
4. Then BA will submit all the gathered requirements to the system analyst (SA) in
order to do the analysis or detailed planning which is going to submit it to the PM.
Then PM will approve that planning done by SA.
5. Then SA will submit that document to the technical architect (TA).
6. Then designers will do the design which consists of HLD and LLD's.
7. Based on that design, programmers will do the coding and that corresponding
programmers will test the developed code.
8. Then after testing that s/w, few programmers will be selected for onsite and release
the s/w. Then change for control board (CCB) people will do the
maintenance/support of that s/w.
Advantages of prototype model:

1. Clarity on requirements from the customer, success rate of the project is higher.
2. Customer can see the system and he provides the feedback immediately.
3. Error can detected much earlier as customer is getting involved.
4. Reduced time and cost.
5. Improved and increased user involvements.
Disadvantages of prototype model:

1. Customer may think that prototype is the real system.
2. Time taking model as the actual development does not start until the prototype is
finalized.
3. Adopting changes or adding new requirements is difficult.
4. Prototype is of no use once the development of actual system started.
8
C. Incremental Model
When customer requirements are clear, but huge. Then the organizations can
follow the incremental model to release the software instalment by instalment.
SRG some requirements gathering
A  Analysis
D Design
C  Coding
T  Testing
R  Release
M  Maintenance
1. From the above diagram in the first instalment (i #1) all the process from the software
requirement gathering (SRG) to maintenance will be done and this will be proceeded up
to last instalment (i # N).
2. Thus finally all the huge requirement software will be developed and released to the
customer instalment by instalment.
Advantages of Incremental model:
 Generates working software quickly and early during the software life cycle.
 This model is more flexible – less costly to change scope and requirements.
 It is easier to test and debug during a smaller iteration.
 In this model customer can respond to each built.
 Lowers initial delivery cost.
9
 Easier to manage risk because risky pieces are identified and handled during it’d
iteration.
Disadvantages of Incremental model:
 Needs good planning and design.

 Needs a clear and complete definition of the whole system before it can be
broken down and built incrementally.
 Total cost is higher than waterfall.
When to use the Incremental model:
 This model can be used when the requirements of the complete system are
clearly defined and understood.
 Major requirements must be defined; however, some details can evolve with
time.
 There is a need to get a product to the market early.
 A new technology is being used
 Resources with needed skill set are not available
 There are some high risk features and goals.
10
D. Spiral Model
When the requirements are clear and enhancing regularly, organizations can follow spiral
model to release the software version by version.
1. From the above diagram requirement gathering will be done at first and later design
this will be continued till the maintenance stage.
2. If customer will need any enhancements, those enhancements will be gathered by them
and again with the new requirements, analysis will be done. This cycle will be repeated
for every new version of the software.
Advantages of Spiral model:

1. High amount of risk analysis and hence avoidance of risk is enhanced.
2. Good for large and mission-critical projects.
3. Strong approval and documentation control.
4. Additional functionality can be added at a later date.
5. Software is produced early in the software life cycle.
Disadvantages of Spiral model:

1. Can be a costly model to use.
11
2. Risk analysis requires highly specific expertise.
3. Project’s success is highly dependent on the risk analysis phase.
4. Doesn’t work well for smaller projects.
E. Rapid Application Development (RAD) Model

1. Organizations are following this Model, when Customer Requirements are
known.
2. When customer requirements are similar to old projects, then organizations
can follow this model to develop new software by copying coding from old
projects and they will release new Software using existing Software Coding.
3. Here, New Software will be integrated by using Existing Components of Old
Projects
Advanced SDLC (Software Development Life Cycle)

Models
Before going to learn the Advanced SDLC models, let you know the reasons for
outdating the old SDLC models in the organizations. They are:
1. In all the Old SDLC Models, Testing Stage comes after Coding only.
2. This Single Stage of Testing is conducted by the Same Programmers / Developers who
perform Coding.
3. Due to this, Organizations are not able to release Quality Software to Customer or to
Market.
4. To Develop and Release Quality Software, Organizations are following New SDLC
Models.
5. In New SDLC Models, Organizations conduct Multiple Stages of Testing and maintain
Separate Testing Teams. The new SDLC models are as follows:
a) Fish Model
b) V-Model
c) Agile Model(XP,SPRINT,SCRUM)
d) Devops
a) Fish Model
To release quality software to customer/market, we need to conduct multiple

stages of testing by including separate tester. Do you this reason , organization
are following advanced SDLC model.
To develop a quality s/w w.r.t to customer requirements and expectations,

organizations are following fish model. But, this model is costly to follow and time
consuming model.
12
1. At first project initiation note(PIN) will be given to the CEO, from there
the work is going to begin.
2. One BA can prepare BRS and other BA can review BRS for Completeness
and correctness.
BRSBusiness Requirement specifications
Customer Requirement specifications
User Requirement specifications
3. One SA can prepare SRS and Other SA can review SRS for completeness
and correctness.
SRS Software Requirement specifications
4. Design is two levels such as
HLDHigh Level Design
LLDSLow Level Designs
5. One TA can prepare HLD & LLDS and other TA can review HLD & LLDS for
completeness and correctness.
6. Programmers can develop software by writing programs and by
integrating those programs.
7. Other programmer can conduct unit testing & integration testing.
8. A separate testing team can test software called as software testing.
9. PM can take care of Acceptance and release. Here programmers and
testers can involve along with customer site people.
10. CCB can take care of maintenance/support/service.
(OR)
1. At first project initiation note(PIN) will be given to the CEO, from there the
work is going to begin.
2. The business analyst(BA) will gather all the requirements from the customer
and for that gathered requirements testing purpose a 'separate testing team' will
be assigned.
3. Then system analyst (SA) will do the analysis of that requirements and for
the review of those analysed requirements a 'separate testing team' will
be assigned.
13
4. Technical architect (s.r programmer) will do the design of those analysed
requirements in the form of HLD and LLD's after that a 'separate testing team'
will be assigned for the review of those design.
5. All the above conducted testing or reviewing is called as 'documents testing'

or 'verification' or 'static testing'.
6. Unit testing: unit testing means that conducting testing on a single

programme in java, .NET,oracle,SAP,C,C++ and etc.
7. Integration testing: Integration testing means conducting testing on the

interconnection of two or more programmes. The below diagram depicts the
integration testing:
8. Software testing: software testing means conducting the testing on a

complete Software w.r.t to the customer requirements and expectations.
9. Acceptance testing: Acceptance testing means that collecting the

feedback on S/w from the real customers (Clients) or model customers (Public).
10. Release testing: Release testing means that the whether s/w was
completely and correctly ported into customer site or not. It is also called
as onsite testing/Delivery testing/port testing.
11. Maintenance testing: During the maintenance testing, CCB people can
modify and test s/w w.r.t to customer change request.
Advantages of fish model:
Due to thorough verification and validation Fish Model yields a quality product.
Disadvantages of fish model:
It is more time consuming/taking.

It is more expensive/costly.
14
Note: But this model is follow able to develop software relative to satellites,
aeronautical, Health care equipments, robotics, and export systems because those
software critical to develop and quick sharing in usage.
b) V-Model
 To decrease cost and time in software development, company will go to V-Model
but this model can assure quality but not guaranty.
 This model was introduced by "William Evans ferrie".
 'V' stands for verification and validation.
 This model is also defining mapping in between development stages and testing
stages.
 This model is not taking more time to develop a quality s/w unlike Fish model.

1. From the above model BA can prepare and review BRS.
2. SA can prepare and review SRS.
3. TA can prepare and review HLD and LLD's.
4. Programmer can write programmes and conduct unit testing and integration testing
w.r.t LLD’s and integration testing w.r.t HLD.
5. A separate testing team can test s/w (system testing) w.r.t SRS.
6. Customer site people can provide feedback on s/w w.r.t BRS.
7. Release team will take care of s/w release and port testing and CCB people can take
care of maintenance/support.
8. To assure quality to customer on s/w, project management can maintain separate
testing team in software testing stages because software testing is bottle neck stage for
software development.
15
9. V-Model is follow to develop banking, insurance, Hospital management, financial
insurance, e commerce ,logistics ….etc based software.
Note: From the V-model, a separate test engineers will be needed for s/w testing stage.
Those test engineers also responsible for involve in the acceptance testing and release
testing.
Note: Small and medium scale companies prefer V-model to follow because this model
is inexpensive and not taking more time.
Advantages of V-Model:
6. Quality of the software gets improved as the model as testing activities for
the respective development activity.
7. Avoid the defect multiplication.
8. Saves more time as testing activities happen well before coding.
9. Defects can be identified in the early stages of the life cycle.
Disadvantages of V-Model:
1. Expensive as it involves more number of resources.
2. Adopting any changes in requirement is not possible.
When to use the V-Shaped Model:
 All requirements are known up-front

 When it can be modified to handle changing requirements beyond analysis phase
 Solution and technology are known
Note: In old SDLC models, testing will come after coding only. But, in advanced SDLC
models testing will come in every stage of development by same developer or
separate tester.
Old SDLC models with V-Model

i. Prototype V-Model:
 When customer requirements are clear, organizations are following v-model by
conducting testing in every stage of development and separate testing team for
software testing stage.
 When customer requirements are not clear, organizations will follow prototype V-
model.
16
 Once requirements are finalized, again same V-model will proceeds.
ii. Incremental V-Model
When customer requirements are clear and huge, organizations’ can follow Incremental
V-model.
17
iii. Spiral V-Model
When customer requirements are enhancing regularly, organizations’ can follow Spiral V-
model.
c) DevOps
Devops transfer development and operations.
From this model developers and testers confirm as a single team like in agile model but
they are responsible for maintenance also. In general in other models, maintenance of
software is the job of CCB.
Example: Apple products
Case study: Any type of software but customer and company need to provide facilities
to team (Developer + Testers) for development, testing, release and maintenance.
Technical benefits:
 Continuous software delivery
18
 Less complex problems to fix
 Faster resolution of problems
Business benefits:
 Faster delivery of features

 More stable operating environments
 More time available to add value (rather than fix/maintain)
In details:
http://newrelic.com/devops/benefits-of-devops
d) Agile Model
Agile model is derived from agile manifesto like Shown below.
1. Develop software in incremental model as instalment by instalment.

2. Individual and interaction over process and tools.
3. Working software over comprehensive documentation.
4. Customer collaboration over contract negotiation.
5. Responding to change over following plan.
In general, different types agile model are in use such as scrum, extreme programming
(XP), kanban, FDD, ASD, Lean, DSDM, Crystal.
Here popular agile model is scrum because in this model, developers can join with
testers as single team, call it’s a scrum team.
In large scale companies, this model is follow able. Because, client is able to maintain
stakeholder team to approve deliverables of each stage in development.
19
After completion of software testing and approval from the stakeholders, real customers
are involving to give the feedback on that software.
Under the guidance of stakeholders, release team can release software and CCB can
maintain software.
Advantages of Agile model:
1. Success rate of the project very high compared to any other models.
2. Can adopt changes in requirements at any point of time.
3. Working software is delivered frequently.
4. It emphasizes on responding to change rather than extensive planning and
documentation.
5. It is recommended for product development.
20
Disadvantages of Agile model:
1. Expensive model as more number of resources are required.

2. Complex in managing.
3. There is lack of emphasis on necessary designing and documentation.
4. The project can easily get taken off track if there is any communication gap.
Case Study :( Old SDLC under along with Agile Model)

When customer requirements are clear and customers are ready to provide stakeholders
then organizations can follow the 'Agile model'.
1. When customer requirements are not clear and customer is ready to provide
stakeholders, organizations can follow prototype based agile model called as 'XP'
(Extreme Programming).
2. When customer requirements are huge and customer is ready to provide
stakeholders, organizations can follow in based incremental based agile model
called as 'SPRINT'.
3. When customer requirements are enhancing regularly and customer is ready to
provide stakeholders, organizations can follow spiral based agile model called as
'SCRUM'.
21
Lesson 2
Agile scrum model

1. Currently companies using model is agile model.
2. In agile model scrum methodology more popular.
3. Scrum word is related to rugby game here scrum transfer for formation of two
teams as one team.
4. In scrum methodology developers and testers combined team is called as scrum
team.
5. From scrum methodology, we can develop software as piece by piece called as
sprint.
6. Sprint is a piece of software, which is potential shippable to customer site.
7. Every sprint duration is 30 days for a development and testing.
8. Scrum team size is 7 to 10 members(developers + testers) (3:1 ratio)
a. Agile scrum process
1. From the above process, agile scrum methodology is incremental spiral

model, means developing software as piece by piece, but here every piece is
having new features along with pervious piece features.
2. The above agile scrum methodology is classified into roles, ceremonies,
artifacts.
22
Roles in Agile Scrum Ceremonies Artifacts
Customer Kick of meeting (KOM) Product Backlog (PBL)
Stack Holders (SHS) Product Backlog Sprint Backlog (SBL ) PO
Grooming Meeting
(PBLGM)
Chief executive officer Sprint Planning Meeting HLD & LLD’s
(CEO) (SPM)
Product Owner (PO) Daily Scrum Meeting Unit Test case (UT) Developer
(DSM)
Scrum Master (SM) Sprint Review Meeting Integration Test case (IT)
(SRM)
Scrum Team (ST) Sprint Retrospective Sprint Test case(ST) Tester
Meeting (SRSM)
Change Control Board Product Backlog Defect Reports
(CCB) Refinement Meeting
(PBLRM)
Traceability Matrix
->Sprint Burn-Down chart (Flow
diagrams)  (SM)
I. Roles in SCRUM
a) CEO:
1. Head of Software Company.
2. Responsible to study customer proposal or responsible to prepare own product.
3. Responsible to conduct kick of meeting to select PO under guidance of customer
& SHS.
4. Responsible to involve in script review meeting for customer feedback.
b) Customer:
1. Involve in kick of meeting for PO selection.
2. Appoint SHS.
3. Share requirements to PO.
4. Provide feedback on sprint.
5. Suggest changes in user stories.
c) Stack Holders:
1. Involve in kick of meeting for PO selection.
2. Involve in product backlog grooming meeting to share customer requirements to
PO.
3. Involve in sprint planning meeting to select some user stories from all user
stories for every sprint.
4. Involve in daily scrum meeting for status of requirements during sprint process
(during 30 days).
5. Involve in sprint review meeting to collect feedback from customer.
6. Involve in product backlog refinement meeting for changes in user stories.
d) Product Owner (PO):
1. Responsible to prepare product backlog with all user stories.
2. Responsible to decide some user stories for sprint development.
3. Responsible to prioritize user stories while selecting for sprint.
4. Responsible to adjust user stories for sprint with respective duration and scrum
team size.
5. Responsible to motivate scrum team during sprint development & tester.
6. Responsible to accept or reject work result.
23
e) Scrum Master:
1. Represents management to the project.
2. Responsible for enacting scrum values and practices.
3. Remove impediments.
4. Ensure that the team is fully functional and productive.
5. Enable close cooperation across all roles and functions.
6. Shield the team from external interferences.
f) Scrum Team: (Developers & Testers)
1. Scrum team size is 7 to 10 members.
2. Scrum team is a combination of developers and testers.
3. Scrum team have 30 days time to finish one sprint development and testing
(Sprint duration is changing depends on agreement in between company and
customer).
Developers:
Developers of scrum team can finish HLD and LLD’s of sprint and they are
responsible for coding, unit testing, integration testing, and sprint release to
testers and bug fixing.
QA Testers :( Quality Assurance Testers)
QA testers are responsible for study sprint backlog user stories and prepare test
scenarios and cases along with test data. They are responsible for test execution,
Test automation, defects reporting and bugs closing.
g) CCB Responsibility:
1. It is a fresher team.
2. Team members have knowledge on development and testing both.
3. Responsible to receive change request from customer site on released sprints.
4. Perform changes in sprint and release patch file to customer site.
24
II. Ceremonies
Ceremonies in Agile scrum
a) Kick of meeting:
1. CEO or higher management is responsible to select product owner in kick
of meeting.
2. This selection must be approved by customer and their stakeholders.
b) Product Backlog Grooming Meeting:
1. Participants are customer, SHS, PO.
2. PO can gather all requirements of customer as user stories and prepare backlog
document like shown below.
Example: Product Backlog Document
As a I would Like to So that Acceptance criteria

(Exceptions)
Existing User  Launch Sprint If given This login need to be
 Enter userid userid and performed in win
as alphanumeric password are XP/Vista/7/8/10/Linux/Mac
from 4 to 16 valid, next computers by using
positions screen will be IE/MFF/Chrome/Safari/Opera
 Enter opened Browsers
password as If userid or Easy to use
alphanumeric password is 1000 user can try to login
from 4 to 8 invalid , error at a time
positions message will
Click submit be displayed
button
Customer Requirements Customer Expectations
25
3. PO can review completeness and correctness of user stories in product backlog.
4. PO can take the help of SME (Subject matter expert) to get more clarity on
customer requirements while preparing product backlog.
5. If any customer requirements is EPIC (ALL User stories), then PO can divided
that requirement into multiple user stories.
c) Sprint Planning Meeting:
1. Participants are SHS, PO, SM and Scrum Team.
2. PO responsible to select some user stories for current on size and importance
3. PO is responsible to assign T-shirt size indicators to all user stories for

adjustment in between product backlog and sprint backlog.
4. Po needs to get approval from stake holders on selected user stories for
current sprint.
5. Po needs to get feedback of scrum team on selected users stories for current
sprint.
d) Daily Scrum Meeting:
1. Participants are PO,SHS, SM and ST
2. Needs to conduct the daily during 30 days of sprint process.
3. Meeting duration is 15 minutes.
4. This meeting is also called stand-up meeting.
5. Through this meeting, PO and SHS along with scrum master can try to know
problems of scrum team.
6. During this meeting, PO cans constraint on 3 points.
1. What did you do today?
2. What will you do tomorrow?
3. What obstacles are in your way?
7. Scrum mater is responsible to invite participants and responsible to provide
facility for daily scrum meeting.
8. SM can maintain time box to start and stop daily scrum meeting.
e) Sprint Review Meeting:
1. Participants are customer, CEO, PO, SM and ST.
2. To show sprint to customer for feedback.
3. The time box is 2 hours.
4. Perform instance changes in sprint if require.
5. Plan sprint release to customer site.
f) Sprint Retrospective Meeting:
26
1. Participants are SM and ST only.
2. To form feedback on finished sprint.
3. One hour time box.
4. Discuss problem faced in finished sprint process/previous sprint process.
g) Product Backlog Refinement:
1. Participants are customer, SHS, PO, SM and ST.
2. Two to three hours is time box.
3. Responsible to change product backlog user stories before going to the next
sprint.
III. Artifacts
In Agile model documents are called as atrifacts.
Examples:-
Praposal document (from customer site in project or from management of

company in product)
Product Backlog (PO)-ALL User stories
Sprint Backlog (PO)-Some user stories
High-Level Design & Low Level Designs (Developers in ST)
Unit test cases and integration test cases (Developers in ST)
27
Sprint Burn down Chart (SM)
IV. Multi Scrum

1. Sometimes organizations can maintain multiple scrum teams for one project.
When that project is huge. Here every scrum team is depending corresponding
scrum master and product owner.
2. ALL SM and PO from scrum team can be coordinate chief scrum master and
Mater PO.
MPO Master Product owner
CSMChief Scrum Master
28
V. Certifications
Launch SCRUMSTUDY.COM site
Click register
Fill fields
Click submit
Click login by using register email id and emailed password
Select scrum fundamental exam
Answer questions
Note: To get more information on agile scrum process, we are able to read SBOK guide.
SBOKSCRUM Body of knowledge.
29
Lesson 3
Testing Stages/Phases
I. Documents Testing
1. In any advanced SDLC Model, testing can start with documents testing. In agile
scrum model, PO is responsible to prepare product backlog with all user stories.
2. Same PO is responsible to review that PBL from completeness and correctness.
3. PO is responsible to select some user stories with to respective user stories size &
importance from ALL user stories for sprint backlog.
4. Same PO can review sprint backlog for completeness and correctness.
5. Scrum team developers are responsible to develop HLD & LLD depends on SBL.
Here HLD can define overall architecture of sprint, where as LLD’s can
define in-depth logic of specific model in that sprint. Due to this reason,
one sprint design consists of one HLD and multiple LLD’s.
Example:
HLD and LLD for login:
6. Same developers can review HLD and LLD completeness and correctness.
Case Study:
Document Prepared By Reviewed by Techniques (*)

Product Backlog PO Same PO Walk Through
(PBL) Inspection
Peer Review
Sprint Backlog PO Same PO Walk Through
(SBL) Inspection
Peer Review
HLD & LLD’s Developers in ST Same Developer in Walk Through
ST Inspection
30
Peer Review
Walk Through: Study a document from first to last.
Inspection: searching document for specific factor.
Peer Review: Comparison of two similar documents.
These 3 techniques are also called as static testing techniques or review techniques
or document testing techniques or verification techniques.
II. Unit Testing

After completion of sprint backlog and design documents preparation and review,
corresponding developers in scrum team can start coding by writing programs.
These same developers are responsible to test programs by applying white box
testing techniques.
In general understanding above diagram four points:

1. Program running or not
2. Program correctly working or not
3. Program running fast or not
4. Testing on above 3 testing (Program lines cheeking)
a) Basic Paths Coverage:

Unit testing can start with basic paths coverage on a program. Here , developers
can run program more than one time by covering all reasons of that program.
Here programmer can follow a process.
Example 1:
31
Example 2:
Example 3:
b) Control structure Coverage:

When one program is running without any errors, corresponding Programmer can
concentrate on that program output correctness with respective given input. This
32
technique is also called as debugging. Here program can watch output of each
line in program.
c) Program technique coverage:

When program is running correct corresponding programmer can try to calculate
execution speed of the program. Here programmer can use JUNIT and NUNIT like tools
to calculate execution speed of program.
d) Mutation Coverage:
When one Program running fast and correctly, corresponding programmer can
validate program test coverage. Here programmer can retest program to identify
management level people performed changes.
If programmer not succeeding in changes finding, then management can decide
that program testing in incomplete.
This technique is also called as bebugging.
Case Study:
33
III. Integration Testing
After completion of related programs writing and unit testing corresponding programmer
can inter connect programs to build a sprint/software. Here Programmers can test
interconnection of programs correctness.
Here programmers can follow any one of four approaches such as Top-down, Bottom-Up,
hybrid, big bang approaches.
1) Top-Down:
From this approach programmer can interconnect main program and some of sub
programs because the remaining sub programs are under constructions. In the place of
under constructive sub programs, programmer can use temporary program called as
STUB.
2) Bottom-UP:
From this approach programmer can interconnect sub programs without involvement of
main program because the main program is under construction. In the place of under
constructive main program, programmer can use a temporary code as Driver.
34
3) Hybrid approach:
From this approach programmer can interconnect sub programs without involvement of
main program and some of sub programs because they are under construction.
This approach is also called as sand-which approach. Here driver is “calling program”
and Stub is “Called Program”.
Note: Top-down, bottom-up and hybrid approaches are also called as incremental
integration.
4) Bigbang approach:
This approach is also called system approach. Form this approach programmers can
wait until 100% coding then goto integration.
35
IV. Sprint or Software Testing
After completion of integration of sprint, tester in scrum team can concentrate on sprint
testing by conducting below functional and non-functional tests.
1) Functional Testing
Sprint testing or software testing by testers can start with functional testing. Here
testers can validate sprint or software with respective to customer requirements
in user stories.
In general, functional testing is divided into below subtest.
a. GUI Testing:
GUI transfer graphical user interface.
During this test, testers can validate behaviour of each element in every
screen of sprint or software. This testing is also called as control flow
testing or behavioural testing.
b. Input Domain Testing:

During this test, testers can fill input elements to validate size and type
of those elements.
c. Error-Handling Testing:
During this test, testers can operate sprint or software screens, by giving
invalid data to get error message, POP-Ups.
d. Manipulation Testing:
During this test, testers can operate sprint or software screens, by giving
valid data to get output or outcomes.
This testing also called as functionality testing.
e. Database Testing:**
During database testing, testers can operate front end screens of software
and observe that operation impact on back end database tables. In terms
of data validation and data integrity.
36
f. Data Volume Testing:
This test also called as memory testing or capacity testing.
During this test, testers can try to calculate capacity of data base table in
sprint or software.
Note: In above 6 functional testing topics. First 4 topics are front end; next 2 topics are
back end test.
37
g. Recovery Testing:
This test is also called as reliability testing.
During this test, testers can observe this sprint or software is recovery
from abnormal stage to normal stage or not.
h. SOA Testing*
SOA transfers for service for service oriented architecture. During SOA
testing, testers can operate sprint to share data from other software’s.
This testing is also called as intersystem testing or end to end testing
or Interoperability testing or API (Application programming interface)
testing or web services testing.
2) Non-Functional Testing
After completion of functional testing, testers can concentrate on non-functional
testing. During this test, testing team can concentrate on customer expectations
during non-functional testing. Due to this reason non-functional testing is called
as expectations testing.
Here testers can expect a complete sprint without driver & stubs to conduct non-
functional testing. Due to this reason non-functional testing is also called as
system testing.
In general non-functional testing can validate characteristics of software like
usability, performance, security, comparability…etc. Due to this reason non-
functional testing is called as characteristics testing.
Non-functional testing divided into below sub test such as:

a) Usability Testing:
This testing is also called as accessibility testing.
During this test, testers can concentrate on below factors.
Ease of Use
Look and Feel User friendliness
Short Navigations
b) Comparability Testing:
This testing also called as portability testing.
During this test, testers can operate corresponding sprint in various
customer expected platforms. Here platforms mean browser,
operating system and other system software’s.
c) Hardware configuration Testing:
This testing is also called as hardware comparability testing.
38
During test, testers can operate corresponding sprint in various
hardware configuration.
EX: Lunch a website in computer in mobile.
d) Performance Testing:
Performance means speed in processing.
During performance testing, we can conduct below subtest, such as
 Load Testing
 Stress Testing
 Spike Testing
 Endurance Testing
 Load Testing:
The execution of sprint or software in customer expected environment and by
applying customer expected load (load means NO: of concurrent Users) to
estimate speed in process is called load testing.
 Stress Testing:
applying more than customer expected load to identify peak load, is called
as stress testing or Load capacity testing.
 Spike Testing:
applying huge load to identify crashing point, is called as spike testing.
 Endurance Testing:
applying customer expected load iteratively/continuously long time to
identify memory leakage is called as endurance testing or durability testing or
soak testing or longuity testing.
e) Security Testing:
This testing is also called as penetration testing during this test,
testing people can concentrate on below sub tests.
 Authorization/Authentic Testing:
It’s means whether sprint or software is allowing valid user and preventing invalid
user or not?
Ex: Login, swiping, finger print, digital signature, eye detection… etc.
 Access Control Testing:
Its means whether a valid user have permission to access functionalities in sprint
or software?
 Encryption/Decryption Testing:
It’s means whether encryption/decryption process in sprint or software is strong
or not?
39
Note: To Conduct Encryption/decryption testing, Hacking knowledge is mandatory for
testers.
f) MultiLanguity Testing:
This testing is also called as foreign languages testing. During this
test, testing people can follow any one of two ways when
corresponding sprint or software developing using java Unicode or
.net Unicode..Etc.
g) Parallel Testing:
This testing is also called comparison or competitiveness
testing.
During this test, testers can compare corresponding sprint or
software with other competitive product in market to identify
weakness and strengths.
40
 This testing is need for product based software or sprint.
h) Compliance Testing:
This testing is also called as standard testing.
During this test, testing people or validate by scrum master and
Product Owner with respective to company standards.
Ex1:15 to 20 test scenarios with cases preparation per day (8
hours).
EX2:10 to 15 test scenarios with cases execution per day (8
hours).
Ex3:3 to 5 defects detected per day (8 hours).
V. Acceptance Testing
After completion of 30 days sprints cycles, project management can conduct
sprint review meeting. During this meeting management, including developers
and tester can try to collect feedback from customer and stakeholders. This
acceptance testing is in two ways.
α-Test β-Test
Invite customer and provide demo Release trail version of sprint or
on sprint or software software to customer and collect and
collect feedback via emails.
Yellow-box techniques
 If feedback is not good developer can changes sprint or software and testers can
test those changes.
VI. Release Testing

Project management can select few developers and testers for to goto customer
site for sprint or software release. The selected people for release are called as
release team or onsite team or delivery team or deployment team.
This team can perform below observation in customer site:
Complete installation.
Overall functionality.
Input devices support.
Ex: keyboard, Mouse, Joystick…etc.
Output devices support.
Ex: Monitor, Printer…etc.
Secondary storage devices support.
Ex: External hard disk, Pen drive, CD-ROM…etc.
OS support.
CO-existence with other software’s.
Green-box techniques
After completion of release testing, onsite team can provide training to end user
(Customer site people).
And then onsite team back to company and then concentrate on next sprint or
next project.
41
VII. Testing during Maintenance
While utilizing sprint or software, customer site people can send change request
to handle those change request, project management can form a fresher’s team
called as change control board.
Case Study:
42
Lesson 4
STLC: (Software testing life cycle)
In my company testing process is start with test initiation in test initiation PO prepare
optimal test strategy document based on test strategy scrum master prepare daily
planning activities, depends on daily activities prepare test design(like scenarios
,cases,..) . Developers send sprint and once we receive sprint start the test execution for
sprint. If sprint any defect is come, this defect maintain in test report and assign back to
developer. Once developer fix bug and retest the modify bug, it’s cycling process of in
between developers and testers. If sprint doesn’t have any defect we decide that sprint
is close/closure.
 From the above STLC, corresponding PO, SM and Scrum team can integrate SDLC
processor with STLC process.
43
I. Test Initiation:
In general testing process can start with test initiation, in this stage, PO can
prepare a strategy document for testers. In general strategies are 3 types such
as Exhaustive, Optimal, Ad-hoc, from testing principles, exhaustive testing is
impossible. Ad-hoc testing is not reasonable. Due to this reason PO can goto
select optimal test strategy for every sprint or software testing.
Example:
44
Exhaustive Optimal Ad-hoc
16 √ 15 X 16 √
17 √ 16 √ 60 √
18 √ 17 √
19 √ 59 √
: 60 √
: 61 X
20 √
Test with all values Test with some values Test with few values
(Form by using black-box (no technique)
testing techniques)
 In this stage, PO can prepare optimal test strategy document for testers like
shown below.
Optimal test strategy in IEEE829 format

1. Test strategy ID:
The identify Number of strategy document for future
reference.
2. Scope and objective:
The importance of testing in current sprint.
3. Business issues:
Budget allocation to testing.
Example:
4. Test responsibility matrix(TRM):

This selection of functional and non-functional testing topics.
Example TRM:
Sprint/Software Yes/No Comments
Testing topics
Functional Testing Yes _________
(8-topics)
Usability Testing Yes __________
Comparability Testing Yes _______________
45
Performance Testing Yes ________
Hardware Configuration No Lack of resource

Security No Lack of skill to testing
Multi-Langutiy Testing No No requirement for
Unicode
: : :
: : :
5. Roles and Responsibilities:
PO is responsible to hierarchy for testers.
Role Responsibilities
(as per testing)
SM  Prepare test plan
 Conduct review meeting
 Coordinate in between testers and developers
Senior Tester  Prepare test scenarios, cases and data
(QA Eng)  Involve in defect tracking
 Guide junior testers in test execution
Junior Tester  Execute test cases on sprint or software build
(QC Eng)  Report defect to developers
 Automate test cases if required using selenium…etc
QA  Quality Assurance (Test design)
QC  Quality Control (Test execution)
6. Test automation and Testing tools:

Po can decide need for automation in current sprint or
software testing.
7. Defect reporting and Tracking:

Po is responsible to define defect reporting and tracking
process in between developers and testers.
46
8. Communication and status reporting:
PO responsible to conduct daily scrum meet to maintain
good relation between developers and testes.
9. Configuration management and Test management:

Po responsible to specify location for developers and testers
to store their deliverables.
 From the above diagram, development base folder is useful to store developers
developed deliverables like product backlog, sprint backlog, HLD,LLD’s , source
code , unit test case, integration test case …etc.
 Test base folder is useful to store testers developed document, test strategy, test
plan, test scenarios, test cases, test data and automation scripts, traceability
matrix, sprint burn down chart… etc.
 Sprint base folder is useful to store all sprint build upload by developers download
by testers.
10.Testing measurements and metrics:
47
PO is responsible to define measurements and metrics to
improve effectiveness of testers during testers.
Example:
15 to 20 scenarios cases preparation for day
10 to 15 scenarios cases execution for day PO
3 to 5 defect detected for day
10 to 15 scenarios cases automated for day
11.Training Plan:
PO is responsible to decide need for training testers to
understand corresponding sprint or software requirements
or user stories.
Note1: Po can prepare test strategy like shown above by using MS word or Open office
word.
Note2: Po can get approval on above like strategy from stakeholders.
Note3: Po can save above like test strategy document in configuration repository of
server computer for future reference.
II. Test Planning

After completion of test initiation for Product Owner, corresponding scrum master
can prepare test plan document by following IEEE829.
a. Team level changes if required:

In general test planning process can start with team level changes if
required. As per sprint backlog user stories, team level changes were
48
needed some times with respect to complexity in those user stories. So
the selection of user stories for sprint depends on size of user stories,
importance of user stories (Priority) and complexity in user stories to finish
selected user stories development and testing in 30 days, scrum master
can try to change team size if required.
Type of Software/ Sprint Development : Testers

Client/server and web based
software(banking, Insurance, Health 3:1
care, Logistics…etc
Network related embedded
(Hardware related and telecom 1:1
software)
Artifacts intelligence software and
expert systems 1:7
(robotics, health equipment ,
satellites, Aeronautical)
b. Identify Tactical Risks:

After completion of team level changes scrum master can concentrate on
risks identifications.
Example:
 Lack of times
 Lack of resources
 Lack of documentation
 Lack of skills
 Lack of communication
 Delay in delivery (Unexpected problem)
 Lack of seriousness to developers
 Sudden changes in user stories/Requirements
c. Prepare Test plan:
After completion of team level changes and risks identification,
corresponding scrum master can prepare test plan document like shown
below:-
1. Test Plan document:
Unique number or name for feature reference.
2. Introduction:
The about current sprint or software.
What to Test?
3. Features or Modules:
List of all modules in current sprint or software
4. Feature not to be tested:
Features already tested in pervious sprint.
5. Features to be tested:
Features yet to test in current sprint.
How to test?
6. Test strategy:
Attach test strategy given by product owner.
Strategy is a part of plan.
49
7. Test Environment:
Required hardware and software for testers in current sprint
software test.
8. Test Deliverables:
List of document to be prepared by testers in current sprint
or software testing.
Example: Test scenarios, Test cases, Test data, Defect
reports, Automation script, and sprint burn down chart and
traceability matrix.
9. Entry Criteria: (To start test execution)
 Test design completed.
(Test scenarios, Cases and test data)
 Test environment established.
 Sprint Build released from developers.
10. Suspension criteria: (To interrupt testing)
 Test environment abounded.
 Major bug in sprint (Show stopper)
 More minor bugs in pending (Quality gap)
11. Exit Criteria:
 Test duration excided.
 All Major closed.
 All reasonable tests finished.
What to test?
12. Staff:
Names of testers in scrum team.
13. Responsibility:
Scrum master can allocate work to testers in two ways such
as modules wise allocation and topics wise allocation
When to test?
14.Schedule:
Dates and time for testers.
Example: 30 days schedule for current sprint.
50
15. Risks and Assumptions:
List of previously analyze risks and solution to overcome
those risks.
16. Approvals:
Signatures of scrum master, Product owner, Stakeholders.
Note1: Scrum master can follow above like test plan document format while preparing
test plan for each sprint or software testing. The above format is in IEEE829 format.
Note2: Test plan document preparation by specifying entry criteria, suspension criteria,
exist criteria is mandatory active for scrum master in every sprint test life cycle.
Note3: Test plan document classified four parts such as:
1. What to test?
2. How to test?
3. Who to test?
4. When to test?
d. Review test plan:
After completion of test plan document preparation corresponding scrum
master can take approval from product owner and stake holders on that
plan. Sometimes scrum master can change plan with respective
suggestion of product owner and stakeholders and request from scrum
team testers.
III. Test design

After completion of test planning corresponding testers in scrum team can start
test design by writing test scenarios, test cases and test data for responsible
module.
a. Study all user stories in sprint backlog(SBL):

Sprint backlog is part of product backlog, testers responsible modules are part of
sprint backlog.
51
But specific testers need to understand all user stories in sprint backlog or
product backlog.
b. Prepare test scenarios and test cases for responsible user stories:
From testing principles exhaustive testing impossible, Ad-hoc testing is not
reasonable due to this reasons testers can prepare test scenarios and cases for
responsible modules optimal testing. Here testers can follow black-box
testing techniques and IEEE829 standard format to prepare optimal test
cases for responsible modules.
 Black-Box testing techniques:

To prepare optimal scenarios and cases for responsible modules functional
testing, every tester can follow black box testing techniques or closed-box testing
techniques.
52
From the above diagram no techniques are available for non functional testing scenarios
and cases writing. While writing scenarios and cases for functional testing tester can use
black-box techniques like shown below:
 BVA, Boundary values analysis techniques is used to write test cases on size of
inputs and outputs.
Examples: from user stories, userid can take 4 to 16 positions long data BVA
(size of userid).
Min  4 Pos  valid
Min-1  3 Pos  invalid
Min+1  5 Pos  valid
Max  16 Pos  valid
Max-1  15 Pos  valid
Max+1  17 Pos  invalid
 ECP, equivalence classes’ partitions techniques is used to write test cases on

type of inputs and outputs.
Example: From user stories, user id can take alphanumeric in lower case.
Valid Invalid
 Alphanumeric in lowercase  Alphabet in upper case
 Special chars
 Blank field
 DT, decision table techniques is used to prepare test cases related to mapping in
between inputs and outputs.
Examples: From user stories, next page will come for valid userid and valid
password and error message any one is invalid in login.
Inputs Outputs
Userid Password Expected output
Valid Valid Next page
Invalid Valid Error message
Valid Invalid Error message
Invalid Invalid Error message
Blank field Fill Error message
Fill Blank field Error message
Blank field Blank field Error message
Remove test case repetition in test case

Orthogonal arrays
53
Orthogonal arrays(OA):
 OA, we can this technique to remove repetition in test cases.
 STF, state transition flow techniques is used to write test cases in order with
respective to functionality.
 EG, error guessing Technique is used to guess defect in upcoming sprint or

software depends on past experience.
Note: BVA
ECP Write test cases
DT
OA* Remove repetition in test cases
STF Arrange test cases in order
EG Guess defect without running cases on sprint or software
Test cases document format in IEEE829

Test Test Test Priority Test Test Procedure
Cases Scenario Suite Setup/ Step Step Test Expected
Doc ID Test No Description Cases Output
ID Environment
 From the above format, activity to be tested is called as test scenario. A condition
to be used while testing in scenario is called as a test case.
So, one software means multiple sprints. One sprint means multiple modules.
One modules testing means applying multiple test scenarios. One scenario means
applying multiple test cases. One case means one condition.
 In above test cases document format test cases document ID is useful to refer
documents in feature. Test ID is useful to group related scenarios and cases.
 *Priority is used to specify importance of test cases.
Example: Functional test cases  High
Non-functional test cases  Medium
Usability test cases  Low
 While preparing test cases for functional testing we can use test step to specify
necessary conditions.
 While preparing test cases for non-functional testing we can use “test
environment” to specify required hardware and software.
 Test procedure useful to write step by step process with test cases for every
scenario.
54
Case study (Online Insurance system)
User story1:- (IEEE830)
User story ID AS a I would like to So that Acceptance criteria
US_Registration New Launch OIS site If all fields Registration page
user Click register link filled with must be user friendly
in home page valid data
Fill first name, we can get Run on various type
which is alphabet as login page. of browsers and
one word operating system.
Fill last name, If any field
which is alphabet as is blank or Like
one word invalid, error IE/Chrome/Firefox/
Fill email id, w.r.t message will Opera/Safari
W3C rules come Windows
Fill mobile XP/Vista/7/8/10/2003
number, which is server/2008
valid in India server/Linux red hut
Fill address field, and Mac
which allow
alphanumeric along 1000 users can use
with /-, and space register at time
in middle
Fill user id, which need to run in hub,
is alphanumeric Ring and Bus
lowercase from 4 to topology networks
16 position long
Fill password
which is alphabet in
lower case from 4
to 8 position long
 Fill confirm
password, which
value equal to
password value
Click submit
button
Requirement Expectations
(Functional testing) (Non-Functional Testing)
Q) Prepare test scenarios cases for registration module functional

testing in OIS?
55
Test cases document (IEEE829)
Test Cases Test Scenario Test suite ID Priority Test setup Test procedure
doc ID Step Step Test cases Expected
no description output
TCD_OIS_FT Validate register link TS_register_1 High OIS site 1 Launch OIS None Home page
_Anil_28thm by clicking in home home page site will be opened
arch16_1 page is ready to 2 Click link Register link Registration
open page will be
opened
Other link Registration
page will not
be open
TCD_OIS_FT Validate first name TS_register_2 High OIS site 1 Launch OIS None Home page
_Anil_29thm field in registration home page site will be opened
arch16_2 page is ready to 2 Click register None Registration
open link page will be
opened
3 Fill first name 1 char Accepted
field Blank field Rejected
2 chars Accepted
256 chars Accepted BVA
255 chars Accepted
257 chars Rejected
Alphabet Accepted
Numeric Rejected ECP
Special chars Rejected
TCD_OIS_FT Validate last name TS_register_3 High OIS site 1 Launch OIS None Home page
opened
3 Fill Last name 1 char Accepted
2 chars Accepted
256 chars Accepted
56
255 chars Accepted
257 chars Rejected
Alphabet Accepted
Numeric Rejected
TCD_OIS_FT Validate email id field TS_register_4 High OIS site 1 Launch OIS None Home page
_Anil_29thm in registration page home page site will be opened
arch16_4 is ready to 2 Click register None Registration
opened
3 Fill email id 7 positions Accepted
field 6 positions Rejected
8 positions Accepted
257 positions Rejected
For userid Accepted
alphabet
numeric - _ .
#$
For site name, Accepted
alphabet
numeric -
For site type , Accepted
alphabet
For zone , Accepted
alphabet
Blank Rejected
field/email id
empty
@ and . Accepted
between
userid, site
name, site
type and zone
57
TCD_OIS_FT Validate mobile TS_register_5 High OIS site 1 Launch OIS None Home page
_Anil_29thm number field in home page site will be opened
arch16_5 registration page is ready to 2 Click register None Registration
opened
3 Fill mobile 10 digits Accepted
number field 9 digits Rejected
11 digits Accepted
12 digits Accepted
13 digits Rejected
For 10 digits, Accepted
numeric
numeric with
first as 0
numeric with
9 and 5 at
starting
Alphabet Rejected
Blank field Rejected
TCD_OIS_FT Validate Address field TS_register_6 High OIS site 1 Launch OIS None Home page
_Anil_29thm in registration page home page site will be opened
opened
3 Fill Address 1 positions Accepted
Alphanumeric Accepted
with / - . and
blank space
58
/ - and blank
space
TCD_OIS_FT Validate Userid field in TS_register_7 High OIS site 1 Launch OIS None Home page
_Anil_29thm registration page home page site will be opened
opened
3 Fill userid field 4 positions Accepted
Alphanumeric Accepted
in lowercase
Alphabet in Rejected
upper case
Special char Rejected
TCD_OIS_FT Validate Password TS_register_8 High OIS site 1 Launch OIS None Home page
opened
3 Fill password 4 chars Accepted
field 3 chars Rejected
5 chars Accepted
8 chars Accepted
7 chars Accepted
9 chars Rejected
Alphabet in Accepted
lowercase
Alphabet in Rejected
uppercase
Numeric Rejected
59
TCD_OIS_FT Validate Confirm TS_register_9 High OIS site 1 Launch OIS None Home page
_Anil_29thm Password field in home page site will be opened
arch16_9 registration page is ready to 2 Click register None Registration
opened
3 Fill password None Confirm
password field
will be
activated
4 Fill confirm Equal to Accepted
password field password
Not equal to Rejected
password
TCD_OIS_FT Validate registration TS_register_1 High OIS site 1 Launch OIS None Home page
_Anil_30thm operation by clicking 0 home page site will be opened
arch16_10 “submit” button is ready to 2 Click register None Registration
opened
3 Fill fields and All fields filled Login page will
click “submit” with valid data be opened
button Any one field Error message
filled with will be
invalid data appeared
Any one field Error message
is blank field Will be
appeared
60
W3C Rules on email id:*
 W3C transfer world wide web consortium
Example: a@b.com  minimum 7 Position
Maximum 256 Positions
 Minimum size is 7 positions to maximum size 256 positions.

 4 blocks in email id i.e. userid, site name, site type and zone.
 Zone is optional
 Test scenario is not scientific, it is a artistic
Characteristics of testers
 Domain knowledge (Like understand user stories)
 Testing knowledge
 Programming knowledge
Using regular expression in test design

To write test scenarios, test cases in short form, tester can use mathematical notations
called as regular expression.
[ ]  one position (Char /digits)
[a-z]  one alphabet in lower case
[0-9]  one digit
[A-Z]  one alphabet in upper case
[a-zA-Z]  one alphabet (either upper/lower)
[0-9a-zA-Z _ ]  one alphabet/digit/_
[.]
[.$]  one alphabet/digit/_/$
[7-9]  one digit, which is 7 or 8 or 9
[^0-6]
61
[q-z]  One alphabet in lower case, which is any one in q to z
[^a-p]
[Q-Z]  one alphabet in upper case, which is in Q TO Z
[^A-P]
[^_ ]  Any special char except _
[A-Z][a-z]  two positions with first as upper case and next as lower case
[A-Z][a-z][ .]  three positions with first as upper case, second as lower case and third
as alphabet in any case/digit/_
[09-]  one position, which is 0 or 9 or –
[a-z][a-z]  two positions, both are lower case alphabet
[a-z]{2}
Regular expression for pan card number

[A-Z]{5}[0-9]{4}[A-Z]  10 positions with first 5 positions are upper case alphabet,
next 4 positions are digits and last is upper case alphabet
Regular expression for mobile number in India

[0-9]{10}  10 digits number
[0][0-9]{10}  11 digits number, but start with 0 only
[9][5][0-9]{10}  12 digits number, but first as 9 and second as 5
[A-Z][A-Za-z0-9]{9}  10 positions data, with first as upper case alphabet and

remaining are alphanumeric
[A-Z][A-Za-z0-9]{8}[a-z]  10 positions with first as upper case alphabet last as lower

case alphabet and middle remaining are alphanumeric
[A-Z][1 3 5 7 9]{8}[a-z]  10 positions with first as upper and last lower and middle
remaining are odd digits.
([a-z][A-Z]){5}  10 positions with upper case in even position lower case in odd
position
Example:
[A-Z][.]{8}[0-9]  10 positions with first as upper, last as digit and middle remaining
are alphanumeric with _
62
[0-9]{4,6}  A number from 4 digits long
[A-Z][a-z]{3.5}  4 to 6 positions data with first as upper case and remaining are lower
[A-Z][a-z]{3,5}[0-9]  5 to 7 positions with first as upper case last as digit and middle
remaining are lower case
[A-Z][a-z0-9]{4,10}  5 to 11 positions with first as upper case and remaining are

lower case alphanumeric
[0-9]{1,}  one digit to infinite no: of digits number
[0-9]+
[0-9]{0,}  no digit to infinite no: of digits number
[0-9]*
[0-9]{0,1}  no digit or one digit
[0-9]?
[a-zA-Z]+  One or more alphabet
[\w] (One word)
[\w][\s][\w]  two words separated by space
Blank space
([\w][\s]?){1,}[\.]  Sentence
Full stop
Example
(([\w][\s]?){1,}[\.][\s]){1,}  paragraph
([\w][\s]?){1,}[\.]  one sentence in alphabet only
[\s]  one blank space
[\.]  One . (Full stop)
^  Not/except
|  Or
63
Regular expression for email
User id [a-zA-Z0-9_-#$\.]
[.]
[. -#$\.]+[@][a-zA-Z0-9-]+[\.][a-zA-Z]+([\.][a-zA-Z)+){0,1}
With sizing for site type
[.-#$\.]+[@][a-zA-Z0-9-]+[\.][a-zA-Z]{2,4}([\.][a-zA-Z]{2}){0,1}
Full stop/Period
Alphanumeric with _
64
User Story 2
User story As a I would like to So that Acceptance criteria

ID
Us_Login Existing user Launch OIS site, click login button to get For valid data options page Registration page
login page, Enter userid, which can take 4 to will be opened must be user friendly
16 positions
Alphanumeric in lowercase. For invalid data error message Run on various type
will be appeared of browsers and
Enter password, which can take 4 to 8 operating system.
positions alphabet in lower case click ok
button Like
IE/Chrome/Firefox/
Opera/Safari
Windows
XP/Vista/7/8/10/2003
server/2008
server/Linux red hut
and Mac
1000 users can use

register at time
need to run in hub,

Ring and Bus
topology networks
Q) Prepare test scenarios and cases for login module functional testing in OIS site?
65
Test Cases Test Scenario Test suite Priority Test Test procedure
doc ID ID setup Step Step Test cases Expected
TCD_OIS_FT Validate register link by TS_Login_1 High Home 1 Launch OIS None Home
_Anil_31thm clicking in home page page is site page will
arch16_11 ready to be opened
Launch 2 Click link Login Login
page will
be opened
Other Login
page will
not
opened
TCD_OIS_FT Validate user id field login page TS_Login_2 High Home 1 Launch OIS None Home
_Anil_31thm page is site page will
Launch 2 Click Login None Login
page will
be opened
3 Fill userid 4 positions Accepted
16positions Accepted
17positions Rejected
[a-z0-9] Accepted
{4,16}
[A-Z] Rejected
Special Rejected
chars
TCD_OIS_FT Validate password field in login TS_Login_3 High Home 1 Launch OIS None Home
_Anil_31thm page page is site page will
Launch 2 Click Login None Login
page will
66
be opened
3 Fill password 4 positions Accepted
[a-z]{4,8} Accepted
[A-Z] Rejected
Special Rejected
chars
TCD_OIS_FT Validate login operation by TS_Login_4 High Home 1 Launch OIS None Home
_Anil_31thm clicking “ok” button page is site page will
Launch
and have 2 Click Login None Login
valid user page will
id and be opened
correspon
ding
password 3 Fill fields and All fields Options
click “OK” filled with page will
valid data be opened
Any one Error
field filled message
with invalid will be
data appeared
Any one Error
field is message
blank field will be
appeared
67
User story 3
User story As a I would like to So that Acceptance criteria
ID
Us_PC Existing user Launch OIS site For valid policy creation Registration page
(Policy) Click login to get login page successful message will be must be user friendly
Do login by using valid data appeared
Click policy creation link in options page Run on various type
Enter policy holder name, which is For invalid policy creation of browsers and
alphabet in one or more words error message will be appeared operating system.
Select policy duration, which consist of 20
years, 15 years, 10 years and 5 years as Logout always provide in Like
items and here 5 years is default homepage IE/Chrome/Firefox/
Select payment duration, which consist of Opera/Safari
monthly, quarterly, half-yearly and yearly, Windows
here yearly is default XP/Vista/7/8/10/2003
Enter premium amount, which is in server/2008
between 1500 to 100000(1lakh) server/Linux red hut
Select payment type, which consist of net and Mac
banking and credit card
If net banking, we need to enter customer 1000 users can use
id, password including bank name selection. register at time
Bank name consist of HDFC, ICICI, SBI and
KVB need to run in hub,
If bank name is HDFC customer id is 8 Ring and Bus
digits and password is alphanumeric from 4 topology networks
to 16 positions
if bank name is ICICI, customer id is 10
digits but doesn’t end with zero, password is
alphanumeric with _ from 4 to 16 positions
If bank name is SBI, customer id is 10
digits but doesn’t start with odd and but
doesn’t end with even and password is
alphanumeric with _ # ? from 4 to 16
positions
If bank name is KVB, customer id is 8
digits but doesn’t start and end with zero
68
and password is alphanumeric in lower case
from 4 to 16 positions
If we selected credit card as payment
type, we need to select credit card type,
enter card number, enter CVV value, select
expire month, expire year and enter
password
If card type list consist of VISA, master
and American express and VISA is default
If card type is VISA/Master/AE, card
number is 16 digits, CVV is 3 digits, expiry
month is 01 to 12, expiry is alphanumeric
with _ - # $ for 4 to 16 positions
Click “create” button to get successful
message for valid data and error message
for invalid data
Click logout at any time to back to
homepage
Q) Prepare test scenarios and cases for policy creation module functional testing in OIS?
Test Cases Test Scenario Test suite Priority Test setup Test procedure
doc ID ID Step Step Test cases Expected
TCD_OIS_FT Validate “Policy TS_PC_1 High Home page is 1 Launch OIS None Home page
_Anil_1st Creation” link by ready to site will be
April16_15 clicking in optional page Launch and opened
have valid 2 Click Login None Login page
userid and will be
corresponding opened
password to 3 Do login by None Options page
do login using valid will be
userid and opened
password
69
4 Click link Policy Policy
Creation creation page
will be
opened
Other Policy page
will not be
opened
TCD_OIS_FT Validate “Policy Holder TS_PC_2 High Home page is 1 Launch OIS None Home page
_Anil_1st Name ” field in policy ready to site will be
April16_16 creation page Launch and opened
userid and will be
password in 3 Do login by None Options page
hand using valid will be
userid and opened
password
4 Click PC link None PC page will
be opened
5 Fill Policy 1 char Accepted
holder name Blank field Rejected
2 chars Accepted
256 char Accepted
255 char Accepted
257 char Rejected
([\w][\s]?) Accepted
{1, }
[0-9] Rejected
[^ \s] Rejected
TCD_OIS_FT Validate Policy Duration TS_PC_3 High Home page is 1 Launch OIS None Home page
_Anil_1st selection in policy ready to site will be
userid and will be
70
userid and opened
password
be opened
5 Select policy 5 years 5 years will
duration be
highlighted
10 years 10 years will
be
highlighted
be
highlighted
be
highlighted
No one 5 years will
selected be
highlighted
TCD_OIS_FT Validate Payment TS_PC_4 High Home page is 1 Launch OIS None Home page
_Anil_1st Duration selection in ready to site will be
April16_18 policy creation page Launch and opened
userid and will be
userid and opened
password
be opened
5 Select Monthly Monthly will
payment be
duration highlighted
71
Quarterly Quarterly will
be
highlighted
Half-yearly Half-yearly
will be
highlighted
Yearly Yearly will be
highlighted
No one Yearly will be
selected highlighted
TCD_OIS_FT Validate Premium TS_PC_5 High Home page is 1 Launch OIS None Home page
_Anil_1st amount field in policy ready to site will be
userid and will be
userid and opened
password
be opened
5 Fill premium 1500 Accepted
amount field 1499 Rejected
1501 Accepted
1,00,000 Accepted
99,999 Accepted
1,00,001 Rejected
[a-zA-Z] Accepted
Special Rejected
chars
TCD_OIS_FT Validate “Payment type” TS_PC_6 High Home page is 1 Launch OIS None Home page
_Anil_1st selection in policy ready to site will be
72
userid and will be
userid and opened
password
be opened
5 Select Net Net banking
payment banking will be
type highlighted
including
bank name,
customer id
and
password will
be enabled
Credit card Credit card
will be
highlighted
including
card type,
card number,
CVV number,
expiry
month,
expiry year
and
password will
be enabled
No one Blank field
selected
TCD_OIS_FT Validate “Bank name” TS_PC_7 High Home page is 1 Launch OIS None Home page
_Anil_1st selection when payment ready to site will be
April16_21 type is net banking Launch and opened
73
userid and will be
userid and opened
password
be opened
5 Select None Net banking
payment will be
type as net highlighted
banking and bank
name,
customer id
and
password are
enabled
6 Select bank HDFC HDFC will be
name highlighted
ICICI ICICI will be
highlighted
SBI SBI will be
highlighted
KVB KVB will be
highlighted
No one Blank field
selected
TCD_OIS_FT Validate Customer id TS_PC_8 High Home page is 1 Launch OIS None Home page
_Anil_1st field when payment ready to site will be
April16_22 type is net banking Launch and opened
userid and will be
74
userid and opened
password
be opened
payment will be
banking and bank
name,
customer id
and
password are
enabled
6 Select bank None Customer id
name will be
focused
7.1 Fill customer 8 digits Accepted
id when 7 digits Rejected
bank name 9 digits Rejected
is HDFC [0-9]{8} Accepted
[a-zA-Z] Rejected
Special Rejected
chars
is ICICI [09]{9} Accepted
[1-9]
[a-zA-Z] Rejected
Special Rejected
chars
75
is SBI [0 2 4 6 8] Accepted
[0-9]{8}
[1 3 5 7 9]
[a-zA-Z] Rejected
Special Rejected
chars
is SBI [^0][0-9] Accepted
{6}[^0]
[a-zA-Z] Rejected
Special Rejected
chars
TCD_OIS_FT Validate Password field TS_PC_9 High Home page is 1 Launch OIS None Home page
_Anil_1st when payment type is ready to site will be
April16_23 net banking Launch and opened
userid and will be
userid and opened
password
be opened
payment will be
banking and bank
name,
customer id
and
password are
76
enabled
6 Select bank None Customer id
name will be
focused
7.1 Fill password 4 positions Accepted
when bank is 3 positions Rejected
HDFC 5 positions Accepted
[a-zA-Z0- Accepted
9]{4,16}
Special Rejected
chars
ICICI 5 positions Accepted
[.]{4,16} Accepted
[^ _ ] Rejected
SBI 5 positions Accepted
[. # ?] Accepted
{4,16}
[^ _ # ?] Rejected
77
KVB 5 positions Accepted
[a-z0-9] Accepted
{4,16}
[A-Z] Rejected
Special Rejected
chars
TCD_OIS_FT Validate “Card type” TS_PC_10 High Home page is 1 Launch OIS None Home page
_Anil_2nd when payment type is ready to site will be
April16_24 credit card Launch and opened
userid and will be
userid and opened
password
be opened
5 Select None Credit card
payment will be
type as highlighted
“Credit card” and card
type, card
number, CVV
Number,
Expiry
month,
Expiry yea
and
password will
be enabled
78
6 Select card VISA VISA will be
type highlighted
Master Master will
be
highlighted
AE AE will be
highlighted
No one VISA will be
selected highlighted
TCD_OIS_FT Validate Card number TS_PC_11 High Home page is 1 Launch OIS None Home page
_Anil_2nd field when payment ready to site will be
April16_25 type is credit card Launch and opened
userid and will be
userid and opened
password
be opened
payment will be
type as highlighted
type, card
number, CVV
Number,
Expiry
month,
Expiry yea
and
password will
be enabled
6 Select card None Card number
type will be
79
focused
7 Fill card 16 digits Accepted
when card 17 digits Rejected
type is any [0-9]{16} Accepted
Special Rejected
chars
[a-zA-Z] Rejected
TCD_OIS_FT Validate CVV number TS_PC_12 High Home page is 1 Launch OIS None Home page
_Anil_2nd field when payment ready to site will be
userid and will be
userid and opened
password
be opened
payment will be
type as highlighted
type, card
number, CVV
Number,
Expiry
month,
Expiry yea
and
password will
be enabled
type will be
80
focused
7 Fill CVV 3 digits Accepted
when card 4 digits Rejected
type is Any [0-9]{3} Accepted
[a-zA-Z] Rejected
Special Rejected
chars
TCD_OIS_FT Validate “Expiry month” TS_PC_13 High Home page is 1 Launch OIS None Home page
_Anil_2nd selection when payment ready to site will be
userid and will be
userid and opened
password
be opened
payment will be
type as highlighted
type, card
number, CVV
Number,
Expiry
month,
Expiry yea
and
password will
be enabled
type will be
81
focused
7 Select expiry Select Selected item
month existing will be
item which highlighted
is in
between 01
to 12
No one Blank field
selected
TCD_OIS_FT Validate “Expiry year” TS_PC_14 High Home page is 1 Launch OIS None Home page
_Anil_2nd selection when payment ready to site will be
userid and will be
userid and opened
password
be opened
payment will be
type as highlighted
type, card
number, CVV
Number,
Expiry
month,
Expiry yea
and
password will
be enabled
type will be
82
focused
7 Select expiry Select Selected item
year existing will be
item which highlighted
is in
between
2000 to
2099
No one Blank field
selected
TCD_OIS_FT Validate Password when TS_PC_15 High Home page is 1 Launch OIS None Home page
_Anil_2nd payment type is credit ready to site will be
April16_29 card Launch and opened
userid and will be
userid and opened
password
be opened
payment will be
type as highlighted
type, card
number, CVV
Number,
Expiry
month,
Expiry yea
and
password will
be enabled
83
type will be
focused
7 Fill password 4 positions Accepted
field 3 positions Rejected
[. -#$] Accepted
{4, 16}
[^ _ -#$] Rejected
TCD_OIS_FT Validate Policy creation TS_PC_16 High Home page is 1 Launch OIS None Home page
_Anil_2nd operation by clicking ready to site will be
April16_30 “create” button Launch and opened
userid and will be
password do opened
to login and 3 Do login by None Options page
have account using valid will be
details to do userid and opened
payment password
be opened
5 Fill fields and All fields Successful
click create filled with message will
valid data be appeared
w.r.t OIS
site
Database
and Bank
server
Database
Any one Error
filled with message will
84
invalid data be appeared
w.r.t OIS
site
Database
or bank
server
Any one Error
filled is message will
blank field be appeared
TCD_OIS_FT Validate logout by TS_PC_17 High Home page is 1 Launch OIS None Home page
_Anil_2nd clicking in Policy ready to site will be
userid and will be
password do opened
to login and 3 Do login by None Options page
have account using valid will be
details to do userid and opened
payment password
be opened
5 Click logout All fields Home page
In policy are empty will be
creation reopened
page Some fields Home page
are filled will be
reopened
All fields Home page
filled will be
reopened
After Home page
getting will be
error reopened
message
After Home page
getting will be
85
successful reopened
message
Usability Test design

After completion of testing scenarios and test cases writing for functional testing, corresponding tester can concentrate on non-functional
test design. Here usability test design can concentrate on condition to be applied to validate user friendliness of sprint or software.
In this usability test design, testers can consider scenario and case both are same. From user stories, every PO can specific user
friendliness exception for any sprint or software. But while writing scenarios or cases for usability testing, every tester depends on past
experience and end user adaptations.
Depends on time box, tester can assign to low priority to usability scenario and cases
Example:
Test Cases Test scenario/case Test suite ID Priority

doc ID
TCD_OIS_NFT_ Validate spelling of labels in throughout pages of OIS site TS_UT_1 Low
Anil_3rd
April16_1
TCD_OIS_NFT_ Validate Initcap of labels in throughout pages of OIS site TS_UT_2 Low
Anil_3rd
April16_2
TCD_OIS_NFT_ Validate Meaning of labels in throughout pages of OIS site TS_UT_3 Low
Anil_3rd
April16_3
TCD_OIS_NFT_ Validate line space gap uniformness in between label and element in throughout page of TS_UT_4 Low
Anil_3rd OIS site
April16_4
TCD_OIS_NFT_ Validate line space gap uniformness in between elements in throughout page of OIS site TS_UT_5 Low
Anil_3rd
April16_5
TCD_OIS_NFT_ Validate alignment of elements in web pages of OIS site TS_UT_6 Low
Anil_3rd
86
April16_6
TCD_OIS_NFT_ Validate color contrast uniformness in throughout pages of OIS site TS_UT_7 Low
Anil_3rd
April16_7
TCD_OIS_NFT_ Validate font size uniformness in throughout pages of OIS site TS_UT_8 Low
Anil_3rd
April16_8
TCD_OIS_NFT_ Validate font style uniformness in throughout pages of OIS site TS_UT_9 Low
Anil_3rd
April16_9
TCD_OIS_NFT_ Validate visibility of formats for currency, date and time like elements in throughout TS_UT_10 Low
Anil_3rd pages of OIS site
April16_10
TCD_OIS_NFT_ Validate arrangement of elements with respective to functionality in throughout pages of TS_UT_11 Low
Anil_3rd OIS site
April16_11
TCD_OIS_NFT_ Validate matching in between icon symbols and corresponding TS_UT_12 Low
Anil_3rd
April16_12
TCD_OIS_NFT_ Validate matching in between icons and corresponding tool tips in throughout pages of TS_UT_13 Low
Anil_3rd OIS site
April16_13
TCD_OIS_NFT_ Validate meaning of error message with respective to error conditions raised in through TS_UT_14 Low
Anil_3rd pages of OIS site
April16_14
TCD_OIS_NFT_ Validate the availability of ‘ok’ and ‘cancel’ like buttons in throughout pages of OIS site TS_UT_15 Low
Anil_3rd
April16_15
TCD_OIS_NFT_ Validate the availability of status bar or progress bar like elements in throughout pages of TS_UT_16 Low
Anil_3rd OIS site
April16_16
TCD_OIS_NFT_ Validate the availability of system menu in throughout pages of OIS site(Restore, Move, TS_UT_17 Low
Anil_3rd Size, minimize, maximize, close)
April16_17
TCD_OIS_NFT_ Validate the availability of keyboard access on elements in throughout pages of OIS site TS_UT_18 Low
Anil_3rd
87
April16_18
TCD_OIS_NFT_ Validate the availability of scrolling pages in OIS site TS_UT_19 Low
Anil_3rd
April16_19
TCD_OIS_NFT_ Validate help document completeness and correctness in OIS site TS_UT_20 Low
Anil_3rd
April16_20
Note: The above like test scenario or cases are applicable all any of software usability testing.
After completion of usability test design, testers can concentrate on comparability design. From user stories of OIS site, we need to run
that site in various browsers and operating system like IE, Opera, Mozilla Firefox, chrome, safari, windows XP, vista, 7, 8, Linux red hat,
MAC
Comparability Test Scenario

Test Cases Test scenario Test Priority Test Test procedure
doc ID suit id environment Step Step Test cases Excepted
no description Result
TCD_OIS_NFT Validate registration TS_CT_1 Medium Browser are IE, 1 Launch OIS In specified Login page
_Anil_3rd operation in customer Opera, FF and site and test for valid
April16_21 expected platforms safari, OS are registration environment data and
windows error
XP/Vista/7/8/10 message for
Linux red hat, invalid data
MAC and
windows server
2008
TCD_OIS_NFT Validate login TS_CT_2 Medium Browser are IE, 1 Launch OIS In specified Options
_Anil_3rd operation in customer Opera, FF and site and do test page for
April16_22 expected platforms safari, OS are login environment valid data
windows and error
XP/Vista/7/8/10 message for
Linux red hat, invalid
MAC and
windows server
88
2008
TCD_OIS_NFT Validate Policy TS_CT_3 Medium Browser are IE, 1 Launch OIS In specified Successful
_Anil_3rd creation in customer Opera, FF and site, do login test message for
April16_23 expected platforms safari, OS are and perform environment valid data
windows policy and error
XP/Vista/7/8/10 creation message for
Linux red hat, invalid data
MAC and
windows server
2008
 After completion of test scenario and cases writing for comparability testing, we need to concentrate on hardware configuration
test design from OIS site use stories, OIS site need to run in hub, ring and bus topology networks.
Hardware configuration Testing
Test Cases Test scenario Test suit Priority Test Test procedure
doc ID id environment Step Step Test cases Excepted
TCD_OIS_NFT Validate registration TS_HCT_1 Medium Bus, Ring and 1 Launch OIS In specified For valid
_Anil_15th functionality in Hub topology site and do test networks data, next
May16_24 customer expected networks registration in test page will
89
environment environment come and
for invalid
data error
message
will come
TCD_OIS_NFT Validate login TS_HCT_2 Medium Bus, Ring and 1 Launch OIS In specified Next page
_Anil_15th functionality in Hub topology site and do test networks for valid
May16_25 customer expected networks login in test data and
environment environment error
message for
invalid data
TCD_OIS_NFT Validate Policy TS_HCT_3 Medium Bus, Ring and 1 Launch OIS In specified Successful
_Anil_15th creation functionality Hub topology site, do login test networks message for
May16_26 in customer expected networks and perform in test valid data
environment policy environment and error
creation message for
invalid data
 After completion of hardware comparability testing design, we need to prepare test scenarios and test cases for performance
testing form OIS site user stories, 1000 user can access site at a time
Performance Testing
Test Cases Test scenario Test suit Priority Test Test procedure
doc ID id environment Step Step Test cases Excepted
TCD_OIS_NFT Validate registration TS_PT_1 Medium 1000 real or 1 Launch OIS By applying Next page
_Anil_15th functionality by virtual users for site and do specified load for valid
May16_27 applying customer speed in registration levels in test data and
expected load levels process environment error
message for
more than invalid data
1000
real/virtual
user for peak
90
load
identification
Huge than
1000 virtual/
real users for
server crashing
point
1000 users
iteratively long-
time for
memory
leakage
TCD_OIS_NFT Validate login TS_PT_2 Medium 1000 real or 1 Launch OIS By applying Next page
_Anil_15th functionality by virtual users for site and do specified load for valid
May16_28 applying customer speed in login levels in test data and
expected load levels process environment error
message for
1000
real/virtual
user for peak
load
identification
Huge than
1000 virtual/
real users for
server crashing
point
1000 users
iteratively long-
time for
memory
leakage
TCD_OIS_NFT Validate Policy TS_PT_3 Medium 1000 real or 1 Launch OIS By applying Successful
_Anil_15th creation functionality virtual users for site, do login specified load message for
May16_29 by applying specified speed in and perform levels in test valid data
91
load process policy environment and error
creation message for
1000
real/virtual
user for peak
load
identification
Huge than
1000 virtual/
real users for
server crashing
point
1000 users
iteratively long-
time for
memory
leakage
92
*Note1:
In general testers in scrum team are responsible to use a test management tool to store
test scenario and cases in a securable database.
QC  Quality Center (HP)
ALM  Application lifecycle management
Note2:
After completion of scenarios and cases by using a test management tool (or) excel
software corresponding tester in scrum team can start the preparation of test data. In
general test data is two types such as real data and model data.
Example:
93
IV. Test Execution
After completion of test design (preparation of scenario, cases and data), corresponding
testers can concentrate on test execution. Here test execution is possible in two ways
such as manual testing and test automation.
Manual Testing Test Automation

Understanding user stories or requirements Understanding user stories or requirements
Prepare Test Scenarios, Cases and data Prepare Test Scenarios, Cases and data
Apply Test Cases on Sprint or software to Convert Test Cases into Test Script and run
94
detect defects those scripts on sprint or software detect
defects
 Why following manual or Automation or both, test execution process is able to

classify in below steps.
a) Formal meeting
In general test execution process can start with a formal meeting in between
developers and testers. In this meeting, developers and testers can discus three
factors.
 Sprint or software
 Defect Report
 Modified Sprint or software release
(Build Version control process)
In general developers can approach sprint or software to server computer in

company network. Testers can download or launch that sprint or software from
server to tester computer.
 If sprint or software is 1-tier or 2-tier windows based software, tester can

download and install that software or sprint in tester computer.
 If sprint or software is 3-tier or n-tier, tester can launch that sprint or software
using URL/URI.
In general tester can report to defect to developer through an email using ms-outlook,
lotus notes like mailing software’s or report defect using defect reporting tools like JIRA,
Bugzila, Bugtracker, mantis….etc.
In general, developers can release modify sprint or software by assigning new version
number.
95
b) Levels of Test Execution
After completion of formal meeting with developers corresponding tester can
concentrate on design levels of test execution.
96
c) Establish Test Environment
After completion of formal meeting with developers and clarification of level of test
execution, corresponding testers can sit with hardware team or infrastructure team to
establish test environment with required hardware and software.
Test bed or Test harness
d) Smoke Testing or Testability Testing or Verification Testing

This testing stage is also called build verification testing or testability testing or
tester acceptance testing.
In general tester can conduct smoke testing to ensure the corresponding sprint
build came from developers is working or not. Here tester and scrum master can
download launch corresponding sprint or software from server computer into one
97
cabin system into test environment and then, scrum master and testers can
execute a fixed step of positive functional cases on the sprint or software build to
ensure that build is working or not.
If corresponding sprint or software build is not working in test environment,
testers can reject that sprint for working sprint or software.
e) Real Testing
This stage of testing is also called as comprehensive testing. During this test,
tester can execute all test cases one after other on corresponding sprint or
software builds by comparing expected values in test cases and actual values of
sprint or software build.
If all test cases expected values are equal to corresponding actual value then
tester can stop test execution and concentrate on defect reporting.
f) Error, Defect, Bug, Failure

Error: A mistake in coding found by developer is called as error or flaw.
Defect: A mismatch in sprint or software found by tester is called as
defect/issue/Incident/Ticket.
Bug: A defect in software was accepted by developers is called bug.
Failure: A software problem raised in customer site called as failure or latent
bug.
g) Defect Report
During smoke testing, tester can reject sprint when sprint is not working. But in
real testing, tester can report defect to developer when that sprint or software is
not correctly working. Due to this reason defect means a mismatch in between
tester expectations and sprint or software actual to report to defect to developer,
tester can follow below IEEE829 format.
1. Defect ID: Unique number or name as title
98
2. Description: About detected defect
3. Build Version: Version number of build, in which this defect was detected
4. Feature or Module: Name of module in which this defect was detected
5. Failed Test case ID: ID of test case, in which execution this defect was detected
6. Reproduceable: yes/No,
7. If yes, attach test cases doc:

8. If No, attach test cases doc and screen shot
9. Severity: The seriousness of defect with respective to tester show
Stopper/high/critical Not able to continue further testing until fix this defect.
Ex: functional defects
Medium/Major able to continue testing, but mandatory to fix this defect Ex:
Non-functional defects
Low/Minor  able to continue further testing, but May or may not to solve
defect. Ex: Usability defects
10. Priority: The importance of defect fixing with respective to customer
High
Medium
Low
11.Status: New/Reopen
12.Test Environment: List of used hardware and software while detecting this
defect.
13.Detected by: Name of tester
14.Detected on: Date and Time
15.Assigned to: Developer name
16.Suggested fix: (optional)
Suggestion to fix defect if you know
Note1: Tester can use MS-EXCEL, Open office Excel to prepare above like defect report.
Note2: Tester can use MS-Outlook or lotus notes to forward defect report to developer
as an email.
Note3: Some company tester are using defect reporting like Bugzila, JIRA, Defect
tracer, Mantis, Bugtracer…..etc.
99
h) Defect tracking process
i) Bug Life Cycles
j) Test
100

Software Manual Testing PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Software Manual Testing PDF

Hochgeladen von

Copyright:

Verfügbare Formate

2016

Prepared by Anil Kumar

A set of executable programmes in an electronic device is called as software.

Types of SDLC Models

OLD SDLC Models

Advantages of waterfall model:

Disadvantages of waterfall model:

Explanation of above diagram:

Advantages of prototype model:

Disadvantages of prototype model:

SRG some requirements gathering

Advantages of Incremental model:

Disadvantages of Incremental model:

 Needs good planning and design.

When to use the Incremental model:

Advantages of Spiral model:

Disadvantages of Spiral model:

E. Rapid Application Development (RAD) Model

Advanced SDLC (Software Development Life Cycle)

To release quality software to customer/market, we need to conduct multiple

To develop a quality s/w w.r.t to customer requirements and expectations,

5. All the above conducted testing or reviewing is called as 'documents testing'

6. Unit testing: unit testing means that conducting testing on a single

7. Integration testing: Integration testing means conducting testing on the

8. Software testing: software testing means conducting the testing on a

9. Acceptance testing: Acceptance testing means that collecting the

Advantages of fish model:

Disadvantages of fish model:

It is more time consuming/taking.

Explanation of above diagram:

 All requirements are known up-front

Old SDLC models with V-Model

ii. Incremental V-Model

Devops transfer development and operations.

Example: Apple products

 Continuous software delivery

 Faster delivery of features

Agile model is derived from agile manifesto like Shown below.

1. Develop software in incremental model as instalment by instalment.

Advantages of Agile model:

1. Expensive model as more number of resources are required.

Case Study :( Old SDLC under along with Agile Model)

Agile scrum model

a. Agile scrum process

1. From the above process, agile scrum methodology is incremental spiral

QA Testers :( Quality Assurance Testers)

As a I would Like to So that Acceptance criteria

Customer Requirements Customer Expectations

3. PO is responsible to assign T-shirt size indicators to all user stories for

In Agile model documents are called as atrifacts.

Praposal document (from customer site in project or from management of

Unit test cases and integration test cases (Developers in ST)

IV. Multi Scrum

Launch SCRUMSTUDY.COM site

Click login by using register email id and emailed password

Select scrum fundamental exam

SBOKSCRUM Body of knowledge.

HLD and LLD for login:

Document Prepared By Reviewed by Techniques (*)

Walk Through: Study a document from first to last.

Inspection: searching document for specific factor.

Peer Review: Comparison of two similar documents.

II. Unit Testing