Hands on - A flight booking system allows passengers to select the number of seats they want to

book, with a limit of 1 to 5 seats per booking. Design test cases using boundary value analysis to
ensure the seat booking functionality works correctly.

2. Verify is user can book 1 seat (valid)

3. verify if user can book 2 seats(valid)
4.Verify if user can book 4 seats(valid)
5.Verify is user can book 5 seats(valid)
6.Verify user can book 6 seats(invalid)

Cyclomatic Complexity: is a software metric which is used

to calculate the complexity of the application.

V (G) = E - N + 2P

V(g)= V (G) is the maximum number of independent paths in the graph

E = number of edges in the flow graph.(Lines)

N = number of nodes in the flow graph.(Shapes)
P = number of nodes that have exit points

A = 10
IF B > C THEN
 A = B
ELSE
A = C
ENDIF
Print A
Print B
Print C

STLC ( Software Test Life Cycle):

Software Testing life cycle is a process of testing software application by following phases.

1> Test Strategy – QA

2> Test Planning – QA
3> Test Design- QA
4> Test Execution – QC
5> Test Closure – QA

Test Strategy – WHAT TO TEST, WHY TO TEST

It’s a high level documents usually prepared by senior QA member which outlines all the activities
which needs to be conducted to plan and test for a particular app or software.

It provides a roadmap for how testing will be carried out across the organization/project.

Purpose – It defines testing objectives, methodologies , tools , standard and guidelines to be

followed throughout the project.

Audience - Development team, PO, Testing team and stakeholders (end user)

Content –

Items which are in test strategy document:

1. Scope and objectives.

2. Testing Approach – Waterfall/Agile
3. Testing Types – Functional , Load , Usability
4. Hardware and Software configuration
5. Testing Tools – Load Runner, Selenium
6. Test Deliverables – Test cases , Test plan , Bug report , Testing report
7. Risks

Sample Test Strategy Document

1. Scope
The testing will be performed on the banking web application which includes the
following functionalities:

 User registration and account authentication

 Account transactions and transfers

 Balance inquiries and statements

 Bill payments and fund transfers

 Loan applications and approvals

2. Test Approach
The testing approach for the banking web application will include the following
steps:

 Test planning: The testing team will review the requirements and develop

a test plan that outlines the testing scope, objectives, and timelines

specific to banking functionalities.

  Test design: The testing team will develop test cases and test scenarios

based on the banking requirements and user stories. Test data will be

identified, and test environments will be set up.

 Test execution: The test cases will be executed using manual and

automated testing techniques. The testing team will report and track

defects, and retest fixed defects.

 Test reporting: The testing team will prepare and share test reports that

summarize the testing progress, the number of defects, and the overall

quality of the banking application.

3. Testing Types
The following testing types will be performed during the testing of the banking
web application:

 Functional testing: This type of testing ensures that the application

functions correctly according to the banking requirements. It includes the

testing of user registration, account transactions, balance inquiries, bill

payments, and loan applications.

 Usability testing: This type of testing focuses on user experience, ease

of use, and user interface design specific to banking operations.

 Performance testing: This type of testing evaluates the system's

responsiveness, stability, and scalability under different load conditions for

banking transactions.

 Security testing: This type of testing ensures that the banking

application is secure from unauthorized access, data breaches, and other

security threats.

 Compatibility testing: This type of testing checks if the banking

application functions correctly across different browsers, devices, and

operating systems.

4. Testing Tools
There are several important tools used in almost every testing project:

 Test management tools - JIRA

  Test automation tools – Selenium Webdriver

 Performance testing tools JMETER

 Security testing tools

 Code quality and static analysis tools SONARCUBE

 Continuous integration and continuous delivery (CI/CD) tools GITHUB Action, JENKINS

 Defect tracking tools JIRA

 Test environment management tools GIT/PERFORCE

5. Hardware - Software Configuration

The testing will be conducted on the banking web application across the
following hardware and software configurations (based on the user and traffic
analytics provided by the web development team or marketing team):

 Operating systems: Windows, macOS, Linux

 Browsers: Chrome, Firefox, Safari

 Database systems: MySQL, Oracle, SQL Server

 Devices – Iphone 6-15, One Plus devices , IPAD , TAB

6. Reporting/Test Deliverables
The testing team will prepare and provide the following reports for the banking
web application:

 Test Cases Execution Report: Provides information on the execution of

test cases, including:

o Pass/fail status

o Test case IDs

o Associated defects or issues encountered during testing

 Defect Report: Contains details about the defects or issues discovered

during testing, including:

o Description

o Severity

o Priority

o Steps to reproduce

o Current status (open, resolved, closed)

  Test Summary Report: Offers an overview of the testing activities

conducted, including:

o Number of test cases executed

o Pass/fail rates

o Test coverage achieved

o Overall assessment of the application's quality

 Test Progress Report: Tracks the progress of testing activities

throughout the project, including:

o Planned versus actual test execution

o Remaining work

o Milestones achieved

o Risks or issues encountered

 Test Coverage Report: Provides insights into the extent of testing

coverage achieved, including:

o Areas of the application tested

o Types of testing performed

Gaps or areas requiring additional testing

Test Plan Document: is a high level document which is more detailed

and specific to a particular project/release.It provides step by step

guide on how the testing will be conducted , who will do it and when

will it be done.

Audience : Testing team , Development team

Purpose - testing activities , schedule , resource management and deliverables for

that phase.
Content – test objectives for that phase , test scope , test deliverables , test

schedules , resource allocation, testing env details , test execution approach ,

test entry and exit criteria , test estimation, defect management and risk

management.

Test Cases design Phase :

1> Create Test scenarios --- generate them by using Black box test design

techniques

Verify if the user is able to login with correct username and

correct password

2> Create test cases

3> Review and Approval

Verify if the user is able to login with correct username and correct password.

Verify if the user is not able to login with correct username and incorrect password.

Verify if the user is not able to login with incorrect username and correct password.

Verify if the user is not able to login with incorrect username and incorrect password.

Software Test Execution-

Here the testers get the build/app and start with Dynamic testing. Smoke testing, sanity testing and
then whatever planned. It means executing the test cases on a real software.

Expected Results .- After successful login , The user is able to navigate to home page

Actual Result – User is getting error message. If Actual results are not matching with expected results
, defects are logged in project management tool (JIRA , BUGZILLA).

Test Env – QA env( Staging Env)

Test Closure/completion: It refers to all the activities which are performed at the conclusion of
testing phase in SDLC.It involves –

1> Making sure exit criteria is done.

 2> All the test artefacts/documents are logged and circulated with stakeholders.
3> Formally closing the testing activity.

Exit Criteria –

1. All test cases are executed .

2. No critical bug is open.
3. All bugs are reported and assigned.
4. All the planned regression test cases passed.