Smoke and Sanity Testing:

Smoke testing is more broad and general, while sanity testing is more specific and focused on a
small piece of the software.
Smoke testing, also known as "build verification testing," is a type of software testing that is
performed to ensure that the most important functions of a software program work correctly.
It is usually done after a build or a release to ensure that the most critical parts of the software
are stable and can be used. It is a quick and basic test to ensure that the software is not
completely broken and can be used for further testing.
Sanity testing, also known as "health check testing," is a type of software testing that is
performed to ensure that a small section of the software, such as a specific module or feature,
works as expected. It is usually done after a small change or modification to the software has
been made to ensure that the change has not affected the rest of the software. It is a quick and
superficial test to ensure that the software is stable and can be used for further testing.

Re-Testing
when there is a bug, the developer solves it then it is tested by QA whether it is resolved or not.
only bug flows can test that it is solved or not.

Regression testing
Regression tests are typically performed after changes have been made to the software, such as
bug fixes, new features or updates. The goal of regression testing is to identify any new bugs or
issues that have been introduced by the changes, and to ensure that existing functionality is still
working correctly. This helps to ensure that the software remains stable and reliable, even as
changes are made to it over time.
Regression testing can be done manually or using automated testing tools, and it can include
testing the entire software or just specific parts of it. It can be done on different levels such as
unit, integration, system and acceptance level testing.

Performance testing
Performance testing is a type of software testing that is used to evaluate the performance of a software
application or system under a specific workload. It is used to determine how the system behaves in
terms of responsiveness and stability under different loads and conditions, and to identify any
bottlenecks or limitations that may need to be addressed.

There are several types of performance testing, each with a specific focus:
  Load testing: This type of testing is used to evaluate how the system behaves when a large
number of users or requests are made simultaneously. It is used to ensure that the system can
handle the expected levels of traffic and usage.
 Stress testing: This type of testing is used to evaluate how the system behaves when it is
pushed beyond its normal or expected usage limits. It is used to identify the point at which the
system breaks or fails.

Example: Considering your application can handle 100 concurrent users. In a stress test, you may
start by having 100 or more users in the system performing data transactions. Slowly you would
stress the system by either increasing the load or having more transactions performed. Then you
would monitor how your application is performing in this stressed situation.

 Endurance testing: This type of testing is used to evaluate how the system behaves over an
extended period of time. It is used to identify any issues or problems that may arise after very
long usage of time.
 Scalability testing: This type of testing is used to evaluate how the system behaves as the
number of users or requests increases. It is used to identify any limitations or bottlenecks in the
system that may prevent it from handling a large number of users or requests.

Performance testing can be done manually or using automated testing tools, and it can include testing
the entire software or just specific parts of it. It can be done on different levels such as unit, integration,
system and acceptance level testing.
Black box testing & White box testing
Black box testing and white box testing are two different approaches to software testing.

Black box testing is a method of testing software where the tester is only aware of the inputs and
expected outputs of the system, but has no knowledge of the internal structure or implementation.
The tester is "outside the box" and only interacts with the system through its interface, like a user
would. The focus of black box testing is on testing the functionality of the software and ensuring that it
meets the requirements.

White box testing, also known as structural testing or glass box testing, is a method of testing
software where the tester has knowledge of the internal structure and implementation of the system.
The tester is "inside the box" and can see the code, data structures and other internal elements of the
system. The focus of white box testing is on testing the internal logic and structure of the code, and
ensuring that it is correct and efficient.

Bugs and Error

Bugs can be caused by errors in the code, in summary, a bug is a specific type of error that is present in
the software code and cause the software to malfunction.

If there is a difference between Actual and expected result is called BUG, Defect excepted by the
developer is called a BUG. ERROR can be caused by mistake in code. FAILURE can be caused by BUGS in
Production Stage.

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

An error can be caused by a bug, but it can also be caused by other factors such as incorrect input,
hardware failures

How to know bug severity/priority.

Severity defines the impact of the bug on the software
Priority defines by team lead when we solved the bug.
Priority refers to how quickly the fault should be rectified, whereas Severity refers to how important the
flaw is to the product's functionality. The manager/client decides on the priority of problems, whereas
the QA engineer determines the severity levels of the faults.
VERIFICATION AND VALIDATION
BUG LIFE CYCLE
Defect Life Cycle or Bug Life Cycle in software testing is the specific set of states
that defect or bug goes through in its entire life.

 New: When a new defect is logged and posted for the first time. It is
assigned a status as NEW.
 Assigned: Once the bug is posted by the tester, the lead of the tester
approves the bug and assigns the bug to the developer team
 Open: The developer starts analyzing and works on the defect fix
 Fixed: When a developer makes a necessary code change and verifies the
change, he or she can make bug status as “Fixed.”
 Pending retest: Once the defect is fixed the developer gives a particular
code for retesting the code to the tester. Since the software testing remains
pending from the testers end, the status assigned is “pending retest.”
 Retest: Tester does the retesting of the code at this stage to check whether
the defect is fixed by the developer or not and changes the status to “Re-
test.”
 Verified: The tester re-tests the bug after it got fixed by the developer. If
there is no bug detected in the software, then the bug is fixed and the
status assigned is “verified.”
 Reopen: If the bug persists even after the developer has fixed the bug, the
tester changes the status to “reopened”. Once again the bug goes through
the life cycle.
 Closed: If the bug is no longer exists then tester assigns the status
“Closed.”
Components of bug reporting in Jira.
Jira issue key for the bug as a hyperlink.

Bug summary.

Bug description including steps to reproduce, expected and actual results.

Priority.

Date of discovery.

Current status.

Fix version.

Postman Parameters.

To send parameters values

How to get all of the patient with postman.

Testing types
Testing techniques

Use case
A use case is a written description of how users will perform tasks on your website. It outlines, from a
user's point of view,

Set of action performed by the user. Use case testing is a technique that helps to identify test cases that
cover the entire system, on a transaction by transaction basis, from start to finish.

Test suite: Set of test cases.

Test Script:
Set of instruction to perform automation ( ). The script is written in a specific programming
language like Java, Python, and more

Test plan:
A test plan is a comprehensive document that lists the test strategy, goals, timetable, projections,
deadlines, and resources needed to complete that specific project

Which strategy to perform, smoke sanity regression functional non functional

We need to know what is requirement.

Xpath:
Dom is created by the user at the runtime when the user xpath worked based on the DOM structure it
will navigate every node to find the element.

SDLC Phases:
Requirement gathering (gather requirement from customer and convert into coding language)

Analysis (check finance to take over the project or not), Designing, coding, testing.

STLC:
Understanding the requirement,

Design the test cases,

Find bug reports to Developers.

QA/QC
QA the process or set of processes used to measure and assure the quality of a
product, and QC Quality Control, the process of ensuring products and services
meet consumer expectations.
QA primarily focuses on the processes and procedures that improve quality, including training,
documentation, monitoring and audits. QC focuses on the product to find defects that remain after
development.
API STATUS CODE:
API testing is important for validating the functionality of the API and ensuring that it meets the
functional requirements.
***************

🔴 400 Bad Request

***************

Suppose you are working with an e-commerce API, and you attempt to create a new order without
providing the required fields, suppose we need to send three fields in request product, customer,
quantity but you only send product field.

👉 Request
POST /api/orders
Content Type: application/json
{ "product": "12345" }

👉 Response
400 Bad Request
Content-Type: application/json
{ "error": "Missing required fields: 'customer', 'quantity'" }

************

🔴 401 Unauthorized
************
When interacting with an authentication API, if you provide incorrect or missing credentials, you may
receive a 401 status code:

👉 Request
POST /api/auth/login
Content-Type: application/json {"username": "john", "password": "incorrectpassword" }

👉 Response
401 Unauthorized
Content-Type: application/json
{ "error": "Invalid credentials" }

***********

🔴 403 Forbidden
***********

Let's say you are accessing an API that requires specific user roles or permissions to perform certain
actions.

If you attempt to access a restricted resource without the necessary permissions fo example in below
scenario DELETE method can only be done by Admin but you are trying to perform delete action with
normal user, you’ll receive a 403 status code.

👉 Request
DELETE /api/users/123
Authorization: Bearer <token>

👉 Response
403 Forbidden
Content-Type: application/json
{ "error": "Insufficient permissions to delete user" }

***********

🔴 404 Not Found

***********

When accessing a resource that doesn't exist, you may receive a 404 status code.
if you query an API for a user that doesn't exist, that means userid 999 not present in DB

👉 Request:
GET /api/users/999

👉 Response:
404 Not Found
Content-Type: application/json
{ "error": "User not found" }

***************

🔴 405 Method Not Allowed

***************

Suppose you are interacting with an API that only allows specific HTTP methods for a particular
endpoint. If you attempt to use an unsupported method, you will receive a 405 status code,

TIPS: always use OPTIONS method to cross check what all methods are allowed

👉 Request:
PUT /api/customers/123
Content-Type: application/json
{ "name": "John Doe", "email": "john.doe@example.com" }

👉 Response:
405 Method Not Allowed
Content-Type: application/json
{ "error": "PUT method is not allowed for this endpoint" }

*****************
Keep in mind that specific endpoints, request formats, and error messages may vary depending on the
API you are testing.