πŸŽ“ Software Engineering Final Exam Cheat Sheet

Focus on Past Finals | Tips & Tricks | Quick Reference

πŸ“‹ Software Process Models (High Frequency in Exams!)

Always appears in MCQs and scenario-matching questions!

Quick Model Selector

Model When to Use Key Characteristics Exam Keywords
Waterfall Requirements clear & fixed Sequential, no going back "well understood", "critical safety", "fixed requirements"
Incremental Need quick delivery of core Deliver in increments "quickly", "core product", "business competition"
Evolutionary/Spiral High risk, changing requirements Risk management, iterative "risk management", "gradually growing"
Prototyping Unclear requirements, UI focus Build throwaway version "unclear requirements", "user interface", "stakeholder feedback"
Unified Process Large enterprise systems Use-case driven, architecture-centric "use-case driven", "architecture-centric", "iterative and incremental"
Scenario Matching Example (From Final 2022):
Q: "A compelling need to provide limited functionality to users quickly and then refine in later releases"

Step 1: Identify keywords β†’ "quickly", "limited functionality", "refine later"
Step 2: Match to model characteristics:
  β€’ Waterfall? NO - it doesn't allow refinement
  β€’ Incremental? YES - delivers core quickly, adds features later
  β€’ Spiral? NO - focuses on risk, not speed
Step 3: Answer = Incremental Model
Multiple Choice Example:
Q: "An iterative model with emphasis on risk management that develops increasingly complete versions"

Step 1: Key phrases β†’ "iterative", "risk management", "increasingly complete"
Step 2: Eliminate options:
  a) Waterfall - NOT iterative ❌
  b) Evolutionary/Spiral - iterative + risk βœ“
  c) Incremental - iterative but no risk focus ❌
Step 3: Answer = b) Evolutionary Process Model
Real Exam Scenarios - Match the Model:

Scenario 1: "System developed at several sites"
Solution: Waterfall (clear phases for distributed teams)

Scenario 2: "Requirements are huge and unclear, needs user involvement"
Solution: Prototyping (user feedback refines unclear requirements)

Scenario 3: "Hardware delivery date uncertain"
Solution: Spiral (handles uncertainty through risk management)

Scenario 4: "Use-case driven, architecture-centric, iterative"
Solution: Unified Process (these are its defining characteristics)
Quick Decision Tree:
1. Requirements clear? β†’ YES: Waterfall | NO: Continue
2. Need quick delivery? β†’ YES: Incremental | NO: Continue
3. High risk/uncertainty? β†’ YES: Spiral | NO: Continue
4. UI/User feedback critical? β†’ YES: Prototyping

πŸƒ Agile, Scrum & XP (Guaranteed Questions!)

Scrum Terminology - Must Know!

Term Definition Exam Trap
Sprint 2-4 weeks fixed iteration NEVER extended for incomplete work
Product Owner Prioritizes backlog, represents customer NOT a project manager!
Scrum Master Facilitator, removes obstacles NOT managing the team directly
Sprint Backlog Tasks for current sprint For DEVELOPERS to manage themselves
Product Backlog All pending features/requirements Prioritized by Product Owner
Daily Scrum 15-minute standup 3 questions: yesterday, today, obstacles
Development Team size: 7 people (up to 10 max) - common MCQ!

XP Practices

  • Pair Programming - Two developers, one computer
  • Test-First Development - Write tests before code
  • Continuous Integration - Frequent code integration
  • Small Releases - Frequent delivery
  • Simple Design - Avoid complexity
  • User Stories - Requirements as scenarios (TRUE in XP!)
Scrum MCQ Example (From Final 2022):
Q: "What is the MAIN purpose of a Sprint Backlog?"
a) For Developers to manage themselves during Sprint
b) For Scrum Master to manage progress
c) For Developers to manage hours spent
d) For Product Owner to understand commitments

Step 1: Recall Sprint Backlog ownership β†’ Belongs to Development Team
Step 2: Eliminate wrong roles:
  β€’ Scrum Master doesn't manage it (b) ❌
  β€’ Product Owner manages Product Backlog, not Sprint (d) ❌
Step 3: Compare remaining options:
  β€’ Hours tracking is minor detail (c) ❌
  β€’ Self-management is core Scrum principle (a) βœ“
Answer: a) For Developers to manage themselves
True/False Example:
Q: "User requirements are expressed as Scenarios in Extreme Programming"

Step 1: Recall XP terminology β†’ User Stories = Scenarios
Step 2: Verify: XP uses "User Stories" which are scenario-based requirements
Step 3: Answer = TRUE

Common Trap: Don't confuse with Use Cases (that's RUP/Unified Process)
Scrum Calculation Problem:
Q: "A team has velocity of 40 points. Sprint is 3 weeks. Product Backlog has 200 points. How many sprints to complete?"

Step 1: Identify given data
  β€’ Velocity = 40 points/sprint
  β€’ Total work = 200 points
Step 2: Calculate sprints
  β€’ Sprints needed = Total work Γ· Velocity
  β€’ Sprints = 200 Γ· 40 = 5 sprints
Step 3: Calculate time (if asked)
  β€’ Time = 5 sprints Γ— 3 weeks = 15 weeks
Answer: 5 sprints (15 weeks total)
Role Identification Example:
Q: "Who is responsible for maximizing the value of the product?"

Step 1: Review each role's responsibility:
  β€’ Scrum Master β†’ Process facilitator ❌
  β€’ Development Team β†’ Creates product ❌
  β€’ Product Owner β†’ Value maximization βœ“
Answer: Product Owner

Remember:
β€’ Product Owner = WHAT to build (value)
β€’ Dev Team = HOW to build (technical)
β€’ Scrum Master = Process guardian

πŸ“Š UML Diagrams (Drawing & Analysis Questions)

Diagram Types & When to Use

Structural Diagrams

  • Class Diagram - Shows classes & relationships
  • Components: Class name, Attributes, Operations
  • Relationships: Association, Dependency, Generalization

Behavioral Diagrams

  • Use Case - User interactions
  • Sequence - Message flow over time
  • Activity - Workflow/process
  • State - Object state changes

Class Diagram Relationships

Relationship Symbol Meaning Example
Association β€”β€” General relationship Student β€” Course
Aggregation β—‡β€”β€” Has-a (can exist separately) Team β—‡β€”β€” Employee
Composition β—†β€”β€” Part-of (cannot exist separately) House β—†β€”β€” Room
Dependency - - -> Uses temporarily Class - - -> Parameter
Generalization β€”β€”β–· Inheritance (is-a) Dog β€”β€”β–· Animal
Realization - - -β–· Interface implementation Class - - -β–· Interface

Class Diagram Visibility Modifiers

Symbol Visibility Access Level
+ Public Accessible from anywhere
- Private Only within class
# Protected Within class and subclasses
~ Package Within same package

Multiplicity Notations

Notation Meaning Example
1 Exactly one Person has 1 passport
0..1 Zero or one Person has 0..1 spouse
* Zero or more Customer places * orders
1..* One or more Course has 1..* students
n Exactly n Team has 11 players
m..n Between m and n Car has 2..5 doors
Remember: Aggregation = Empty diamond (can be Empty/separate), Composition = Filled diamond (must be together)

Sequence Diagram Components

  • Actor - Stick figure or box
  • Lifeline - Vertical dashed line
  • Activation - Rectangle on lifeline (shows active)
  • Messages - Horizontal arrows between lifelines
  • Alt/Loop blocks - For conditions and iterations
Use Case Diagram - ATM System (Common Exam):

⭐ Step 1: Identify Actors
  β€’ Customer (primary)
  β€’ Bank System (secondary)
  β€’ Admin (maintenance)

⭐ Step 2: Identify Use Cases
  β€’ Login/Authenticate
  β€’ Withdraw Cash
  β€’ Check Balance
  β€’ Transfer Money
  β€’ Print Receipt

⭐ Step 3: Identify Relationships
  β€’ Withdraw Cash Β«includesΒ» Authenticate
  β€’ Check Balance Β«includesΒ» Authenticate
  β€’ Print Receipt Β«extendsΒ» from all transactions

⭐ Step 4: Draw Diagram
    [Customer]──────(Login)
         β”‚         β†—Β«includeΒ»
         β”œβ”€β”€β”€β”€(Withdraw Cash)
         β”‚         β†˜Β«extendΒ»
         β”œβ”€β”€β”€β”€(Check Balance)──────(Print Receipt)
         β”‚         β†—Β«extendΒ»
         └────(Transfer Money)
                    β”‚
              [Bank System]
                    
Class Diagram - Library System:

⭐ Step 1: Identify Classes
  β€’ Book, Member, Librarian, Loan

⭐ Step 2: Add Attributes
    Book               Member
    ---------          ---------
    -ISBN: String      -memberID: int
    -title: String     -name: String
    -author: String    -email: String
    -available: bool   -maxBooks: int
                    
⭐ Step 3: Add Methods
    Book               Member
    ---------          ---------
    +checkOut()        +borrowBook()
    +return()          +returnBook()
    +reserve()         +payFine()
                    
⭐ Step 4: Add Relationships
  β€’ Member ──── Loan (1 to 0..*)
  β€’ Book ──── Loan (1 to 0..*)
  β€’ Librarian ──▷ Member (inheritance)
  β€’ Library ◆──── Book (composition)
Sequence Diagram - Login Process:

⭐ Step 1: Identify Objects/Actors
  β€’ User, LoginUI, AuthController, Database

⭐ Step 2: Identify Messages in Order
  1. User β†’ LoginUI: enterCredentials()
  2. LoginUI β†’ AuthController: validateLogin(user,pass)
  3. AuthController β†’ Database: checkUser(user,pass)
  4. Database β†’ AuthController: userValid
  5. AuthController β†’ LoginUI: loginSuccess
  6. LoginUI β†’ User: displayHomePage

⭐ Step 3: Draw with Proper Notation
    User        LoginUI     AuthController    Database
     |             |              |              |
     |--enter----->|              |              |
     |             |--validate--->|              |
     |             |              |--check------>|
     |             |              |<---valid-----|
     |             |<--success----|              |
     |<--display---|              |              |
                    
Activity Diagram - Order Processing:

⭐ Step 1: Identify Activities
  β€’ Receive Order, Check Stock, Process Payment
  β€’ Ship Order, Send Confirmation

⭐ Step 2: Identify Decision Points
  β€’ Stock available? (Yes/No)
  β€’ Payment successful? (Yes/No)

⭐ Step 3: Identify Parallel Activities
  β€’ Ship Order AND Send Email (concurrent)

⭐ Step 4: Draw with Symbols
         ● Start
         ↓
    [Receive Order]
         ↓
      Stock?
        β—‡
  ↙ Yes    β†˜ No
[Process Pay]  [Notify Customer]
      ↓              ↓
   Success?     β—‰ End
       β—‡
 ↙ Yes    β†˜ No
   β–¬Forkβ–¬    [Cancel]
   ↙    β†˜         ↓
[Ship] [Email]    β—‰
   β†˜    ↙
   β–¬Joinβ–¬
      ↓
      β—‰ End
                    
Diagram Drawing Order:
1. Use Case: Actors β†’ Use Cases β†’ Relationships
2. Class: Classes β†’ Attributes β†’ Methods β†’ Relationships
3. Sequence: Objects β†’ Messages (top to bottom)
4. Activity: Start β†’ Activities β†’ Decisions β†’ End

🎯 Complete UML Symbol Reference

Use Case Diagram Symbols

Use Case
Oval / Ellipse
Represents a use case - specific function/action
πŸ“ Example: "Login", "Process Payment"
🚢
Stick Figure
Represents an actor - external entity
πŸ“ Example: "Customer", "Admin", "System"
System
Rectangle / Box
System boundary - defines system scope
πŸ“ Contains all use cases
Solid Line (Association)
Communication between actor and use case
⚠️ SOLID LINE - No arrowhead
Β«includeΒ»
Β«includeΒ» Relationship
Mandatory inclusion of behavior
⚠️ DASHED LINE + OPEN ARROWHEAD
Β«extendΒ»
Β«extendΒ» Relationship
Optional behavior extension
⚠️ DASHED LINE + OPEN ARROW (to base)
Generalization (Inheritance)
Child inherits from parent
⚠️ SOLID LINE + HOLLOW TRIANGLE

Class Diagram Relationships

Association
General relationship between classes
πŸ“ Example: Student β€” Course
Aggregation (Hollow Diamond)
Weak "has-a" - parts can exist independently
⚠️ HOLLOW DIAMOND (at whole)
πŸ“ Example: Team β—‡β€” Employee
Composition (Filled Diamond)
Strong "has-a" - parts CANNOT exist alone
⚠️ FILLED DIAMOND (at whole)
πŸ“ Example: House β—†β€” Room
Dependency
Uses temporarily/weakly depends on
⚠️ DASHED LINE + OPEN ARROW
πŸ“ Example: Class uses Parameter
Generalization (Inheritance)
"is-a" relationship
⚠️ SOLID LINE + HOLLOW TRIANGLE
πŸ“ Example: Dog β€”β€”β–· Animal
Realization
Interface implementation
⚠️ DASHED LINE + HOLLOW TRIANGLE
πŸ“ Example: Class implements Interface

Activity Diagram Symbols

Initial Node
Start point - filled black circle
● Beginning of workflow
Final Node
End point - circle with dot
β—‰ Termination of workflow
Decision Node
Diamond - conditional branch
β—‡ Multiple paths based on condition
Activity
Activity/Action
Rounded rectangle
Task or operation performed
Fork/Join Bar
Thick horizontal/vertical bar
β–¬ Split/merge parallel flows
Flow Final
Circle with X
βŠ— Terminates specific flow

Sequence Diagram Symbols

Object
Object with Lifeline
Rectangle with dashed vertical line
β”Š Shows object's existence over time
Activation Box
Rectangle on lifeline
β–ˆ Shows when object is active
Synchronous Message
Solid line with filled arrowhead
β†’ Waits for response
Asynchronous Message
Solid line with open arrowhead
⟢ Doesn't wait for response
Return Message
Dashed line with open arrow
⟡ Response to a call
alt
Alt/Loop Frame
Rectangle with label
For conditions and iterations

State Diagram Symbols

Initial State
Filled black circle
● Start of state machine
Final State
Circle with dot inside
β—‰ End of state machine
State
State
Rounded rectangle
Object's condition at a point in time
event
Transition
Arrow with event label
β†’ State change trigger
Self Transition
Loop back to same state
↻ State remains but event processed
Composite substates
Composite State
State containing sub-states
Hierarchical state decomposition
🎯 Quick Memory Tricks:
β€’ Hollow = Can be separate (Aggregation, Open arrows)
β€’ Filled = Must be together (Composition, Closed arrows)
β€’ Dashed = Weak/temporary (Dependency, Include/Extend)
β€’ Solid = Strong/permanent (Association, Generalization)
Memory trick for relationships: Empty Diamond = Apart OK (Aggregation), Filled Diamond = Forever together (Composition)

πŸ“ˆ Project Management - Critical Path (Always in Finals!)

Critical Path Method (CPM) appears in EVERY final - expect 8-10 marks!

Step-by-Step Critical Path Solution

  1. Draw Network Diagram - Boxes connected with arrows based on prerequisites
  2. Forward Pass - Calculate ES and EF
    ES = Maximum EF of all predecessors
    EF = ES + Duration
  3. Backward Pass - Calculate LS and LF
    LF = Minimum LS of all successors
    LS = LF - Duration
  4. Calculate Slack
    Total Slack = LS - ES = LF - EF
    Free Slack = ES(successor) - EF(current)
  5. Identify Critical Path - Path where all tasks have Total Slack = 0
Tasks on critical path: EF = LF (Early Finish equals Late Finish)
Complete Critical Path Example (From Final 2022):
Given WBS: A(15 days), B(9 days), C(12, needs A), D(10, needs B), E(29, needs B)

⭐ Step 1: Draw Network Diagram
  β€’ Start with tasks with no prerequisites (A, B)
  β€’ Add dependent tasks based on prerequisites
  β€’ Connect with arrows showing dependencies
                    START β†’ A(15) β†’ C(12) β†’ END
                         β†˜
                           B(9) β†’ D(10) β†’ END
                                β†˜
                                  E(29) β†’ END
                    
⭐ Step 2: Forward Pass (Calculate ES and EF)
  β€’ ES of first tasks = 0
  β€’ EF = ES + Duration
  β€’ ES of next task = Maximum EF of all predecessors

TaskCalculationESEF
AStart task00+15=15
BStart task00+9=9
CAfter A1515+12=27
DAfter B99+10=19
EAfter B99+29=38
⭐ Step 3: Project Duration
  β€’ Maximum EF = max(27, 19, 38) = 38 days

⭐ Step 4: Backward Pass (Calculate LS and LF)
  β€’ LF of last tasks = Project Duration = 38
  β€’ LS = LF - Duration
  β€’ LF of previous = Minimum LS of successors

TaskCalculationLSLF
CLF=3838-12=2638
DLF=3838-10=2838
ELF=3838-29=938
ALF=min(LS of C)=2626-15=1126
BLF=min(LS of D,E)=99-9=09
⭐ Step 5: Calculate Slack
  β€’ Total Slack = LS - ES = LF - EF

TaskESLSSlackCritical?
A01111NO
B000YES
C152611NO
D92819NO
E990YES
⭐ Step 6: Identify Critical Path
  β€’ Tasks with slack = 0: B, E
  β€’ Critical Path: B β†’ E (38 days)
Delay Impact Calculation:
Q: "If Task E delayed by 5 days, when will project complete?"

Step 1: Check if task is critical
  β€’ E has slack = 0 β†’ It's critical
Step 2: Calculate impact
  β€’ Critical task delay = Project delay
  β€’ New duration = 38 + 5 = 43 days
Answer: 43 days

Q: "If Task D delayed by 9 days?"

Step 1: Check slack
  β€’ D has slack = 19 days
Step 2: Compare delay vs slack
  β€’ Delay (9) < Slack (19)
  β€’ No impact on project
Answer: No effect, still 38 days
CPM Quick Checks:
β€’ Critical task: ES = LS and EF = LF
β€’ Delay formula: If delay > slack, project delays by (delay - slack)
β€’ Free Slack = ES(next) - EF(current) - only affects immediate successor

Network Diagram Box Format

                    β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
                    β”‚  ES | Task | EF  β”‚
                    β”‚  LS | Dura.| LF  β”‚
                    β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                    

πŸ”§ Requirements Engineering

Functional vs Non-Functional Requirements

Functional Requirements

  • WHAT system should do
  • Specific functions/features
  • Example: "System shall send email"
  • Keywords: "shall", "must", "will"

Non-Functional Requirements

  • HOW system should perform
  • Quality attributes
  • Example: "Response time < 2 seconds"
  • Types: Performance, Security, Usability
Functional vs Non-Functional Example (From Finals):
Q: "Heat sensor detects intrusion and alerts security company"

Step 1: Identify the key action
  β€’ "detects" and "alerts" are ACTIONS/VERBS
Step 2: Apply the rule
  β€’ Actions/What system does = Functional
  β€’ Quality/How well = Non-functional
Step 3: Verify
  β€’ This describes WHAT the system does
Answer: a) Functional Requirement
More Classification Examples:

Example 1: "System shall process 1000 transactions per second"
  Step 1: Look for quality metric β†’ "1000 per second"
  Step 2: This is HOW FAST, not WHAT
  Answer: Non-Functional (Performance)

Example 2: "System shall encrypt all stored passwords"
  Step 1: Action word β†’ "encrypt"
  Step 2: Describes WHAT system does
  Answer: Functional

Example 3: "Response time shall be less than 2 seconds"
  Step 1: Quality constraint β†’ "less than 2 seconds"
  Step 2: Describes HOW WELL
  Answer: Non-Functional (Performance)

Example 4: "System shall be available 99.9% of the time"
  Step 1: Percentage metric β†’ "99.9%"
  Step 2: Quality attribute
  Answer: Non-Functional (Reliability)
Risk Classification Example:
Q: "Requirements change is what type of risk?"

Step 1: Analyze impact areas
  β€’ Changes affect schedule β†’ Project Risk βœ“
  β€’ Changes affect quality β†’ Product Risk βœ“
  β€’ Changes affect organization β†’ Maybe not directly
Step 2: Check given options
  a) Project risk βœ“
  b) Product risk βœ“
  c) Organizational risk ❌
  d) a and b βœ“
Answer: d) Both Project and Product Risk
Risk Management Strategy Example:
Q: "Risk avoidance refers to?"

Step 1: Recall risk strategies:
  β€’ Avoidance = Reduce probability
  β€’ Mitigation = Reduce impact
  β€’ Contingency = Plan B if it happens
  β€’ Acceptance = Take the risk
Step 2: Match definition
  "Reducing probability" = Avoidance
Answer: a) Reducing the probability that risk will arise
Quick Test for Requirements:
β€’ Can you test it with YES/NO? β†’ Functional
β€’ Need to measure HOW MUCH/FAST/WELL? β†’ Non-functional
β€’ Has a number/metric? β†’ Usually Non-functional

Requirements Elicitation Problems (Common MCQ)

  • Stakeholders don't know what they want
  • Stakeholders use their own terms (domain language)
  • Conflicting requirements from different stakeholders
  • Political/organizational factors influence requirements

Risk Categories

Risk Type Examples Exam Tip
Project Risk Schedule, budget, resources Affects project timeline
Product Risk Quality, performance issues Affects product quality
Business Risk Market changes, competition Affects product viability
"Requirements change" is BOTH Project Risk AND Product Risk!

πŸ—οΈ Software Architecture Patterns

Architecture Pattern Selector

Pattern Use Case Key Feature Exam Keyword
Layered Enterprise applications Separation of concerns "layers", "n-tier"
Client-Server Distributed systems Request-response model "thin/fat client"
Pipe & Filter Data transformations Sequential processing "batch", "sequential transformations"
Repository Data-centric systems Centralized data store "shared data", "central database"
MVC Web applications Separation of UI/logic/data "model-view-controller"
Architecture Selection Example (From Final 2021):
Q: "System accepts batch of data and applies series of sequential transformations"

Step 1: Identify key requirements
  β€’ "batch of data" β†’ Processing chunks
  β€’ "sequential transformations" β†’ Step-by-step processing
Step 2: Match to patterns
  a) Pipe & Filter β†’ Sequential data flow βœ“
  b) Repository β†’ Central data store ❌
  c) Client-Server β†’ Request-response ❌
  d) Layered β†’ Hierarchical organization ❌
Step 3: Verify match
  β€’ Pipe & Filter: data β†’ filter1 β†’ filter2 β†’ output
Answer: a) Pipe & Filter Architecture
Architecture Scenario Matching:

Scenario 1: "Multiple users accessing shared patient records"
  Step 1: Key = "shared" data
  Step 2: Central storage needed
  Answer: Repository Architecture

Scenario 2: "Web app with separate UI, business logic, and database"
  Step 1: Three distinct layers mentioned
  Step 2: Each has specific responsibility
  Answer: Layered/3-Tier Architecture

Scenario 3: "Compiler processing source code"
  Step 1: Sequential: lexical β†’ syntax β†’ semantic β†’ code gen
  Step 2: Each stage transforms data
  Answer: Pipe & Filter

Scenario 4: "Web application needing different views of same data"
  Step 1: Multiple views of same data
  Step 2: Separation of concerns needed
  Answer: MVC Pattern
MVC Component Identification:
Q: "In online banking, where does password validation logic belong?"

Step 1: Understand MVC roles
  β€’ Model = Business logic & data
  β€’ View = Presentation/UI
  β€’ Controller = User input handling
Step 2: Classify "validation logic"
  β€’ It's business rule/logic
  β€’ Not UI, not input handling
Answer: Model

Q: "Where does the login button belong?"
  Answer: View (UI element)

Q: "Where does click event handling go?"
  Answer: Controller (handles user interaction)
Architecture Quick Match:
β€’ "Sequential/Transform" β†’ Pipe & Filter
β€’ "Shared data" β†’ Repository
β€’ "Layers/Tiers" β†’ Layered
β€’ "Request-Response" β†’ Client-Server
β€’ "Different views" β†’ MVC

MVC Components

  • Model - Data and business logic
  • View - Presentation/UI
  • Controller - Handles user input, updates model/view

πŸ§ͺ Software Testing (Essential for Finals!)

Testing Levels (Always asked!)

  1. Unit Testing - Individual components
  2. Integration Testing - Component interfaces
  3. System Testing - Complete system
  4. Acceptance Testing - Customer validation
Regression Testing = Re-testing after changes (maintenance phase)

Black Box vs White Box Testing

Black Box Testing

  • No code knowledge needed
  • Tests functionality
  • Based on requirements
  • Equivalence partitioning
  • Boundary value analysis

White Box Testing

  • Code knowledge required
  • Tests internal structure
  • Path coverage
  • Statement coverage
  • Branch coverage
  • Basis Path Testing

πŸ” Basis Path Testing (White Box Technique)

Steps for Basis Path Testing:

  1. Draw Control Flow Graph (CFG)
    • Nodes (circles) = Sequential statements
    • Diamonds = Decision points (if/while conditions)
    • Edges = Flow between nodes
    • Label nodes: 1, 2, 3...
  2. Calculate Cyclomatic Complexity
    V(G) = E - N + 2
    Where: E = Edges, N = Nodes
    OR
    V(G) = P + 1
    Where: P = Predicate nodes (conditions)
  3. Determine Independent Paths
    • Number of paths = Cyclomatic Complexity
    • Each path must introduce at least one new edge
  4. Design Test Cases
    • One test case for each independent path
    • Ensure all statements executed at least once
Complete Worked Example (From your image):
Code: min = A[0]; I = 1; while (I < N) { if (A[I] < min) min = A[I]; I++; }

⭐ Step 1: Create Control Flow Graph
        Node 1: min = A[0]; I = 1;
                ↓
        Node 2: while (I < N) [Decision]
               ↙ True    β†˜ False
        Node 3: if(A[I] < min)    Node 6: print min
               ↙ True    β†˜ False
        Node 4: min=A[I]  Node 5: (skip)
                β†˜        ↙
                 Node 5: I++
                    ↑_______|
        
⭐ Step 2: Count Nodes and Edges
  β€’ Nodes: 1, 2, 3, 4, 5, 6 = 6 nodes
  β€’ Edges: Count all arrows
    - 1β†’2, 2β†’3, 2β†’6 (while exits)
    - 3β†’4, 3β†’5, 4β†’5, 5β†’2 (loop back)
  β€’ Total = 7 edges

⭐ Step 3: Calculate Cyclomatic Complexity
  Method 1: V(G) = E - N + 2
    V(G) = 7 - 6 + 2 = 3
  Method 2: V(G) = P + 1
    Predicates: while (node 2), if (node 3) = 2
    V(G) = 2 + 1 = 3

⭐ Step 4: Identify 3 Independent Paths
  Path 1: 1 β†’ 2 β†’ 6 (Empty array, N=0)
  Path 2: 1 β†’ 2 β†’ 3 β†’ 5 β†’ 2 β†’ 6 (No min update)
  Path 3: 1 β†’ 2 β†’ 3 β†’ 4 β†’ 5 β†’ 2 β†’ 6 (Min updated)

⭐ Step 5: Design Test Cases
PathTest DataExpected Output
1A=[], N=0Error or undefined
2A=[5,10], N=2min=5
3A=[10,5], N=2min=5
Another Example - With Nested Conditions:
Code: if (x > 0) { if (y > 0) z = 1; else z = 2; } else z = 3;

Step 1: Draw CFG
  β€’ Node 1: Start
  β€’ Node 2: if (x > 0)
  β€’ Node 3: if (y > 0)
  β€’ Node 4: z = 1
  β€’ Node 5: z = 2
  β€’ Node 6: z = 3
  β€’ Node 7: End

Step 2: Count
  β€’ Nodes = 7, Edges = 8
  β€’ V(G) = 8 - 7 + 2 = 3

Step 3: Three paths needed
  β€’ Path 1: 1β†’2β†’6β†’7 (x ≀ 0)
  β€’ Path 2: 1β†’2β†’3β†’4β†’7 (x > 0, y > 0)
  β€’ Path 3: 1β†’2β†’3β†’5β†’7 (x > 0, y ≀ 0)

Step 4: Test cases
  β€’ Test 1: x=0, y=0 β†’ z=3
  β€’ Test 2: x=1, y=1 β†’ z=1
  β€’ Test 3: x=1, y=0 β†’ z=2
CFG Symbols: β—‹ = Statement node, β—‡ = Decision node, β†’ = Control flow
Quick Check: If code has 2 if-statements, you need at least 3 test cases (2+1)

Integration Testing Strategies

  • Bottom-up - Test low-level modules first
  • Top-down - Test high-level modules first
  • Big-bang - Test all together (risky!)
  • Sandwich - Combination of top-down and bottom-up
Testing Level Identification (Common MCQ):
Q: "Testing after maintenance phase with previous test cases is?"

Step 1: Keywords = "maintenance", "previous test cases"
Step 2: Recall testing types for changes:
  β€’ Unit Testing = Individual components ❌
  β€’ Integration = Component interfaces ❌
  β€’ System = Complete system ❌
  β€’ Regression = Re-test after changes βœ“
Answer: d) Regression Testing
Black Box Testing - Equivalence Partitioning:
Q: "Test a field that accepts age 18-65"

⭐ Step 1: Identify partitions
  β€’ Invalid: age < 18
  β€’ Valid: 18 ≀ age ≀ 65
  β€’ Invalid: age > 65

⭐ Step 2: Select test values (one from each)
  β€’ Partition 1: age = 10 (< 18)
  β€’ Partition 2: age = 40 (valid)
  β€’ Partition 3: age = 70 (> 65)

⭐ Step 3: Add boundary values
  β€’ Lower boundary: 17, 18, 19
  β€’ Upper boundary: 64, 65, 66

Final Test Cases:
  10 (invalid low), 17, 18, 19, 40 (valid middle), 64, 65, 66, 70 (invalid high)
Integration Testing Strategy Selection:
Q: "You have Login β†’ Database β†’ Payment modules. Which integration approach?"

Bottom-Up Approach:
  Step 1: Test Database (lowest level)
  Step 2: Test Database + Payment
  Step 3: Test Login + Database
  Step 4: Test all together
  Pros: No stubs needed / Cons: UI tested last

Top-Down Approach:
  Step 1: Test Login (with stubs for others)
  Step 2: Test Login + Database (stub Payment)
  Step 3: Test all together
  Pros: UI tested first / Cons: Many stubs needed

Best Choice: Bottom-up (critical payment logic tested early)
Test Case Design Problem:
Q: "Design test cases for: if (x > 10 && y < 5) output = 'A' else output = 'B'"

⭐ Step 1: Identify decision conditions
  β€’ Condition 1: x > 10
  β€’ Condition 2: y < 5
  β€’ Combined: BOTH must be true for 'A'

⭐ Step 2: Create decision table
Testx > 10y < 5Expected
1T (x=15)T (y=3)'A'
2T (x=15)F (y=7)'B'
3F (x=5)T (y=3)'B'
4F (x=5)F (y=7)'B'
⭐ Step 3: Add boundary cases
  β€’ Test 5: x=10, y=3 β†’ 'B' (boundary)
  β€’ Test 6: x=11, y=5 β†’ 'B' (boundary)
  β€’ Test 7: x=11, y=4 β†’ 'A' (just inside)
Testing Quick Rules:
β€’ Number of test cases = 2^n (n = conditions) for complete coverage
β€’ Always test: Valid, Invalid, Boundary, Null/Empty
β€’ Integration order: Critical β†’ Supporting β†’ UI

πŸ’Ž Software Design Concepts

Cohesion vs Coupling

Cohesion (WANT HIGH!)

  • Intra-module strength
  • How related elements are within module
  • High cohesion = Good design
  • Single, well-defined purpose

Coupling (WANT LOW!)

  • Inter-module dependency
  • How modules depend on each other
  • Low coupling = Good design
  • Independent modules
Mnemonic: "High Cohesion, Low Coupling" = HCLC = Healthy Code, Long-lasting Code

Design Quality Attributes

  • Correctness - No bugs inhibiting function
  • Commodity/Suitability - Suitable for intended purpose
  • Usability - Pleasant user experience
  • Consistency - No contradictions or omissions
Cohesion vs Coupling MCQ (From Finals):
Q: "Which defines the degree of intra-dependability within elements of a module?"

Step 1: Parse the question
  β€’ "intra" = within/inside
  β€’ "within elements of a module" = inside one module
Step 2: Recall definitions
  β€’ Cohesion = INTRA-module (within) βœ“
  β€’ Coupling = INTER-module (between) ❌
Answer: a) Cohesion
Design Quality Example:
Q: "Good design where program is suitable for intended purpose is?"

Step 1: Match description to attributes
  β€’ Correctness = No bugs ❌
  β€’ Commodity/Suitability = Suitable for purpose βœ“
  β€’ Usability = Pleasant experience ❌
  β€’ Consistency = No contradictions ❌
Answer: b) Commodity
Cohesion Analysis - Practical Example:
Evaluate this class for cohesion:
class UserManager {
    validateEmail()
    calculateTax()      // ???
    saveUser()
    sendEmail()
    generateReport()    // ???
}
                    
Step 1: Check if all methods relate to single purpose
  β€’ validateEmail βœ“ (user-related)
  β€’ calculateTax ❌ (not user management)
  β€’ saveUser βœ“ (user-related)
  β€’ sendEmail βœ“ (user communication)
  β€’ generateReport ❌ (could be any report)
Step 2: Evaluate cohesion level
  β€’ Mixed responsibilities = LOW cohesion (BAD)
Step 3: Improve by splitting:
  β€’ UserManager: validateEmail, saveUser, sendEmail
  β€’ TaxCalculator: calculateTax
  β€’ ReportGenerator: generateReport
  Result: HIGH cohesion (GOOD)
Coupling Analysis - Practical Example:
// HIGH Coupling (BAD)
class Order {
    Database db = new Database();
    EmailService email = new EmailService();
    PaymentGateway payment = new PaymentGateway();
    
    processOrder() {
        db.connect();
        payment.charge();
        email.send();
    }
}

// LOW Coupling (GOOD)
class Order {
    processOrder(IDatabase db, IEmail email, IPayment payment) {
        db.save(this);
        payment.charge(amount);
        email.notify(customer);
    }
}
                    
Analysis:
  Version 1: Creates its own dependencies = TIGHT coupling
  Version 2: Dependencies injected = LOOSE coupling
  Better: Version 2 (can test, change implementations easily)
SOLID Principles Quick Check:
Q: "A class should have only one reason to change" - Which principle?

Step 1: Match to SOLID
  β€’ S = Single Responsibility βœ“
  β€’ O = Open/Closed
  β€’ L = Liskov Substitution
  β€’ I = Interface Segregation
  β€’ D = Dependency Inversion
Answer: Single Responsibility Principle
Remember the Goal:
β€’ HIGH Cohesion = Related things together (GOOD)
β€’ LOW Coupling = Independent modules (GOOD)
β€’ Mnemonic: "HC-LC" = Healthy Code - Lasting Code

⚑ Quick Exam Reference

Common Traps to Avoid

  • ❌ Waterfall is NOT suitable for accommodating changes
  • ❌ Scrum Master is NOT a project manager
  • ❌ Sprint Backlog is NOT for Product Owner to manage
  • ❌ Requirements change affects BOTH project and product risk
  • ❌ Sprints are NEVER extended for incomplete work

Must-Remember Numbers

  • Scrum team size: 7 (max 10)
  • Sprint duration: 2-4 weeks
  • Daily Scrum: 15 minutes
  • CMM Levels: 1-5 (Initial to Optimizing)

Acronyms to Know

CMM Capability Maturity Model Process improvement
XP Extreme Programming Agile methodology
MVC Model-View-Controller Architecture pattern
WBS Work Breakdown Structure Project tasks
CPM Critical Path Method Project scheduling

Last-Minute Checklist

  • βœ… Know all Scrum roles and artifacts
  • βœ… Can calculate critical path (ES, EF, LS, LF, Slack)
  • βœ… Know when to use each process model
  • βœ… Can distinguish functional vs non-functional requirements
  • βœ… Know testing levels order
  • βœ… Remember cohesion (high) vs coupling (low)
  • βœ… Can identify architecture patterns from descriptions