Software Testing Assignment

Md. Asif Samrat (ID: 221902117)

Date: 17 February 2026

1. Software Testing: Definition and Importance

Software testing is the systematic process of evaluating a software product
to ensure it works correctly and meets requirements[1][2]. In other
words, it verifies that each function of the application satisfies its design
specifications and user needs. Testing is crucial because it catches defects
early – revealing bugs, performance issues or security flaws before release –
which leads to higher quality software and reduced costs[3][4]. For example,
discovering a critical bug during testing prevents costly fixes after
deployment (as illustrated by historical incidents like the 2018 Boeing MCAS
failure). Rigorous testing builds confidence that the software is reliable and
safe to use (Susnjara & Smalley, 2023)[3].

2. Verification vs Validation; Objectives of SQA

Verification and Validation are complementary processes in testing.
Verification asks “Are we building the product right?” – it ensures the
software’s work-products (requirements, design, code) conform to
specifications through reviews and static analyses[5]. By contrast,
Validation asks “Are we building the right product?” – it involves executing
the software to check it fulfills intended use and meets user needs[6][7]. For
example, code inspections and design reviews are verification activities,
while running functional tests on the final application is validation.
The objective of Software Quality Assurance (SQA) is to ensure high
software quality by preventing defects and enforcing processes. SQA is a
process-oriented, preventive approach that focuses on defining and following
standards throughout the development life cycle[8]. Key SQA goals include
defect prevention, continuous process improvement, and compliance
with standards[8]. By establishing clear quality plans and checkpoints (e.g.
requirement reviews, audits, and testing strategies), SQA reduces risks and
ensures that processes are followed. Ultimately, SQA strives to ensure the
final product meets customer expectations and quality standards[9][10].
3. Four Levels of Testing in SDLC

The four main levels of testing in the Software Development Life Cycle
are Unit Testing, Integration Testing, System Testing, and Acceptance
Testing[11][12]. Each serves a distinct purpose:
 Unit Testing: Developers test individual components or functions in
isolation[13]. The goal is to verify that each small part works correctly
on its own before it is combined with others. Example: Testing the
“Submit Assignment” function in the code to ensure it accepts valid
files and rejects invalid ones. By catching bugs at this level, unit tests
make later debugging easier[13].

 Integration Testing: After unit tests pass, this level checks that
modules work together properly[14]. For instance, testers might
verify that the Assignment Submission module correctly interacts with
the user authentication module and the database. It ensures data flows
correctly between integrated components, catching interface or
interaction issues[14]. Example: Confirming that when a student
uploads an assignment, the gradebook module and notification system
update correctly.

 System Testing: Here the entire system is tested as a whole[15].

Both functional requirements (features) and non-functional aspects
(performance, security, usability) are validated in a real-world
environment. Example: Testing the full Student Management System
end-to-end: ensuring a student can log in, submit assignments, and a
teacher can grade them without errors. This level verifies the system
meets overall requirements[15].

 Acceptance Testing: Also called User Acceptance Testing (UAT), this

is the final test by stakeholders[12]. Users or customers verify that the
 software meets their needs and give approval. For example, a group of
instructors might test the Assignment Submission interface to ensure it
is user-friendly and meets institutional rules (deadline handling,
feedback workflow). Passing UAT means the software is ready for
release[12].

The diagram above illustrates these testing levels in the development

process, from low-level unit tests to high-level user acceptance.

4. White-box vs Black-box Testing

In software testing, white-box and black-box approaches serve different
goals:

Aspect White-Box Testing Black-Box Testing

Goal Verify internal code Verify external
logic and structure. functionality
Testers use against
knowledge of the specifications.
source code to Testers treat the
design tests (e.g. system as a “black
path coverage, box,” ensuring
branch coverage). required behaviors
The focus is on occur for given
exercising the code inputs without
internals[16][17]. concern for internal
code[16][18].
Advantages Thorough: can find No programming
hidden errors and knowledge needed:
cover all code testers can start
paths. Enables early using
maximum coverage requirement
since tester knows documents[18].
the code[17]. Tests are unbiased
Developers/testers (tester does not
can pinpoint logic write code).
flaws. Efficient at higher
levels: quick to
perform and
reveals
specification
mismatches.
Limitations Time-consuming Limited coverage:
and requires internal paths
technical skill. might never be
Developing tested. Difficult to
Aspect White-Box Testing Black-Box Testing
exhaustive tests for achieve complete
every path is labor- test cases and may
intensive[19]. May miss corner-case
miss missing bugs in code[20].
requirements Relies on good
(focuses only on specifications;
written code). writing thorough
test cases can be
slow and
challenging[20].

For example, white-box testing’s goal is “ensuring that the internal code…is
correct and efficient”[21], while black-box aims to “test the functionality…
meets requirements”[22]. As a result, white-box can achieve high coverage
and catch deep logical errors[17], but it requires knowledgeable testers and
more effort[23]. In contrast, black-box testing is quick to begin (once specs
are ready) and easy for non-programmers[18], but it risks missing code-level
defects and incomplete coverage[20]. The table summarizes these trade-
offs.

5. Recommended Testing Techniques for the Assignment

Submission Module
For the Assignment Submission module of a Student Management System,
appropriate testing techniques include:
 Equivalence Partitioning and Boundary-Value Analysis: These
black-box design techniques divide input data into valid and invalid
partitions and specifically test edge cases[24]. For example, if the
module accepts file sizes up to 50 MB, boundary-value testing would
try 49 MB, 50 MB, and 51 MB files. Equivalence partitioning would test
one typical valid file (e.g. a 10 MB PDF) and one invalid (e.g. a 100 MB
PDF). This ensures input fields (file size, date of submission, number of
attachments, etc.) handle normal and extreme values correctly[24].
Such testing is suitable here because the module has clear numeric
limits (e.g. deadlines, file size limits) that benefit from boundary
checks.

 Decision Table Testing: This technique creates a table of

combinations of input conditions and their expected outcomes. It is
effective when multiple factors influence behavior[25]. For the
Submission module, conditions like (Submitted before deadline?
Yes/No) and (File type allowed? Yes/No) could be combined in a
decision table to ensure all scenarios are covered (e.g., on-time valid
submission, late submission, invalid file type, etc.). Decision tables
 systematically capture business rules (such as late-submission
penalties or required file formats) and help derive test cases for each
rule combination[25]. This technique is suitable because the module’s
behavior depends on several yes/no conditions (dates, user
authentication, file validity) that can be neatly expressed in a decision
table to ensure thorough testing.

These techniques together ensure the module’s inputs and business logic are
thoroughly tested from both typical and edge-case perspectives, improving
confidence that it will work correctly under all expected conditions.

References
 Fiorenza, I. (2024, March 24). Quality assurance in software: what it is
and what it does. W&B Asset Studio.
 GeeksforGeeks. (2025, July 23). Decision table based testing in
software testing. Retrieved from
[Link]
based-testing-in-software-testing/
 GeeksforGeeks. (2025, July 23). Software testing – Boundary value
analysis. Retrieved from [Link]
testing/software-testing-boundary-value-analysis/
 GeeksforGeeks. (2025, Dec 12). Differences between Verification and
Validation. Retrieved from [Link]
engineering/differences-between-verification-and-validation/
 GeeksforGeeks. (2026, Jan 10). What is Software Testing? Retrieved
from [Link]
basics/
 Susnjara, S., & Smalley, I. (2023). Software testing, defined. IBM.
Retrieved from [Link]
 TestSigma Team. (2022, Nov 19). Key differences between Black Box
and White Box Testing. Retrieved from [Link]
differences-between-black-box-and-white-box-testing/

[1] [3] What is Software Testing? | IBM

[Link]
[2] What is Software Testing? - GeeksforGeeks
[Link]
[4] 11 Reasons Why Software Testing is Important
[Link]
[5] [6] [7] Verification Vs Validation - GeeksforGeeks
[Link]
verification-and-validation/
[8] [9] Quality Assurance in software: what it is and what it does – W&B Asset
Studio
[Link]
it-is-and-what-it-does/
[10] Software Quality Assurance - Software Engineering - GeeksforGeeks
[Link]
software-quality-assurance/
[11] [12] [13] [14] [15] Levels of Software Testing - GeeksforGeeks
[Link]
[16] [21] [22] Differences between Black Box Testing and White Box Testing
- GeeksforGeeks
[Link]
box-testing-vs-white-box-testing/
[17] [18] [19] [20] [23] Key Differences Between Black Box And White Box
Testing
[Link]
box-testing/
[24] Software Testing - Boundary Value Analysis - GeeksforGeeks
[Link]
value-analysis/
[25] Decision Table Based Testing in Software Testing - GeeksforGeeks
[Link]
testing-in-software-testing/