Manual testing

Manual testing is a software testing process in which test cases are executed manually without using any
automated tool. All test cases executed by the tester manually according to the end user's perspective.
Manual testing is essential because one of the software testing fundamentals is "100% automation is not
possible."

Software Development life cycle

SDLC is a process that creates a structure of development of software. There are different phases within
SDLC, and each phase has its various activities.

1. Requirement phase- During this phase, business analyst will gathered the all information about
the software like how the product will be used and who will use the product to determine the load
of operations.
2. Design phase: This is the high priority phase in the development life cycle of a system because
the logical designing of the system is converted into physical designing.
3. Development phase: In this phase, work is divided into small units, and coding starts by the team
of developers according to the design discussed in the previous phase and according to the
requirements of the client discussed in requirement phase to produce the desired result.
4. Testing phase: Testing determines whether the software is actually giving the result as per the
requirements addressed in the requirement phase or not. If there are any defects in the software or
it is not working as per expectations, then the testing team gives information to the development
team in detail about the issue.
5. Deployment: When software testing is completed with a satisfying result, and there are no
remaining issues in the working of the software, it is delivered to the customer for their use. As
soon as customers receive the product, they are recommended first to do the beta testing.
6. Maintenance: The maintenance phase is the last and long-lasting phase of SDLC because it is the
process which continues until the software's life cycle comes to an end. When a customer starts
using software, then actual problems start to occur, and at that time there's a need to solve these
problems.

STLC

Testing a software application to ensure that it meets the requirements and is free of defects.

Phase of stlc

1.Requirement Analysis

In this phase quality assurance team understands the requirements like what is to be tested, how to test,
when to test. If anything is missing or not understandable then the quality assurance team meets with the
stakeholders to better understand the detailed knowledge of requirements.

2. Test Planning
Test Planning in STLC is a phase in which a Senior QA manager determines the test plan strategy along
with efforts and cost estimates for the project. Moreover, the resources, test environment, test limitations
and the testing schedule are also determined.

3. Test case Design

The test case Design phase gets started once the test planning phase is completed. In this phase testing
team notes down the detailed test cases. The testing team also prepares the required test data for the
testing. When the test cases are prepared then they are reviewed by the quality assurance team.

4. Test Environment Setup

Environment setup requires a group of essential software and hardware to create a test environment. The
testing team is not involved in setting up the testing environment, its senior developers who create it.

5.Test Execution

After the test case design and test environment setup test execution phase gets started. In this phase
testing team starts executing test cases based on prepared test cases in the earlier step.

6.test closure

Test closure is the final stage of the Software Testing Life Cycle (STLC) where all testing-related
activities are completed and documented. The main objective of the test closure stage is to ensure that all
testing-related activities have been completed and that the software is ready for release.

Verification

In verification, checking whether the product is being developed according to the specified
requirements and design. It answers the question: "Are we building the product right?"

Validation

In validation, evaluating the final product to ensure it meets user needs and expectations. It answers the
question: "Are we building the right product?"

Types of testing

1. White box testing: In white-box testing, the developer will inspect every line of code before
handing it over to the testing team
2. black box testing: black box testing is a process of checking the functionality of an
application as per the customer requirement. the source code is not visible in this testing;
that's why it is known as black-box testing.
Types of black box testing
 Functional testing: Functional Testing is a type of Software Testing that verifies that an
application’s feature work as expected.
 1. Unit testing- individual units or modules of the application are tested. It ensures that each
module is working correctly.
2. Integration testing: where we test the data flow between two features is
called integration testing.

3. System testing
4. Smoke testing: Smoke testing is a type of software testing that is performed to quickly
evaluate whether the basic functionalities of a software application are working correctly.
5. Sanity testing: Sanity testing is a subset of regression testing performed after receiving a
new build to verify that the critical functionalities of the application are working as
expected.
6. Regression testing: Regression testing is a type of software testing that ensure that recent
change such as (code changes, bug fixes, or enhancements) have not negatively impacted
the existing functionality of the application.
7. Retesting: Retesting is performed when test cases are re executed after the defects fixed.
8. Ad-hoc: Ad-hoc testing is an informal testing type whose aim is to break the system. This
type of software testing is unplanned activity. It does not follow any test design to create
the test cases. Ad-hoc testing is done randomly on any part of the application; it does not
support any structured way of testing.
9. Static testing: Static testing is a software testing technique by which we can check the
defects in software without actually executing it.
10. UAT: UAT is done by the client to certify that the system meets the requirements and
works as intended. It is the final phase of testing before the product release.
11. Usability testing: Usability testing is done to measure how easy and user-friendly a
software application is.
 Non functional testing:
1. Performance testing
2. Load testing
3. Security testing

Testing Documents:

Testing documentation is the documentation of artifacts that are created during or before the testing of a
software application. Documentation reflects the importance of processes for the customer, individual and
organization. Type of testing document

1. Test scenarios: The test scenario is a detailed document of test cases that cover end to end
functionality of a software application.
2. Test case: test case describe step by step procedure to test an application
3. Test plan: Test plan is a document that is prepared by the managers or test lead. It consists of all
information about the testing activities. The test plan consists of multiple components such
as Objectives, Scope, Approach, Test Environments, Test methodology, Template, Role &
Responsibility, Effort estimation, Entry and Exit criteria, Schedule, Tools, Defect tracking,
Test Deliverable, Assumption, Risk, and Mitigation Plan or Contingency Plan.
 4. Requirement traceability matrix [RTM]: The Requirement traceability matrix [RTM] is a
document which ensures that all the test case has been covered. This document is created before
the test execution process to verify that we did not miss writing any test case for the particular
requirement.
5. Test strategy: The test strategy is a high-level document, which is used to verify the test types
(levels) to be executed for the product and also describe that what kind of technique has to be
used and which module is going to be tested.
6. Test data: It is data that occurs before the test is executed. It is mainly used when we are
implementing the test case.
7. Bug report: The bug report is a document where we maintain a summary of all the bugs which
occurred during the testing process.
8. Test execution report: It is the document prepared by test leads after the entire testing execution
process is completed. The test summary report defines the constancy of the product, and it
contains information like the modules, the number of written test cases, executed, pass, fail, and
their percentage.

Defect life cycle

1) When tester find the defect. The tester will Logged into the defect tracking tool with relevant
details like steps to reproduce, environment, severity, priority, etc. status of the defect will be
New.
2) Then developer will analyze the defect.
3) Developer will determine if the defect is valid or not
4) If the defect is not valid then the development manager assigns the status Rejected to defect.
5) If the defect is valid then it is checked whether the defect is in scope or not. If no then the defect
status is changed to Deferred.
6) If the defect is in scope then the manager checks whether a similar defect was raised earlier. If
yes then the defect is assigned a status duplicate.
7) If the defect is not already raised then the manager starts fixing the code and the defect is
assigned the status In-Progress.
8) Once the defect is fixed the status is changed to fixed.
9) The tester retests the code if the test is passed then the defect status is changed to closed.
10) If the test fails again then the defect is assigned status reopened and assigned to the developer.

Severity

how severely a defect can affect the functionality of the software.

It can be a blocker, critical, major, and minor for the bug.

1. Blocker: if the severity of a bug is a blocker, which means we cannot proceed to the next module, and
unnecessarily test engineer sits ideal.
2. Critical: main functionality is not working, and the test engineer cannot continue testing.
3. Major: supporting components and modules are not working fine, but test engineer can continue the
testing.
4. Minor: U.I problems are not working fine, but testing can be processed without interruption.

Priority

Priority how soon we need to fix a defect.

It can be urgent, high, medium, and low.

1. High: it is a major impact on the customer application, and it has to be fixed first.
2. Medium: he problem should be fixed before the release of the current version in development.
3. Low: The flow should be fixed if there is time, but it can be deferred with the next release

High Severity, High Priority:

Example:

 Issue: when user unable to login to the application.

High Severity, Low Priority:

Example:

 Issue: The "Reports" module crashes, but the release does not include this module.
 Reason: A critical issue but does not impact the current release.
 Action: Can be deferred to a future release.

Low Severity, High Priority:

Example:

 Issue: A typo in the company's name on the homepage.

Low Severity, Low Priority:

Example:
 Issue: Misalignment of text in the footer of a page.
 Reason: Cosmetic issue with no functional impact.
 Action: Can be fixed in a later release if time permits.