x The Application which is developed by developers to check whether is matching with Client

Requirement or not ??? is called software testing.

FSD-Functional specification Document

BRD-Business Requirement Document

Project: Based upon the client Requirement Company will Develop the Project is called Project Based
Company

Product: Based upon on the market value company develop their own product and try to sell to other
company

Error:-

Defect?

Bug:-

SDLC: software Development Life Cycle

1.Requirement Gathering & Analysis:

2.Desigining

3.Coding

4.Testing-STLC

5.Maintainance and Support

Requirement Gathering Analysis: The business Analyst will interact with the client and receive the BRD
document from the client and that document will be given to the UI and UX team for Preparing the FSD
Document and mock up screen.

Designing Phase: Based on the FSD and BRD, Development lead will Start Designing of Technical design
Document --contains Low level and High Level document and QA will start designing the test cases and
test scenarios – what functionality we are going to testing and test cases how many ways we can test
that functionalities

Coding: Development team will start developing the application based on Technical Design Document,
Once Development is done Development team will perform unit Testing then they will give that
application to the Testers.

Testing Phase: Once testers Receive the FSD and BRD they will start analyzing the requirement and start
designing the test scenarios and test cases. Once Testers receive the build from the Development team
then they will start executing the test cases—Analysis , Designing and Execution
Maintaince and Support: once the product is in go live if there is any clarification or any support this
team will look into it.

Testing Methodologies:

White Box Testing: White Box Testing is done by the Developers it is also called as unit testing and
component testing.

Unit Testing: Testing a single unit of code is called as unit testing. In white box Testing / unit testing
Developers validate only basic Functionality of code. Once the Unit testing is done then only they deploy
to QA Environment.

Black Box Testing: Black box Testing is done by the Functional Testers which is also called as functional
testing. Here we will mainly concentrate on the functional -business flow and positive and Negative Flow
and integration testing.

Grey Box Testing: The person who do both the Development and testing is a grey box testing which
happens is small company.--SDET

-------------------------

Environments:

url

database server

application server

Development Environment: Once you receive FSD and BRD Development Team will start developing the
application in Dev Environment.

Url:- https;//dev.sbi.com

Build Deployment:- moving the code from one Env to another Env.

Build Releasee Note 1.2:- what functionality, defects they have deployed in that build, they mentioned in
the document.

QA /SIT Testing : Once unit testing is done then only they deploy to QA environment. Once QA testing is
done they will move the code to UAT environment.

Url:- https;//QA.sbi.com 100% pass.

UAT User Acceptance Testing: Once QA testing is done they will move the code to UAT environment

Url:- https;//UAT.sbi.com
Pre-Prod--- business team

Build Releasee Note--- 1.2 version

Production : Once the UAT Testing is Done they will move to Pre Prod/Production Environment

Url:- https;//sbi.com

Types of Testing:

Two Types of Testing

Static Testing: Static Testing is a Verification weather we are doing Right system (Procedure)or not (No
Execution)(Meeting and Review)

Static Testing is also called Verification

We follow Meetings and Reviews No Execution

Meetings

FSD BRD Walkthrough Meeting: Once we Receive the FSD And BRD we analyze the requirement and
prepare Ambiguities Sheet and we will request FSD BRD walkthrough meeting with Devlead and Business
Analyst.

Test Scenario and Test case Walkthrough Meeting: Once we design the test scenarios and test cases we
will have a self review and peers Review within the team members and we will request a Review with
the QA team lead as a walkthrough meeting.

Testplan walkthrough meeting : which we will have with all the team members

Analysis as per FSD and BRD (Ambiguties)

Dynamic Testing: Dynamic Testing is called Validation weather system is right or not(Application is
working as per FRD and BRD)

Dynamic Testing is also called Validation. Here we have Execution to check weather system is right or not
—functional and Non functional testing.

Smoke Testing: Smoke Testing is also called as Health checkup to check weather application is stable or
not and to check whether we are able to navigate all the screens or not and able to do further testing.

Smoke testing is done once we receive the Build(Mostly Done by Automation Team).

Sanity Testing: It is in depth Testing to check weather all the fields are working as per the requirement or
and all are integrated or not?

ReTesting: Executing the failed test cases, once the developer fixed the defect is called retesting.
Regression Testing: Due to code fix or any change request, the existing related functionality should not
get effected or impacted. and Regression testing should be done at the time of Release (3 days Before
SCF).

Ad hoc Testing: Adhoc Testing is unplanned activity. we will not follow any documentation of test
scenario and test case directly we work on application(Validation Dynamic Testing Comes into the
Picture).

Levels of Testing

1)Unit Testing: Unit Testing is a Testing which is done by developers .once unit test is done then only
they will deploy in QA Environment.

2) Integration Testing: Here we will check weather two or more modules are integrated as per the
requirement or not. Here we validate the integration of top to bottom and bottom to top approach

Amzon.in 2000rsà mobileà add addressà Review Orderà balance 2000—1000rs—pending 1000

1000Rs

Emai yahool- 123---321-à youtube---yahoo

jP Morhan bank

creating new account EMI-defaultà ECAR-SYSTEM—XYZ—email—1lk—new good account

up stream--- down stream//

3)System Integration Testing: Here we are validating end-to-end testing. we are Validating upstream and
downstream are integrated as per the requirement.

4)UAT(User Acceptance Testing): It is done by the UAT Testers .who Represents the clients. AT has two
types of testing

Alpha Testing: Alpha Testing is done by functional testers in UAT Environment in their premises—product
base company.. 1) regression testing—previously release core test cases

2) only core functionality test cases for current release

Beta Testing: Beta Testing is Done by UAT Testers in UAT Environment. 90%project base companies

localization testing: -

Essentially, localization testing is a technique to verify software behavior, accuracy, and suitability for
specific locations and regions.

Internationalization Testing:
Internationalization testing is a process of ensuring the adaptability of software to different cultures and
languages around the world accordingly without any modifications in source code.

Explority Testing: If we don’t have any base document for the application, we will spend more time on
the application and explore the knowledge.

Compatibility Testing or Cross browse Testing: To Check whether the application is working as per the
requirement in all the operating systems and Browsers.

Accessibility testing/ 5o8 testing: - voice over testing the app.

Exhaustive Testing: Testing is to check with each field with different inputs and combination to check
weather its working as per expected result or not

Security Testing: To check weather all the security fields are encrypted as per requirement or not.
Weather we have received acknowledgement message or not after transaction.

Monkey Testing: To check weather system generating error message when we enter invalid combination
of data

Check number:- 2345 @@@@@@@@@@&*(*@#WERT#$%

GUI Testing_non functional: Graphical User interface Testing(Font size scroll and

Scalability Testing

Load Testing is a non-functional software testing process in which

Load testing:-
the performance of software application is tested under a specific expected
load
Volume testing

Stress testing.

5 principles of testing

Testing Techniques:

Boundary value Analysis: Which is used to reduce the test data when we have a range values.

Total bill :-1000 to 5000 --10% discount

// Age--- 35 to 50

1. Min 1000 10

2. Max 5000 10
3.Min+1 1001 10

Min-1 Min min+1 max-1 max max+1

4.Max+1 5001 0

Min-1 999 0

Max-1 4999 10

Equivalence Class Partition: This Technique is used to reduce the test data when we have a different
combination of inputs of conditions: with valid class and Invalid class

Account Number:- 6 length with 5 Alpha numeric and 1 special characters :-- ABC12$

Valid class invalid class

ABC12# ABC123

XFR88$ XET34K

Error Guessing Mechanism: -We can easy guess the Result whether, it is working as Expected or not? As
having Domain or Prior Experience on Application.

https://www.youtube.com/watch?v=BSjRmiYP7vg

Severity and Priority

Severity is given by testers which shows how seriously its effecting the defect to end user/ client.

Critical: If there is any show stopper defect then we will go for the critical defect.

Then we drop an email to Devlead.

High Severity: If we got any high defect with no workaround .

Azmon..

Paymnet page-credi, Upi, debt card.

Medium: It is a functional Defect with workaround credit working and bank account number not
working--medium

Credit/account bank not working ---high

Low :- It is a NON Functionality Defect With no impact on functionality.

Priority: It is given by developers /testers and how fast we are expecting the defect to be fixed.

Critical :-it should fix in 1-2 hours

High: It should fix in one to two days.

Medium : It should fix in 2-4 days

Low: Once All the functional defects got fixed then we go for the low defect

High severity---- low priority:-

Low severity and high priority--??

HD

JIRA-,----raise defect J120

Summary: Defect_System generating error on payment page, when user clicks on submit button.

Assigned: Rahul--manoj

Severity:- high

Priority:- high

Status:- Newà Openà In Progress-à Ready for testing/test ready—open and assigned to same CLose

Environment:- SIT

Project:- SBI_phase 1

Attachment:-restesting screen prints

///Sprint:- 20-04-04-05-active—not in ALM and available in Jira

09-04—18-04-furture

//Feature Link:- User story---US3627

Description:-

Steps to Reproduce: -

1)//

5) step---Expected Result and Actual Result

Comment:- Assigned to new defect.

@ravi,@ramu

Rahul:- working in progress

Create button

Bug Life Cycle:

New: When we rise a new defect the defect status will be new.

Assign:We Assigned to Developer.

Open:The Developer will open the defect and change the status to OPEN

developer will cross check whether the defect is valid or not.

if it is a valid defect

They change the status to working “in progress”

Test: Once The defect fixed and at the time if deployment, they will change the status to ready for
testing.

And assignee will be tester name.

Duplicate: Developer may or can reject the defect due to duplicate defect or invalid test data used.

And they can deferred the defect (it will be fixed in next release).

Once the defect is ready for testing the tester will retest the defect.

If it is working as expected they will close the defect

If its is not working they will reassign to same developer

STLC:
Software Testing Life Cycle:

Requirement Analysis: Once we Receive FSD BRD we start analyzing the requirements and prepare the
ambiguti sheet and we schedule FSD BRD Walkthrough Meeting. And get clarified ambuguti queries.

Test Planning: Test planning is prepared by the Sr QA. Test plan consists of below sections:-

1. Objective : Here we will describe about the overview of the project.

We will develop window service which is used to process the file which is uploaded by web site.
Once file uploaded then window service will extract data from excel files (Upload folder) and store
into database.

Folder structure is used for backend process as below:

o Upload
o InProcess
o Failed
o Success

2. Scope: Here we will describe about what are the functionalities we are going to validate as
within the project.

a) We are validating the functionality of uploading region wise administration fee in PMA system.
Admin Fee is used in tender generation process.

a. We are validating the Fields and validation while uploading the document
in the PMA System.

3. Out of Scope: What are the functionalities which are not testing in this project.
a) Data base testing will be out of scope
b) API Testing will be out of scope
c) Performance testing and Security testing

4. SIT and UAT start date and End Date:

SIT-Start date- 07/01/2022
End date- 27/01/2022
UAT start date:-28/01/2022
UAT End date-10/02/2022
5. End to End Testing:- SIT:- Yes/NO
IF Yes---- validate the files, in down stream System—while it is upload in PMA System
 6. Regression Testing start date and end date
Start date and end date--

7. Entry Criteria:- FSD and BRD are available on time and test cases should reviewed and approved
by client.

8. Exit Criteria:- all test cases should be executed and pass rate should be 95% with no high and
critical defects.

9. Test data consideration:/Dependence- Ex: We are depending the few fields like CFS, THC, GYC
values from up stream and we are requesting before 2 weeks of test execution.

Aadhar card number is dependent on up stream.

Test Design and Documentation: In this Phase we will design test scenario and test cases.

Designing of test scenarios and test cases and get reviewed by team lead and business team

Preparing the test data.

Test Environment Setup: To check whether they have installed all the hardware and software or not

Test Execution: Once environment setup is done we will start executing the test cases and if any
expected mismatch the we will raise defect and assigned to developer.

Test Closure: we can do the test closure when all the test cases should be executed and passed and
should be no open defects and the minimum pass percentage should be 95% and we can have the open
defect but those should be deferred and the severity should be medium or low. Finally, we will prepare
the test results summary. We will summarize how many test cases are pass and failed and how many
defects raised and open defects.

RTM: Requirement Tracebilty Matrix

To Ensure that we have covered all the requirements in our testing.

It is easy to trace the requirements in our test cases.

Agile, Scrum and Jira and Qtest

AGILE: Agile is a fast quick easy and we have three roles in agile

1. Scrum Master: Scrum Master is a Facilitator and a leader who drives the project and who resolves the
issues for the team Members.

2.Product owner: He is a decision Maker and who Prioritize the requirements( User stories) and Who
interacts with clients
3.Team: Both Development and testing team are the main reason for the development of the project.

SPRINT: It is a time box of two weeks of time.

1st day we have a sprint planning and team will decide what are requirements to be develop

Every day we have a scrum meeting and we need to tell what we did yesterday or what we are going to
develop do today and impediments

At the last day of the sprint we have a show and tell meeting here all the user stories of sprint 1 given
demo in this meeting.

At the End of the day we have retrospective meeting so we are discussing how the sprint1 went and how
we can we make better for the next sprint.

V-Model

V Model is a combination of both verification and validation. Verification will be on the right hand side
and validation on the left hand side.

Verification is we doing right system or not. Once we get the BRD document the Devlead will prepare
FSD Document.

Validation is to check weather system is right or not. When we are performing unit testing we will
consider the document of low level design document