SOFTWARE TESTING &

PROJECT MANAGEMENT
Concept-First Study Guide — Scenario-Based Exam Ready

Lectures 25, 26 & 29–30 | CSC291 Software Engineering

■ SECTION 1: What is Software Testing?

Core Definition
• Testing = running a program with data to check it does what it should, and find bugs before users do.
• Testing cannot prove correctness — it can only reveal the presence of bugs, not their absence.
• Goal: build confidence that software meets requirements.

■ The Key Idea for Scenarios

If asked "what is the purpose of testing?" — answer: to find defects early and verify the software meets
requirements. NOT to prove it is perfect.

Who Does Testing?

Roles Involved Their Focus

• Software Tester • Finding bugs, writing test cases

• Software Developer • Testing own code (unit tests)

• Project Manager / Leader • Overseeing quality

• End User • Real-world usability

3 Stages of Testing [Must Know]

Development Testing
1
Done DURING development by developers. Finds bugs early. Includes unit & integration tests.

Release Testing
2
Done by a SEPARATE testing team on the complete product before releasing. Validates all requirements.

User Testing
3
Done by real users in their own environment. Includes alpha, beta, and acceptance testing.

■ Scenario Tip

"A dedicated QA team tests the product before launch" → Release Testing. "Developers test individual
functions" → Development Testing. "Customers test in their own office" → User Testing.

Manual vs Automation Testing

Manual Testing ■ Automation Testing ■

 • Done by humans, no automation tools • Uses software to test software

• Slower but flexible • Faster for repetitive tests

• Good for exploratory testing • Code auditing, load tests

• Stages: Unit, Integration, System, UAT • Coverage monitoring

Regression Testing [Important]

• When you fix a bug or add a new feature, regression testing re-runs existing tests to make sure the change didn't
break something else.

■ Scenario Tip

A developer fixes a login bug. The QA team then retests the entire app to ensure nothing else broke. →
Regression Testing.
 ■ SECTION 2: Black Box vs White Box Testing

■ The Core Difference — Remember This

Black Box = Test the BEHAVIOR (you don't see the code). White Box = Test the INTERNALS (you read
the code).

Black Box Testing ■

• Tester gives inputs and checks outputs — without knowing how code works internally.
• Also called: Closed Box, Data-Driven, Functional Testing.

Advantages ■ Disadvantages ■

• No code knowledge needed • Limited knowledge → blind spots

• Suitable for large systems • Can't target error-prone code

• Tests from user's perspective • Test cases hard to design

• Many testers can contribute easily

■ Scenario Tip

A bank hires an external firm to test its app. Testers enter amounts and check results — no access to source
code. → Black Box Testing.

White Box Testing ■

• Tester examines the source code directly and designs tests based on internal logic.
• Also called: Glass Box, Clear Box, Structural, Code-Based Testing.

Advantages ■ Disadvantages ■

• Maximum code coverage • Requires skilled testers (costly)

• Dead/redundant code found • Time-consuming and exhaustive

• Better test data selection • Needs debuggers & analyzers

■ Scenario Tip

A developer reads her own login function code and writes tests for every if-else branch. → White Box Testing.

Quick Comparison Table

Aspect Black Box ■ White Box ■

Code Access Not required Full access needed

Who does it End users, testers Developers, testers

Algorithm testing Not suited Ideal

Time Less time consuming Most exhaustive & time consuming

Perspective External / user view Internal / code view

 ■ SECTION 3: Testing Strategies

Unit Testing
• Tests INDIVIDUAL functions/modules in isolation. Done by the developer who wrote that code.
• Goal: show each piece works correctly on its own.

■ Example

Testing a calculateTax() function with different income values — is each result correct? → Unit Test.

Integration Testing
• Tests COMBINED modules working together. Finds interface bugs — problems that appear only when modules
talk to each other.

■ Example

After login and dashboard modules are tested separately, you test them TOGETHER — does login correctly
redirect to dashboard? → Integration Test.

System Testing
• Tests the COMPLETE, fully integrated application as a whole. Done by a specialized testing team.
• Checks the entire system meets quality standards.

Big Bang vs Incremental Testing [Key Concept]

Big Bang ■ Incremental ■ (Preferred)

• Test ALL modules together at once • Test module by module as built

• Wait until entire system is complete • Unit → Integration → System

• Harder to isolate bugs • Easier to find & fix bugs

• Risky — bugs found late • Lower risk, preferred approach

Top-Down vs Bottom-Up [Scenario Favourite]

Top-Down ■■ Bottom-Up ■■

• Start from the MAIN/TOP module • Start from LOWEST modules

• Work down to sub-modules • Work up to the main module

• Needs STUBS for lower modules • Needs DRIVERS for upper modules

• Good for early interface testing • Good for reusable components

■ Scenario Tip

"Testing starts from module 11 (highest) and gradually tests lower modules" → Top-Down. "Testing starts
from modules 1-7 (lowest) and builds up to main module" → Bottom-Up.

■ Easy Memory Trick

Top-Down = CEO first (start at top, use STUB substitutes for employees not yet hired). Bottom-Up =
Workers first (start at ground level, use DRIVER boss substitutes).
 ■ SECTION 4: Stubs & Drivers

Why Do We Need Them?

• When doing incremental integration testing, some modules are not yet coded.
• Stubs and Drivers are DUMMY/FAKE replacements so testing can continue without waiting for all modules.

STUB [Used in Top-Down Testing]

• A stub replaces a LOWER-LEVEL module that hasn't been built yet.
• It's a dummy that returns fake data when the upper module calls it.
• Rule: Upper module is ready → lower ones not ready → use STUBS for lower.

■ Rule

Stubs are used in TOP-DOWN testing. The upper module is ready, lower ones are not → use stubs for
lower.

■ Real Example (from slides)

Login module is ready and tested. It calls Home and User modules — but those aren't coded yet. We write
STUB code that pretends to be Home/User and returns fake values, so Login can be tested now.

DRIVER [Used in Bottom-Up Testing]

• A driver replaces an UPPER-LEVEL module that hasn't been built yet.
• It CALLS the lower module and collects its output for testing.
• Rule: Lower modules are ready → upper ones not ready → use DRIVERS.

■ Rule

Drivers are used in BOTTOM-UP testing. Lower modules are ready, upper ones are not → use a driver
to call them.

■ Real Example (from slides)

Home and User modules are ready but Login isn't coded yet. We write a DRIVER that pretends to be Login
and calls Home/User to test their outputs.

■ STUB ■ DRIVER

Replaces LOWER module Used in TOP-DOWN It is Replaces UPPER module Used in BOTTOM-UP It
"called" by upper module "calls" the lower module
 ■ SECTION 5: How to Write Test Cases

What is a Test Case?

• A documented set of conditions and steps used to verify a specific feature behaves as expected.
• Produces a PASS ■ or FAIL ■ result.

The 8 Steps of a Test Case [Must Know for Exam]

Test Case ID
1
A unique identifier (e.g., TC_001). Used to track and reference the test.

Test Description
2
What feature/unit is being tested? E.g., "Testing user login with valid credentials."

Assumptions & Pre-Conditions

3
What must be true BEFORE the test runs? E.g., "A valid user account must exist."

Test Data
4
The actual input values. E.g., Username: john@[Link], Password: Pass123

Steps to Execute
5
Step-by-step actions: (1) Open login page → (2) Enter email → (3) Enter password → (4) Click Login

Expected Result
6
What SHOULD happen if software works correctly? E.g., "User is redirected to dashboard."

Actual Result & Post-Conditions

7
What actually happened? Post-condition = state after test (e.g., user is now logged in).

Pass / Fail
8
If Actual Result = Expected Result → PASS. Otherwise → FAIL.

■ How to Answer Scenario Questions

If asked to "write a test case for a registration form", fill all 8 fields with sensible values. Examiners look for:
Pre-conditions, Input data, Clear steps, Expected result, Pass/Fail logic.

Types of Test Cases (Quick Reference)

Functionality Tests Does each feature work as specified?

UI Tests Does the interface look and behave correctly?

Performance Tests Does it meet speed/load requirements?

Integration Tests Do combined modules work together?

Usability Tests Is it easy to use for the end user?

Negative Tests What happens with WRONG/invalid input? (Always include!)

 ■ SECTION 6: User Testing (Alpha, Beta, Acceptance)

3 Types of User Testing [Common in Scenarios]

Alpha Testing
α
Users test at the DEVELOPER'S SITE, working alongside the dev team. Very early, controlled. Bugs expected.

Beta Testing
β
A release is sent to REAL USERS in their own environment. They use it freely and report bugs. Dev team is NOT
present.

Acceptance Testing (UAT)

✓
The CUSTOMER formally decides whether to accept the system. Final gate before deployment. Must meet their
requirements.

■ Scenario Tips

"A client checks the delivered software and signs off on it" → Acceptance Testing. "1000 users download a
pre-release app and send feedback" → Beta Testing. "Developers and select users test together at the office"
→ Alpha Testing.

■ Remember the Order

Alpha (internal / dev site) → Beta (public / user's site) → Acceptance (client approval) → Product Released!
MNEMONIC: A → B → Accept → Deploy
 ■■ SECTION 7: Software Project Management (SPM)

Why Software Projects Fail?

• Unclear or misunderstood requirements
• Unrealistic deadlines
• Poor change management
• Key personnel leaving mid-project
• New/unfamiliar technology introduced
• Scope poorly defined
• Business needs changing
• User resistance to the product
• Team lacks appropriate skills

The 4 P's of Management [Must Know]

The most important element. Without the right people, no process or tool can save a
■ People project.

■ Product The software being built. Must have a clearly defined, unambiguous scope.

■■ Process The framework of activities — requirements, design, coding, testing, maintenance.

■ Project All the work to make the product real — planning, scheduling, tracking progress.

■ Mnemonic

4 P's: People · Product · Process · Project (People is MOST important!)

5 Process Groups of Project Management

Initiation
1
Define the project, get approval to start. Identify stakeholders.

Planning
2
Define scope, schedule, resources, risks. The most detailed phase.

Execution
3
Actually doing the work — coding, designing, building.

Monitoring & Control

4
Track progress, compare to plan, take corrective actions when needed.

Closure
5
Formally end the project, document lessons learned (postmortem).

Product Scope — 3 Key Questions

• Context — How does this software fit in the bigger system? What constraints exist?
• Information Objectives — What data goes IN? What data comes OUT?
• Function & Performance — What does it do? Any speed/load requirements?

■ Key Rule
Scope must be UNAMBIGUOUS at both management AND technical level. Vague scope = project
failure.
 ■ SECTION 8: Teams, Stakeholders & Leadership

Stakeholders
• Senior Managers — Define business issues, have significant influence on the project.
• Project Managers — Plan, motivate, organize, and control the team.
• Practitioners — Developers, testers — deliver the actual technical skills.
• Customers — Specify the requirements for the software.
• End Users — Interact with the software after it is deployed.

The MOI Model (Team Leader) [Scenario Favourite]

Motivation
M
Ability to push or pull team members to produce their best work.

Organization
O
Ability to shape or invent processes that turn the initial concept into a finished product.

Ideas / Innovation
I
Encouraging creativity even within the constraints of the project.

■ Scenario Tip

"A PM holds weekly creative brainstorms and reorganizes tasks when blocked" → demonstrates MOI (all
three).

4 Organizational Paradigms (Team Structures)

• Closed — Traditional hierarchy, authority-based. Structured top-down management.
• Random — Loose structure, depends on individual initiative. Creative but unpredictable.
• Open — Balance of control + innovation. Best of closed + random. Preferred for most projects.
• Synchronous — Problem split into pieces; team members work independently with little communication.

Team Toxicity — Signs to Identify in Scenarios ■■

• Frenzied atmosphere with no clear focus on objectives
• High frustration and friction between team members
• Fragmented or poorly defined processes acting as roadblocks
• Unclear roles → no accountability → finger-pointing
• Repeated exposure to failure → low morale and confidence

■ Scenario Tip

If a scenario describes a team where "nobody knows their role" and "deadlines keep failing" → identify as
Team Toxicity issues.

Agile Teams
• Self-organizing — the team manages itself
• Trust-based — team members must trust one another
• Adaptive structure — changes with the project needs
• Significant autonomy given to the team
• Uses elements of Open, Random, and Synchronous paradigms
• Mavericks who disrupt cohesion may be excluded from team
 ■ SECTION 9: Quick Revision Summary

■ Testing Basics ■■ Box Testing

• Testing finds bugs — doesn't prove correctness • Black Box = No code access, tests behavior

• 3 Stages: Development → Release → User • White Box = Has code access, tests internals

• Manual (humans) vs Automated (tools) • Black Box → functional, user perspective

• Regression = re-test after any change • White Box → structural, algorithm testing

■ Strategies ■ Stubs & Drivers

• Unit → Integration → System (incremental) • Stub = fake lower module (Top-Down)

• Top-Down: main module first, uses Stubs • Driver = fake upper module (Bottom-Up)

• Bottom-Up: lowest modules first, uses Drivers • Both are dummy replacements for missing code

• Big Bang: test all at once (risky) • Stub is CALLED; Driver CALLS

■ Test Case 8 Steps ■ User Testing

• ID → Description → Pre-conditions • Alpha = dev site + selected users

• Test Data → Steps → Expected Result • Beta = user's environment, public release

• Actual Result + Post-conditions • Acceptance = client formally approves

• Pass/Fail determination • Order: Alpha → Beta → Acceptance

■■ SPM Basics ■ Team Management

• 4 P's: People, Product, Process, Project • MOI Model: Motivation, Organization, Ideas

• 5 Phases: Initiate→Plan→Execute→Monitor→Close • 4 Paradigms: Closed/Random/Open/Synchronous

• Scope must be clear and unambiguous • Agile = self-organizing, adaptive, autonomous

• Decompose problem into smaller parts • Avoid team toxicity (unclear roles, failure cycles)

Most Likely Scenario-Based Exam Questions

1. "Identify which type of testing is described" → Use clues: code access? who's testing? which module level?

2. "Write a test case for X feature" → Use all 8 steps with sensible values for your feature.

3. "A bug was fixed, now what?" → Regression Testing (re-run all tests to ensure nothing broke).

4. "Main module is ready, sub-modules not coded" → Top-Down Integration + Stubs.

5. "Team has unclear roles and low morale" → Identify as Team Toxicity signs.

6. "Project is struggling, what went wrong?" → Refer to the 4 P's and common failure reasons.

7. "Classify testing approach: user tests at developer office" → Alpha Testing.

8. "Module A calls Module B, but B is not ready" → Use a Stub for Module B.

Good luck on your exam! ■ You've got this!