Non functional testing is a type of software testing that verifies non functional aspects of

the product, such as performance, stability, and usability. Whereas functional testing
verifies whether or not the product does what it is supposed to, non functional testing
verifies how well the product performs
Non-functional testing can help improve a product's usability, maintainability, and
portability, while also reducing production risk and expense.
Some types of non-functional testing include:
 Performance testing: Measures how well a system performs
 Load testing: Simulates high user loads to measure system performance under heavy
traffic
 Usability testing: Evaluates the user experience and usability of the system
 Security testing: Identifies vulnerabilities and weaknesses in the system's security
Non-functional testing can be challenging because of varying device configurations, network
conditions, and platform-specific behaviors.

Some tools used for non-functional testing include:

Apache JMeter, Gatling, LoadRunner, OWASP ZAP, Burp Suite, Nessus, UserTesting, Morae,
and Optimal Workshop.
Functional Testing
Functional testing is a type of software testing that verifies if an application's features work
as intended, based on specific requirements. It's a common and foundational type of testing
that focuses on the results of processing, not the internal code structure
Unit Testing
Unit Testing: Unit testing is the type of functional testing technique where the individual
units or modules of the application are tested. It ensures that each module is working
correctly.
Unit Testing Techniques
There are 3 types of Unit Testing Techniques. They are follows
Black Box Testing: This testing technique is used in covering the unit tests for input, user
interface, and output parts.
White Box Testing: This technique is used in testing the functional behavior of the system by
giving the input and checking the functionality output including the internal design structure
and code of the modules.
Gray Box Testing: This technique is used in executing the relevant test cases, test methods,
and test functions, and analyzing the code performance for the modules.
https://www.geeksforgeeks.org/unit-testing-software-testing/
Integration Testing
Integration testing, also known as I&T, is a type of software testing that evaluates how
different parts of an application work together as a whole. It's performed after unit testing
and before system testing.
1. Big-Bang Integration Testing
 It is the simplest integration testing approach, where all the modules are combined
and the functionality is verified after the completion of individual module testing.
 In simple words, all the modules of the system are simply put together and tested.
 This approach is practicable only for very small systems. If an error is found during
the integration testing, it is very difficult to localize the error as the error may
potentially belong to any of the modules being integrated.
 So, debugging errors reported during Big Bang integration testing is very expensive
to fix.
 Big-bang integration testing is a software testing approach in which all components
or modules of a software application are combined and tested at once.
Advantages of Big-Bang Integration Testing
 It is convenient for small systems.
 Simple and straightforward approach.
 Can be completed quickly.
 Does not require a lot of planning or coordination.
 May be suitable for small systems or projects with a low degree of interdependence
between components.
Disadvantages of Big-Bang Integration Testing
  There will be quite a lot of delay because you would have to wait for all the modules
to be integrated.
 High-risk critical modules are not isolated and tested on priority since all modules
are tested at once.
 Not Good for long projects.
 High risk of integration problems that are difficult to identify and diagnose.
 This can result in long and complex debugging and troubleshooting efforts.
 This can lead to system downtime and increased development costs.
 May not provide enough visibility into the interactions and data exchange between
components.
 This can result in a lack of confidence in the system’s stability and reliability.
 This can lead to decreased efficiency and productivity.
 This may result in a lack of confidence in the development team.
 This can lead to system failure and decreased user satisfaction.
2. Bottom-Up Integration Testing
In bottom-up testing, each module at lower levels are tested with higher modules until all
modules are tested. The primary purpose of this integration testing is that each subsystem
tests the interfaces among various modules making up the subsystem. This integration
testing uses test drivers to drive and pass appropriate data to the lower-level modules.
Advantages of Bottom-Up Integration Testing
 In bottom-up testing, no stubs are required.
 A principal advantage of this integration testing is that several disjoint subsystems
can be tested simultaneously.

 It is easy to create the test conditions.

 Best for applications that uses bottom up design approach.
 It is Easy to observe the test results.
Disadvantages of Bottom-Up Integration Testing
 Driver modules must be produced.
 In this testing, the complexity that occurs when the system is made up of a large
number of small subsystems.
 As Far modules have been created, there is no working model can be represented.
3. Top-Down Integration Testing
Top-down integration testing technique is used in order to simulate the behaviour of the
lower-level modules that are not yet integrated. In this integration testing, testing takes
place from top to bottom. First, high-level modules are tested and then low-level modules
and finally integrating the low-level modules to a high level to ensure the system is working
as intended.
Advantages of Top-Down Integration Testing
 Separately debugged module.
 Few or no drivers needed.
 It is more stable and accurate at the aggregate level.
 Easier isolation of interface errors.
 In this, design defects can be found in the early stages.
Disadvantages of Top-Down Integration Testing
 Needs many Stubs.

 Modules at lower level are tested inadequately.

 It is difficult to observe the test output.
 It is difficult to stub design.
4. Mixed Integration Testing
A mixed integration testing is also called sandwiched integration testing. A mixed
integration testing follows a combination of top down and bottom-up testing approaches. In
top-down approach, testing can start only after the top-level module have been coded and
unit tested. In bottom-up approach, testing can start only after the bottom level modules
are ready. This sandwich or mixed approach overcomes this shortcoming of the top-down
and bottom-up approaches. It is also called the hybrid integration testing. also, stubs and
drivers are used in mixed integration testing.
Advantages of Mixed Integration Testing
 Mixed approach is useful for very large projects having several sub projects.
 This Sandwich approach overcomes this shortcoming of the top-down and bottom-
up approaches.
 Parallel test can be performed in top and bottom layer tests.
Disadvantages of Mixed Integration Testing
 For mixed integration testing, it requires very high cost because one part has a Top-
down approach while another part has a bottom-up approach.
 This integration testing cannot be used for smaller systems with huge
interdependence between different modules.
User Acceptance Testing
User Acceptance Testing (UAT) is a stage in software development where end users test a
product in real-world conditions to ensure it meets their needs. It's also known as end-user
testing or beta testing.
UAT is important because it helps to:
 Improve product quality: UAT helps identify and resolve issues that affect the user
experience.
 Reduce costs: It's cheaper and easier to fix issues before a product is released.
 Promote brand image: UAT helps ensure that a brand only releases high-quality
products.
 Ensure compliance: UAT helps ensure that a product complies with relevant laws
and regulations

Boundary Value Analysis

STLC
Phases of STLC
1. Requirement Analysis
The entry criteria for this phase is the BRS (Business Requirement Specification)
document. During this phase, the test team studies and analyzes the requirements
from a testing perspective.

This phase helps to identify whether the requirements are testable or not. If any
requirement is not testable, the test team can communicate with various
stakeholders (Client, Business Analyst, Technical Leads, System Architects, etc) during
this phase so that the mitigation strategy can be planned.

What I do in Requirement Analysis Phase as a Software Tester?

As a software testers, When I start with the Requirement Analysis phase, my primary
goal is to understand what needs to be tested. Here, I carefully go through the
software requirements and specifications documents. If I have any doubts or need
clarification, I talk to the stakeholders to make sure everything is clear. This phase
helps me identify the testable requirements and the scope of testing.

Entry Criteria: BRS (Business Requirement Specification)

Deliverables: List of all testable requirements, Automation feasibility report (if

applicable)

Must Read: Test Strategy In Depth Explanation

2. Test Planning
Test planning is the first step in the testing process.

In this phase typically Test Manager/Test Lead involves determining the effort and
cost estimates for the entire project. Preparation of the Test Plan will be done based
on the requirement analysis.

Activities like resource planning, determining roles and responsibilities, tool selection
(if automation), training requirements, etc., carried out in this phase.

The deliverables of this phase are Test Plan & Effort estimation documents.

What I do in Testing Phase as a Software Tester?

In the Test Planning phase, I create a roadmap for how I will approach the testing
process. This involves defining the objectives, resources, schedule, and scope of
testing. I also decide on the tools and techniques we will use and prepare a high-
level timeline. The test plan includes details about the testing environment, risk
analysis, and contingency plans. It acts as a guide for executing the tests.

Entry Criteria: Requirements Documents

Deliverables: Test Strategy, Test Plan, and Test Effort estimation document.

Must Read: How To Write A Good Test Plan

3. Test Design
The test team starts with test case development activity here in this phase. Testers
prepares test cases, test scripts (if automation), and test data.

Once the test cases are ready then these test cases are reviewed by peer members or
team lead.

Also, the test team prepares the Requirement Traceability Matrix (RTM). RTM traces
the requirements to the test cases that are needed to verify whether the
requirements are fulfilled. The deliverables of this phase are Test Cases, Test Scripts,
Test Data, Requirements Traceability Matrix

What I do in Test Design Phase as a Software Tester?

During the Test Design phase, I start creating test cases based on the requirements
gathered. I focus on writing test cases that cover both functional and non-functional
requirements. I make sure each test case includes clear steps and expected results.
Besides, I also work on preparing test data and identifying the criteria for test
automation if needed.

Entry Criteria: Requirements Documents (Updated version of unclear or missing

requirement)

Deliverables: Test cases, Test Scripts (if automation), Test data.

In this phase, Selenium would be the most popular tool to use. However, its
complexities and programming experience needed to Python or C# would definitely
pose a problem to your manual QAs and automation freshers.

Here, Katalon Studio would be your go-to choice in simplifying Selenium’s essential
capabilities through codeless automation, built-in keywords, and pre-defined artifact
templates for test suites.

Must Read: How To Write Test Cases

4. Test Environment Setup

This phase can be started in parallel with the Test design phase.

The test environment setup is done based on the hardware and software
requirement list. In some cases, the test team may not be involved in this phase. The
development team or customer provides the test environment.

Meanwhile, the test team should prepare the smoke test cases to check the readiness
of the given test environment.

What I do in Test Environment Setup Phase as a Software Tester?

In the Test Environment Setup phase, I ensure that the testing environment is ready
for execution. This involves setting up hardware and software requirements,
configuring test servers, and ensuring network settings are correctly applied.
Sometimes, this phase might involve collaboration with the development or IT team
to get everything in place. The goal is to mimic the production environment as
closely as possible.

Entry Criteria: Test Plan, Smoke Test cases, Test Data

Deliverables: Test Environment. Smoke Test Results.

5. Test Execution
The test team starts executing the test cases based on the planned test cases. If a test
case result is Pass/Fail then the same should be updated in the test cases.
The defect report should be prepared for failed test cases and should be reported to
the Development Team through a bug tracking tool for fixing the defects.

Retesting will be performed once the defect was fixed. Click here to see the Bug Life
Cycle.

What I do in Test Execution Phase as a Software Tester?

Once the environment is set up, I move to the Test Execution phase where I actually
run the test cases. Here, I record the outcomes and compare them with the expected
results. Any deviations or defects found are reported, tracked, and retested once
fixed. The objective is to ensure that the software behaves as expected under
different conditions.

Entry Criteria: Test Plan document, Test cases, Test data, Test Environment.

Deliverables: Test case execution report, Defect report, RTM

Must Read: How To Write An Effective Defect Report

6. Test Closure
The final stage where we prepare Test Closure Report, Test Metrics.

The testing team will be called out for a meeting to evaluate cycle completion criteria
based on Test coverage, Quality, Time, Cost, Software, Business objectives.

The test team analyses the test artifacts (such as Test cases, Defect reports, etc.,) to
identify strategies that have to be implemented in the future, which will help to
remove process bottlenecks in the upcoming projects.

Test metrics and Test closure report will be prepared based on the above criteria.

What I do in Test Closure Phase as a Software Tester?

Finally, in the Test Closure phase, I summarize the testing process and results. This
involves evaluating whether all the objectives were met and documenting any
learnings or improvements for future projects. I prepare a test summary report that
includes metrics, defect logs, and an overall assessment of the software quality. This
phase also ensures that all test artifacts are archived for future reference.

Entry Criteria: Test Case Execution report (make sure there are no high severity
defects opened), Defect report

Deliverables: Test Closure report, Test metrics

Advantages of STLC
 Early Detection of Defects: By testing early in the development cycle, defects can be
found and fixed sooner. This helps to avoid bigger problems later on.
 Improved Quality: With systematic testing, the quality of the software improves.
Each feature is checked to make sure it works as expected.
 Better Planning: Testing with clear goals and phases makes it easier to plan and
track progress. Teams know what needs to be tested and when.
 Cost Savings: Finding and fixing issues early is often cheaper than doing so later in
the development process. This can save money and time.
 Clear Requirements: Testing involves reviewing requirements thoroughly. This
ensures that everyone understands what is needed and helps avoid
misunderstandings.
 Efficient Use of Resources: Proper planning and early testing lead to a more efficient
use of time and resources. Teams can focus on what is important and prioritize their
tasks.

STLC and SDLC are both parts of the process of developing software, but they serve different
purposes.
SDLC is the process used to plan, create, test, and deploy software. It is the overall process
of software development. It starts by gathering requirements from the client or
stakeholders, then moves on to design, coding, testing, and eventually deployment and
maintenance of the software.
STLC, on the other hand, focuses entirely on the testing part of software development. It
starts as soon as requirements are gathered, and includes phases such as test planning,
designing test cases, setting up the test environment, executing tests, and finally closing the
tests by evaluating the results.
The main difference is their scope. SDLC covers the whole process of creating software from
start to finish, while STLC focuses just on making sure the software works properly and
meets the requirements. Both are important and work together to ensure that high-quality
software is delivered.