Software Engineering (AL-403) - Unit 4 Short Notes

How unit 4 is examined

This unit covers static and dynamic analysis, the levels and techniques of testing, and object-oriented versus function-oriented development; test techniques, white-box, integration, system testing and the OO comparison carry the most marks.

Software Static and Dynamic analysis

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Low weight</span>

Definition. <mark>Static analysis examines the code without executing it, while dynamic analysis examines the behaviour of the program by executing it with test data.</mark>

Key points.

1. Static analysis uses reviews, inspections, walkthroughs and tools such as lint, SonarQube and compilers' warnings, so it finds defects early, before the program runs.
2. Dynamic analysis uses testing, profiling and memory-leak detectors such as Valgrind, JUnit and gprof, so it finds runtime failures, performance and memory problems.
3. Static analysis finds coding-standard violations, unreachable code and uninitialised variables; dynamic analysis finds wrong outputs, crashes and race conditions.
4. The two are complementary: static checks are cheap and cover all paths in principle, dynamic checks show real behaviour but only for the inputs tried.

Asked: [7 marks] (Jun 2025) Differentiate between static and dynamic code analysis.

Code inspections

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Low weight</span>

Definition. <mark>A code inspection is a formal, peer-led review of source code against a checklist, done to find defects before testing.</mark>

Key points.

1. Fagan's inspection has roles: moderator, author, reader, inspector and recorder, and the author does not defend the code.
2. The process is planning, overview, individual preparation with a checklist, the inspection meeting, rework and follow-up.
3. Early defect detection is cheaper, since a defect found in code costs far less than one found in the field.
4. Inspections improve quality assurance because they spread knowledge, enforce standards and find defects that testing misses.

Asked: [7 marks] (Jun 2026) Discuss the importance of Code Inspection in software quality assurance.

Software Testing Fundamentals

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Medium weight</span>

Definition. <mark>Software testing is the process of executing a program with the intent of finding errors; verification asks "are we building the product right?" and validation asks "are we building the right product?"</mark>

Key points.

1. The strategic approach starts at the module (unit) level and moves outward to integration, system and acceptance testing.
2. Verification checks that each phase's output conforms to the previous phase, using reviews and inspections, without running the code.
3. Validation checks the final product against the customer's needs, using testing on the running software.
4. Testing must be planned early, and effective reviews before testing reduce the errors that testing must find.
5. Regression testing re-runs old tests after every change to confirm nothing else broke.

Answer frame. Open with the definition of testing and of a strategy; draw the levels ladder; develop points 1-6, then the table; close that verification plus validation give quality assurance.

Asked: [7 marks] (Jun 2020) Discuss software testing strategies. Differentiate between Verification and Validation. Asked: [7 marks] (Jun 2023) What are the strategic approaches to software testing? Explain in detail.

Software Test Process

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Low weight</span>

Definition. <mark>The test process is the planned sequence of test planning, test case design, execution and evaluation, applied level by level from unit to acceptance.</mark>

Diagram. <figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u4-01" viewBox="0 0 467 252" width="467" height="252" role="img" aria-label="Test process. Pl = plan, De = design test cases, Ex = execute, Ev = evaluate against expected results, Fix = debug and retest"><style>#dsfig-u4-01 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u4-01 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u4-01 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u4-01 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u4-01 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u4-01 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u4-01 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u4-01 .t{fill:#16181D;font-weight:500}#dsfig-u4-01 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u4-01 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u4-01 .dot{fill:#16181D}#dsfig-u4-01 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u4-01 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u4-01 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u4-01 .ah{fill:#454C5A}#dsfig-u4-01 .ah.hi{fill:#2340B8}#dsfig-u4-01 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u4-01 .wl .t{font-size:12px;font-weight:700}#dsfig-u4-01 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u4-01 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u4-01 .e{stroke:#B1B7C3}html.dark #dsfig-u4-01 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u4-01 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u4-01 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u4-01 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u4-01 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u4-01 .t{fill:#E6E8ED}html.dark #dsfig-u4-01 .t.inv{fill:#0F1115}html.dark #dsfig-u4-01 .kd{stroke:#E6E8ED}html.dark #dsfig-u4-01 .dot{fill:#E6E8ED}html.dark #dsfig-u4-01 .ann{fill:#8FA3FF}html.dark #dsfig-u4-01 .lbl{fill:#858D9C}html.dark #dsfig-u4-01 .ptr{fill:#8FA3FF}html.dark #dsfig-u4-01 .ah{fill:#B1B7C3}html.dark #dsfig-u4-01 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u4-01 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u4-01 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u4-01 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah14" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah" d="M0,1 L9,5 L0,9 z"/></marker><marker id="ahh14" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah hi" d="M0,1 L9,5 L0,9 z"/></marker></defs><path class="e" d="M59,40 L148,40" marker-end="url(#ah14)"/><path class="e" d="M188,40 L277,40" marker-end="url(#ah14)"/><path class="e" d="M317,40 L406,40" marker-end="url(#ah14)"/><path class="e" d="M415.6,55.2 L310.6,195.2" marker-end="url(#ah14)"/><path class="e" d="M298,193 L298,61" marker-end="url(#ah14)"/><circle class="n" cx="40" cy="40" r="18"/><text class="t" x="40" y="40" dy=".35em" text-anchor="middle">Pl</text><circle class="n" cx="169" cy="40" r="18"/><text class="t" x="169" y="40" dy=".35em" text-anchor="middle">De</text><circle class="n" cx="298" cy="40" r="18"/><text class="t" x="298" y="40" dy=".35em" text-anchor="middle">Ex</text><circle class="n" cx="427" cy="40" r="18"/><text class="t" x="427" y="40" dy=".35em" text-anchor="middle">Ev</text><circle class="n" cx="298" cy="212" r="18"/><text class="t" x="298" y="212" dy=".35em" text-anchor="middle">Fix</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">Test process. Pl = plan, De = design test cases, Ex = execute, Ev = evaluate against expected results, Fix = debug and retest</figcaption></figure>

Key points.

1. Test cases with expected results are designed from the requirements or code and then run at unit, integration, system and acceptance levels.
2. Actual output is compared with expected output, and each mismatch is logged as a defect for debugging.
3. After a fix the tests are repeated, and testing stops when the exit criteria are met.

Asked: [7 marks] (Jun 2022) How is software being tested? Explain the process with a neat sketch.

Testing Levels

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Medium weight</span>

Definition. <mark>Testing levels are the stages of testing, unit, integration, system and acceptance, each checking the software at a larger scope.</mark>

Diagram. <figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u4-02" viewBox="0 0 474 80" width="474" height="80" role="img" aria-label="Levels. Unit tests modules, Int tests module interfaces, Sys tests the whole system, Acc is customer acceptance"><style>#dsfig-u4-02 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u4-02 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u4-02 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u4-02 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u4-02 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u4-02 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u4-02 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u4-02 .t{fill:#16181D;font-weight:500}#dsfig-u4-02 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u4-02 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u4-02 .dot{fill:#16181D}#dsfig-u4-02 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u4-02 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u4-02 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u4-02 .ah{fill:#454C5A}#dsfig-u4-02 .ah.hi{fill:#2340B8}#dsfig-u4-02 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u4-02 .wl .t{font-size:12px;font-weight:700}#dsfig-u4-02 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u4-02 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u4-02 .e{stroke:#B1B7C3}html.dark #dsfig-u4-02 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u4-02 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u4-02 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u4-02 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u4-02 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u4-02 .t{fill:#E6E8ED}html.dark #dsfig-u4-02 .t.inv{fill:#0F1115}html.dark #dsfig-u4-02 .kd{stroke:#E6E8ED}html.dark #dsfig-u4-02 .dot{fill:#E6E8ED}html.dark #dsfig-u4-02 .ann{fill:#8FA3FF}html.dark #dsfig-u4-02 .lbl{fill:#858D9C}html.dark #dsfig-u4-02 .ptr{fill:#8FA3FF}html.dark #dsfig-u4-02 .ah{fill:#B1B7C3}html.dark #dsfig-u4-02 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u4-02 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u4-02 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u4-02 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah15" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah" d="M0,1 L9,5 L0,9 z"/></marker><marker id="ahh15" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah hi" d="M0,1 L9,5 L0,9 z"/></marker></defs><path class="e" d="M66,40 L148,40" marker-end="url(#ah15)"/><path class="e" d="M188,40 L277,40" marker-end="url(#ah15)"/><path class="e" d="M317,40 L406,40" marker-end="url(#ah15)"/><rect class="n" x="15" y="25" width="50" height="30" rx="15"/><text class="t" x="40" y="40" dy=".35em" text-anchor="middle">Unit</text><circle class="n" cx="169" cy="40" r="18"/><text class="t" x="169" y="40" dy=".35em" text-anchor="middle">Int</text><circle class="n" cx="298" cy="40" r="18"/><text class="t" x="298" y="40" dy=".35em" text-anchor="middle">Sys</text><circle class="n" cx="427" cy="40" r="18"/><text class="t" x="427" y="40" dy=".35em" text-anchor="middle">Acc</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">Levels. Unit tests modules, Int tests module interfaces, Sys tests the whole system, Acc is customer acceptance</figcaption></figure>

Key points.

1. Unit testing tests the smallest module in isolation, by the developer, using drivers (which call the unit) and stubs (which stand in for called modules).
2. Integration testing checks that combined modules work together, mainly at their interfaces, by developers or testers.
3. System testing tests the complete integrated system against the SRS, by an independent test team.
4. Acceptance testing lets the customer decide whether to accept the system, in alpha and beta form.
5. Example: for max(a,b), test (3,5)->5, (5,3)->5, (4,4)->4; benefit is early bug isolation, limitation is that interface faults stay hidden.

Answer frame. Open with the definition of levels; draw the ladder; explain each level with who and when, then the V&V table for Verification and validation; close that the levels catch faults progressively.

Asked: [7 marks] (Dec 2020) Differentiate between (i) Verification and validation (ii) Unit testing and system testing. Asked: [7 marks] (Jun 2023) What is unit testing in software Engineering? Explain with suitable example. Asked: [7 marks] (Dec 2024) With neat sketch explain briefly about testing levels?

Test Criteria

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>A test criterion is a rule that decides which test cases are needed and when testing is complete, such as statement, branch or path coverage.</mark>

Key points.

1. Coverage criteria measure the fraction of code elements exercised: $\text{Coverage} = \frac{\text{elements exercised}}{\text{total elements}} \times 100$.
2. Statement coverage is weaker than branch coverage, and branch coverage is weaker than path coverage.
3. Black-box criteria are based on the specification, such as every equivalence class and every boundary.

Test Case Design

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>A test case is a set of inputs, execution conditions and expected results designed to check one specific behaviour.</mark>

Key points.

1. A test case has an ID, description, preconditions, input data, expected output, actual output and pass or fail status.
2. Cases are designed with black-box techniques from the specification and white-box techniques from the code.

TestOracles

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Low weight</span>

Definition. <mark>A test oracle is the mechanism that supplies the expected result for a test input, against which the actual output is judged pass or fail.</mark>

Key points.

1. Without an oracle a tester cannot say whether an output is correct, so the oracle is what turns execution into a test.
2. Oracles can be the specification, a human expert, a previous version, or a trusted reference program.
3. The test techniques an oracle serves are black-box (from specification, no code knowledge) and white-box (from code structure); the oracle compares expected with actual output in both.

Asked: [7 marks] (Dec 2024) What is Test Oracles? Explain different types of test techniques.

Test Techniques

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">High weight</span>

Definition. <mark>Test techniques are systematic methods for choosing test cases: black-box techniques use only the specification, and white-box techniques use the internal structure of the code.</mark>

Key points.

1. Black-box (functional, behavioural) testing treats the software as a closed box and checks outputs for given inputs.
2. Its techniques are equivalence partitioning, boundary value analysis, cause-effect graphing, decision tables and error guessing.
3. White-box (glass-box, structural) testing uses knowledge of the code to design tests.
4. Its techniques are statement, branch, condition and path coverage, and basis path testing with cyclomatic complexity.
5. Black-box finds missing functions but may leave code untested; white-box exercises all code but cannot find missing features.

Answer frame. For the comparison, open with both definitions, give the table, close with "both are needed, gray-box combines them". For the techniques question, open with the definition; list black-box then white-box techniques with one example each (points 2-5); close with the applicability line of point 6.

Asked: [7 marks] (May 2019, Jun 2022) Discuss the differences between black box and white box testing models. Asked: [7 marks] (Dec 2020, Jun 2026) Discuss the various black box and white box testing techniques with suitable example? Explain the software testing techniques in detail.

Black-Box Testing

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Medium weight</span>

Definition. <mark>Black-box testing tests the functionality of software against its specification, without any knowledge of the internal code.</mark>

Key points.

1. Equivalence partitioning divides inputs into classes that the program treats alike, so one test from each class represents the class.
2. Boundary value analysis (BVA) tests at the edges of each class, because errors cluster at boundaries: for range min to max, use min-1, min, min+1, max-1, max, max+1.
3. Cause-effect graphing and decision tables handle combinations of conditions and their resulting actions.
4. Testers need no code knowledge and stay unbiased, but hidden code paths stay untested.

Example. A field accepts marks 1 to 100 (0-39 fail, 40-100 pass). BVA cases and results, checked by running the code:

Second example: age 18-60 gives 17, 18, 19, 59, 60, 61.

Answer frame. Open with the definition of black-box testing; state BVA and its rules; develop the example table; close with advantages and limitations.

Asked: [7 marks] (May 2019) What do you mean by boundary value analysis? Give two examples of boundary value testing. Asked: [7 marks] (Jun 2024, Jun 2025) What is Black-Box testing? What is boundary value Analysis? Explain the technique Specifying rules and its usage with the help of an example.

White-Box Unit Testing and Unit Testing Frameworks

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">High weight</span>

Definition. <mark>White-box (glass-box or structural) testing designs test cases from the internal logic of the code, to exercise its statements, branches and paths.</mark>

Key points.

1. Statement coverage requires every statement to execute at least once, and it is the weakest criterion.
2. Branch coverage requires every decision to take both true and false outcomes at least once.
3. Path coverage requires every independent path through the code to execute; basis path testing uses cyclomatic complexity $V(G) = E - N + 2$ or the number of predicates plus one.
4. Carrying it out: draw the flow graph from the code, find the independent paths, design one test case per path with its expected output, run them and compare results.
5. Difficulty: exhaustive path testing is impossible because loops make the number of paths explode.
6. Difficulty: it cannot detect missing functions, and it is data sensitive, since a path may be correct for some data and wrong for others.
7. Difficulty: it needs skilled testers who know the code, so it costs expertise and effort.
8. Unit testing frameworks such as JUnit and pytest automate the running of unit tests and reporting of results.

Example. In the function below, tests 0, 50 and 20 give statement and branch coverage; with three predicates, $V(G)=3+1=4$, so basis path testing needs four tests: 0, 101, 50, 20.

def cat(x):
    if x < 1 or x > 100: return "invalid"
    if x >= 40: return "pass"
    return "fail"
# cat(0) invalid, cat(50) pass, cat(20) fail

Answer frame. Open with the definition; state criteria (points 1-3); show point 4 on the code example; close with difficulties 5-7.

Asked: [14 marks] (Jun 2020, Nov 2023, Jun 2024) What is white box testing and what is the difficulty while exercising it? Write a short note on any two: (a) Structured methods (b) White-Box Testing (c) Feasibility Analysis (d) Test Case Design Asked: [7 marks] (Jun 2024) What is White-Box testing? How white box testing is carried out ? Demonstrate With example.

Integration Testing

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">High weight</span>

Definition. <mark>Integration testing combines unit-tested modules step by step and tests them together to expose interface and interaction faults.</mark>

Diagram. <figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u4-03" viewBox="0 0 360 198" width="360" height="198" role="img" aria-label="Module hierarchy. Top-down tests A first with stubs for B and C; bottom-up tests D, E, F, G first with drivers"><style>#dsfig-u4-03 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u4-03 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u4-03 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u4-03 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u4-03 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u4-03 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u4-03 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u4-03 .t{fill:#16181D;font-weight:500}#dsfig-u4-03 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u4-03 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u4-03 .dot{fill:#16181D}#dsfig-u4-03 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u4-03 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u4-03 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u4-03 .ah{fill:#454C5A}#dsfig-u4-03 .ah.hi{fill:#2340B8}#dsfig-u4-03 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u4-03 .wl .t{font-size:12px;font-weight:700}#dsfig-u4-03 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u4-03 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u4-03 .e{stroke:#B1B7C3}html.dark #dsfig-u4-03 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u4-03 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u4-03 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u4-03 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u4-03 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u4-03 .t{fill:#E6E8ED}html.dark #dsfig-u4-03 .t.inv{fill:#0F1115}html.dark #dsfig-u4-03 .kd{stroke:#E6E8ED}html.dark #dsfig-u4-03 .dot{fill:#E6E8ED}html.dark #dsfig-u4-03 .ann{fill:#8FA3FF}html.dark #dsfig-u4-03 .lbl{fill:#858D9C}html.dark #dsfig-u4-03 .ptr{fill:#8FA3FF}html.dark #dsfig-u4-03 .ah{fill:#B1B7C3}html.dark #dsfig-u4-03 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u4-03 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u4-03 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u4-03 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah16" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah" d="M0,1 L9,5 L0,9 z"/></marker><marker id="ahh16" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah hi" d="M0,1 L9,5 L0,9 z"/></marker></defs><line class="e" x1="168" y1="39" x2="80" y2="103"/><line class="e" x1="168" y1="39" x2="256" y2="103"/><line class="e" x1="80" y1="103" x2="36" y2="167"/><line class="e" x1="80" y1="103" x2="124" y2="167"/><line class="e" x1="256" y1="103" x2="212" y2="167"/><line class="e" x1="256" y1="103" x2="300" y2="167"/><circle class="n" cx="168" cy="39" r="17"/><text class="t" x="168" y="39" dy=".35em" text-anchor="middle">A</text><circle class="n" cx="80" cy="103" r="17"/><text class="t" x="80" y="103" dy=".35em" text-anchor="middle">B</text><circle class="n" cx="36" cy="167" r="17"/><text class="t" x="36" y="167" dy=".35em" text-anchor="middle">D</text><circle class="n" cx="124" cy="167" r="17"/><text class="t" x="124" y="167" dy=".35em" text-anchor="middle">E</text><circle class="n" cx="256" cy="103" r="17"/><text class="t" x="256" y="103" dy=".35em" text-anchor="middle">C</text><circle class="n" cx="212" cy="167" r="17"/><text class="t" x="212" y="167" dy=".35em" text-anchor="middle">F</text><circle class="n" cx="300" cy="167" r="17"/><text class="t" x="300" y="167" dy=".35em" text-anchor="middle">G</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">Module hierarchy. Top-down tests A first with stubs for B and C; bottom-up tests D, E, F, G first with drivers</figcaption></figure>

Key points.

1. Top-down integration starts from the main module and adds lower modules in depth-first or breadth-first order, using stubs for modules not yet integrated.
2. Bottom-up integration starts with the lowest-level modules, grouped into clusters, and uses drivers to call them until the main module is reached.
3. Sandwich (mixed) integration tests top layers top-down and bottom layers bottom-up, meeting in the middle.
4. Big-bang integration joins all modules at once, which is simple but makes faults hard to locate.
5. Advantages: interface faults are found early and each step localises the fault; challenges are writing stubs and drivers and the effort of retesting.
6. Example: in payroll, the report module is tested with a stub for the tax module, or the tax module is tested first through a driver.

Answer frame. Open with the definition; draw the module tree; develop points 1-4 with the example; give the table for the differentiate question; close with points 5.

Asked: [7 marks] (Jun 2020) Differentiate between top down and bottom up integration testing. Asked: [7 marks] (Nov 2023, Jun 2024) Discuss about integration testing with suitable example. Asked: [7 marks] (Jun 2024) Briefly discuss about Integration testing Strategies?

System Testing and other Specialized Testing

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">High weight</span>

Definition. <mark>System testing tests the complete integrated software as a whole against the system requirements, to check it behaves correctly in its intended environment.</mark>

Key points.

1. Its objective is to verify functional and non-functional requirements of the whole system, by an independent team; entry criteria are integration done and environment ready, exit criteria are all planned tests run and no critical defect open.
2. Recovery testing forces failures such as a crash and checks that the system recovers and no data is lost.
3. Security testing checks that authentication, authorisation and data protection resist misuse.
4. Stress testing pushes load beyond limits to see how and where the system breaks.
5. Performance testing measures response time and throughput under normal load.
6. Difference from integration testing: integration tests module interfaces, system testing tests the whole product against the SRS.
7. Acceptance testing is done by the customer: steps are planning the acceptance criteria, designing test cases, executing them, evaluating the results and deciding to accept or reject.
8. Alpha testing is done at the developer's site by internal users; beta testing is done at the customer's site by real users in a real environment.

Answer frame. For system testing, open with its definition, list the types (points 2-5) with one example each, add the process and difference from integration, and close on exit criteria. For acceptance, open with the definition, list the four steps of point 7, then alpha versus beta.

Asked: [7 marks] (May 2019, Jun 2023, Nov 2023) What do you mean by system testing? Explain in detail. What is software testing and system testing? What is system testing. Discuss about different types of system testing. Asked: [7 marks] (Nov 2023) What are the steps of acceptance testing? Explain in detail.

Test Plan

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Low weight</span>

Definition. <mark>A test plan is a document that describes the scope, approach, resources and schedule of testing activities.</mark>

Key points.

1. Its objective is to guide testing and be agreed by the team and customer before testing starts.
2. Contents are the test items, features to be tested, approach, entry and exit criteria, and pass or fail criteria.
3. Parameters are scope, resources (people, tools and test environment), schedule, risks and deliverables such as test cases and defect reports.

Asked: [7 marks] (Jun 2022) What is a test plan? What are the different parameters used for testing. Explain.

Test Metrics

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Low weight</span>

Definition. <mark>Test metrics are quantitative measures of the testing process, the product under test and the project, used to judge progress and quality.</mark>

Key points.

1. Process metrics measure the testing process, such as test cases executed per day and defect detection efficiency.
2. Product metrics measure the software, such as defect density $= \text{defects} / \text{KLOC}$ (30 defects in 15 KLOC is 2 per KLOC) and code coverage.
3. Project metrics measure effort, cost and schedule of testing.
4. Their purpose is to track progress, assess quality and measure productivity.

Asked: [7 marks] (Jun 2023) What are test metrics and its types? What is the purpose of testing metrics? Explain.

Testing Tools

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>Testing tools are programs that automate test execution, coverage measurement or defect tracking.</mark>

Key points.

1. Selenium automates browser-based functional tests, and JUnit automates unit tests.
2. Load tools such as JMeter test performance, and Bugzilla or JIRA track defects.

Introduction to Object-oriented analysis, design and comparison with structured Software Engg

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">High weight</span>

Definition. <mark>Object-oriented development models the system as interacting objects that combine data and operations, while function-oriented (structured) development decomposes it into functions that operate on shared data.</mark>

Key points.

1. Object-oriented analysis (OOA) identifies objects, classes, attributes, operations and relationships from the problem domain, and models them in UML.
2. Object-oriented design (OOD) refines the classes, adds interfaces and applies encapsulation, inheritance and polymorphism.
3. Structured analysis uses data flow diagrams, data dictionary and ER diagrams, and structured design uses structure charts.
4. In OO, data and functions are bound in a class, so data is hidden; in the function-oriented approach data is global and functions share it.
5. OO gives high reusability through inheritance and libraries; function-oriented reuse is mainly through function libraries.
6. OO fits large, changing systems, while the function-oriented approach suits small, stable, process-centric problems.

Answer frame. Open with both definitions; give the 7-row table; add DFD versus UML examples and OOA features (points 1-2); close with the suitability line of point 6.

Asked: [7 marks] (May 2019, Dec 2024, Jun 2026) Differentiate between function-oriented and object-oriented software development. Differentiate Object-Oriented Analysis and Structured Software Engineering in detail. Asked: [7 marks] (Dec 2024) Differentiate between Function-Oriented and Object-Oriented Software development?

Last-minute revision

• Verification means building the product right; validation means building the right product.
• Levels in order: unit, integration, system, acceptance.
• Unit tests use drivers to call modules and stubs to replace called modules.
• BVA for range min to max tests min-1, min, min+1, max-1, max, max+1.
• Cyclomatic complexity $V(G)=E-N+2$, or predicates plus one.
• Coverage strength: statement, then branch, then path.
• Top-down uses stubs; bottom-up uses drivers.
• System testing types: recovery, security, stress, performance.
• Defect density is defects per KLOC.

Memory hooks

• "Stub stands in, Driver drives": top-down needs stubs, bottom-up needs drivers.
• "RSSP" for system testing: Recovery, Security, Stress, Performance.
• "Black sees Behaviour, White sees Where (code)".
• Alpha is Ours (developer site), Beta is Buyer's.

Coverage checklist

• Software Static and Dynamic analysis: static versus dynamic.
• Code inspections: importance of inspection.
• Software Testing Fundamentals: strategies, V&V, strategic approaches.
• Software Test Process: process sketch.
• Testing Levels: V&V, unit versus system, unit testing, levels sketch.
• Test Criteria: no past questions.
• Test Case Design: no past questions.
• TestOracles: oracles and techniques.
• Test Techniques: black versus white, techniques.
• Black-Box Testing: BVA, black-box with BVA.
• White-Box Unit Testing and Unit Testing Frameworks: white-box difficulty, how carried out.
• Integration Testing: top-down versus bottom-up, integration, strategies.
• System Testing and other Specialized Testing: system testing, acceptance steps.
• Test Plan: test plan and parameters.
• Test Metrics: metrics, types, purpose.
• Testing Tools: no past questions.
• Introduction to Object-oriented analysis, design and comparison with structured Software Engg: function versus object oriented.