THEORY EXAMINATION (SEM–VI) 2016-17 SOFTWARE TESTING

SOFTWARE TESTING (EIT062)

Section-wise Solved Answers & Notes

SECTION – A (10 × 2 = 20 Marks)

Short, precise answers

(a) Validation vs Verification

(b) Role of Review in Software Testing

Reviews help detect defects early, improve quality, reduce rework cost, and ensure compliance with requirements before testing begins.

(c) Factors responsible for requirement changes

• Changing customer needs                              • Market competition
• Technological changes                                    • Poor initial requirement analysis
• Regulatory changes

(d) Levels of Testing

• Unit Testing                                                      • Integration Testing
• System Testing                                                 • Acceptance Testing

(e) Testing vs Debugging

(f) Mutation Testing

Mutation testing checks test suite effectiveness by making small changes (mutants) in code and seeing if tests detect them.

(g) Impracticality of testing all paths

Due to large number of possible execution paths, testing all paths is impossible for real-world programs.

(h) Significance of Navigation Testing

Ensures correct navigation between pages/screens, especially in web and GUI applications, improving usability.

(i) Use Case Diagram – Library Management System

Actors:       • Librarian                                          • Student

Use cases:
                 • Issue book                                        • Return book
                 • Search book                                      • Maintain records

(Neat diagram to be drawn in exam)

(j) Software Evolution

Software evolution refers to continuous modification of software after delivery to fix defects, adapt to changes, and add features.

SECTION – B (Attempt Any Five) (5 × 10 = 50 Marks)

(a) Regression Testing & Code Coverage Prioritization

Regression Testing:
Re-testing software after changes to ensure existing functionality is not broken.

Code coverage prioritization:
Test cases are prioritized based on maximum code coverage first.

Example:
Test cases covering more branches/functions are executed earlier.

(b) Object Oriented Testing & Issues

Testing process:                                                 • Testing classes
• Testing class interactions                                   • Testing inheritance & polymorphism

Issues:
• Encapsulation hides data                                   • Dynamic binding
• Inheritance complexity

(c) Risk Matrix

A risk matrix evaluates probability vs impact of risks.

Steps:                                                                   Identify risks

Assign probability                                                 Assign impact

Categorize as high/medium/low priority

(d) State Chart Diagram                                        A state chart diagram shows state changes of a system.

Stack example:
States: Empty → Not Empty                                 Operations: push(), pop()

(Diagram to be drawn in exam)

(e) Static & Dynamic Testing Tools

Static testing tools:
• Code analyzers                                                  • Review tools

Dynamic testing tools:
• Unit testing tools (JUnit)                                   • Performance tools (LoadRunner)

(f) SRS & SDD Document Verification

SRS verification checklist:                                 • Completeness
• Consistency                                                        • Unambiguity
• Verifiability

SDD verification checklist:                                  • Correct architecture
• Interface clarity                                                    • Design standards

(g) Test, Test Case, Test Suite & Test Oracle

• Test: Execution to find defects                            • Test case: Input + expected output
• Test suite: Collection of test cases                      • Test oracle: Determines correctness

Scenario: Login system validation.

(h) Cause–Effect Graphing Technique

Technique converts requirements into logical conditions.

Notations:                                                            • Cause (input condition)
• Effect (output condition)                                     • Logical operators (AND, OR, NOT)

Example: ATM withdrawal rules.

SECTION – C (Attempt Any Two) (2 × 15 = 30 Marks)

Q3 (i) Activity Diagram                                           Activity diagram shows flow of control.

Basic symbols:
• Initial node                                                          • Activity
• Decision node                                                     • Final node

Q3 (ii) Student Division Program

Conditions:                                                            • Avg < 50 → Fail
• 50 ≤ Avg < 60 → Second division                      • Avg ≥ 60 → First division

Functions:
• getdata()                                                            • validate()
• calculate()

Test cases:

Cyclomatic complexity:

V(G)=Number of decision nodes+1V(G) = \text{Number of decision nodes} + 1V(G)=Number of decision nodes+1 

Q4 Previous Date Program

Equivalence Classes

• Valid dates                                              • Invalid dates

Boundary Value Analysis                           • Day = 1, 31
• Month = 1, 12                                         • Year = 1850, 2050

Robust Test Cases

Include invalid values (day = 0, 32)

Worst-Case Test Cases

All combinations of boundary values.

Q5 Short Notes

(i) Walkthrough

Informal review where author explains work to team.

(ii) Inspection

Formal review process with defined roles & checklists.

(iii) Configuration Audit

Ensures correct versions, changes, and documentation are maintained.