Unit 1 of 4 · B.Sc IT Sem 6

Unit 1: Testing principles and test management

Software Testing and Quality Assurance notes · PTU syllabus (BSIT602)

3 min read10 topics10 exam questions
On this page
  1. Unit summary
  2. Errors, faults, defects and failures
  3. Levels of testing
  4. Integration testing approaches
  5. System, regression, alpha, beta and acceptance testing
  6. The software testing life cycle
  7. Test planning
  8. Black-box test design strategies
  9. Equivalence partitioning, boundary value analysis and other techniques
  10. White-box test adequacy criteria
  11. Defect tracking and analysis
  12. Key terms
  13. Quick revision
  14. Important questions

Unit summary

Testing finds defects before customers do, and test management keeps that effort organised. This unit covers errors, faults, defects and failures, the levels and types of testing, white-box and black-box testing, the testing life cycle, test planning, black-box design strategies — random testing, equivalence partitioning and boundary value analysis — white-box test adequacy criteria, and defect tracking and analysis.

After this unit you can

  • Distinguish errors, faults, defects and failures
  • Explain the levels and types of testing
  • Plan tests and design black-box and white-box test cases
  • Track and analyse defects

PTU syllabus topics

  • Errors/faults/defects/failures
  • unit/integration/system/regression/alpha/beta/acceptance testing
  • functional/performance/recovery testing
  • white-box and black-box testing
  • testing life cycle
  • test planning
  • black-box design strategies (random testing, equivalence class partitioning, boundary value analysis)
  • white-box test adequacy criteria
  • defect tracking and analysis
ProcessError, fault and failure
  1. 1Error

    A human mistake

  2. 2Fault (defect)

    The mistake in code

  3. 3Failure

    The system behaves wrongly when the fault runs

1

Topic 1

Errors, faults, defects and failures

ProcessFrom mistake to failure
  1. 1Error (mistake)

    A human action producing an incorrect result — a developer misreads a requirement

  2. 2Fault (bug)

    The incorrect step or code introduced — wrong condition in the program

  3. 3Defect

    Any deviation from requirements found in a work product

  4. 4Failure

    Observable incorrect behaviour when the faulty code runs — wrong fee calculated

  • Not every fault causes a failure: the faulty code may never execute or may give correct output for most inputs. Testing reveals failures; debugging locates and removes faults.
2

Topic 2

Levels of testing

  • Testing: executing a program to find errors; a good test case has a high chance of finding an undiscovered error. Testing shows the presence of defects, not their absence.
HierarchyLevels of testing
  1. Acceptance testing

    Users confirm the system meets their needs

  2. System testing

    The complete system against requirements

  3. Integration testing

    Combined modules and their interfaces

  4. Unit testing

    Individual modules

ComparisonBlack box and white box testing
Black box
White box

Basis

Requirements and inputs–outputs

Internal code and logic

Tester knows code?

No

Yes

Techniques

Equivalence partitioning, boundary value analysis

Statement, branch and path coverage

Done by

Testers, users

Developers

3

Topic 3

Integration testing approaches

ComparisonIntegration approaches
Method
Pros and cons

Big bang

All modules combined at once

Simple; faults hard to locate

Top-down

Start from the main module, use stubs below

Early skeleton; many stubs

Bottom-up

Start from low-level modules, use drivers

Easy fault isolation; no early prototype

Sandwich

Top-down and bottom-up together

Balanced; more complex

4

Topic 4

System, regression, alpha, beta and acceptance testing

Key termsFurther levels and types
System testing
Complete integrated system against requirements
Regression testing
Re-running tests after changes to catch new faults
Alpha testing
Users test at the developer's site under observation
Beta testing
Real users test in their own environment
Acceptance testing
Customer decides whether to accept, using agreed criteria
ComparisonFunctional, performance and recovery testing
Checks
Example

Functional testing

Features behave as specified

Admission form saves a valid record and rejects invalid ones

Performance testing

Response time, throughput and resource use under load

Results page loads within 2 seconds for 5,000 users

Recovery testing

System recovers correctly after forced failure

Power cut during fee payment does not lose or double-charge the transaction

5

Topic 5

The software testing life cycle

CycleSoftware testing life cycle (STLC)
Software testing life cycle (STLC)
1Requirement analysis
2Test planning
3Test case development
4Test environment set-up
5Test execution
6Test closure
  1. 1. Requirement analysis: Identify testable requirements
  2. 2. Test planning: Strategy, scope, effort, schedule, tools
  3. 3. Test case development: Write test cases and test data
  4. 4. Test environment set-up: Hardware, software, data
  5. 5. Test execution: Run tests and log defects
  6. 6. Test closure: Reports, metrics, lessons learnt
6

Topic 6

Test planning

Key termsContents of a test plan (IEEE 829)
Test plan identifier and introduction
Purpose and references
Test items and features to be tested
What will be tested
Features not to be tested
And why
Approach
Levels, types, techniques, tools
Pass/fail criteria
When a test passes; suspension and resumption criteria
Deliverables
Test cases, logs, defect reports, summary report
Environment and responsibilities
Set-up, people, training
Schedule and risks
Milestones, contingencies, approvals
7

Topic 7

Black-box test design strategies

  • Random testing: inputs chosen at random from the input domain — cheap and unbiased but may miss important cases; useful with automated oracles (fuzz testing).
8

Topic 8

Equivalence partitioning, boundary value analysis and other techniques

ComparisonBlack-box techniques
Idea
Example for marks 0–100

Equivalence partitioning

Divide inputs into valid and invalid classes; test one value from each

Classes below 0, 0–100, above 100: test −5, 50, 120

Boundary value analysis

Errors cluster at edges; test at and around boundaries

−1, 0, 1, 99, 100, 101

Cause–effect graphing and decision tables

Map combinations of input conditions to actions

Fine rules for late returns

Graph-based testing

Model objects and relationships, test each link

Navigation between screens

  • Black-box testing finds incorrect or missing functions, interface errors, data structure errors, performance and initialisation errors.

Example

Age field accepting 18–60: equivalence classes — below 18 (invalid), 18–60 (valid), above 60 (invalid); test 10, 35, 70. Boundary values: 17, 18, 19, 59, 60, 61.

9

Topic 9

White-box test adequacy criteria

  • Adequacy criterion: a rule deciding when white-box testing is sufficient, measured as coverage.
HierarchyCoverage criteria (weaker to stronger, top to bottom)
  1. Statement coverage

    Every statement executed at least once

  2. Branch (decision) coverage

    Every branch of each decision taken both ways

  3. Condition coverage

    Each condition in a decision evaluated true and false

  4. Multiple-condition coverage

    All combinations of conditions

  5. Path coverage

    Every independent path — basis path testing with V(G)

Example

if (a > 0 && b > 0) x = 1; — one test (a = 1, b = 1) gives statement coverage; adding (a = −1, b = 1) gives branch coverage; condition coverage also needs b false, e.g., (a = 1, b = −1).

  • Data flow criteria: all-definitions, all-uses and all-du-paths track where variables are defined and used. Loop testing checks loops at zero, one, typical and maximum iterations.
10

Topic 10

Defect tracking and analysis

CycleDefect life cycle
Defect life cycle
1New
2Assigned
3Open
4Fixed
5Retest
6Closed
  1. 1. New: Logged by the tester
  2. 2. Assigned: Given to a developer
  3. 3. Open: Being fixed
  4. 4. Fixed: Change made
  5. 5. Retest: Tester verifies
  6. 6. Closed: Verified fixed — or Reopened if it persists
ComparisonSeverity and priority
Severity
Priority

Meaning

Impact of the defect on the system

Urgency of fixing it

Set by

Tester

Product manager or lead

Example of high severity, low priority

Crash in a rarely used old report

—

Example of low severity, high priority

—

Spelling mistake in the college name on the home page

  • Defect report contents: ID, title, steps to reproduce, expected and actual results, environment, severity, priority, screenshots, status. Tools: Jira, Bugzilla, Azure DevOps.
  • Defect analysis: classify defects by type, phase and cause; use Pareto analysis and root cause analysis; measure defect density and removal efficiency to improve the process.

Key terms

Fault
Incorrect step or code in a program
Failure
Observable deviation from expected behaviour
Test plan
Document describing scope, approach, resources and schedule of testing
Boundary value analysis
Testing at and around input boundaries
Branch coverage
Every decision outcome exercised at least once

Quick revision

  • Error → fault → defect → failure.
  • Unit, integration, system, regression, alpha, beta, acceptance; functional, performance, recovery.
  • STLC phases; IEEE 829 test plan contents.
  • Random testing, equivalence partitioning, BVA.
  • Statement, branch, condition, path coverage; defect life cycle; severity vs priority; defect analysis.

Important exam questions

Practice questions written to the PTU exam pattern for this unit's syllabus: short answers (Section A style) and long answers (Sections B and C style).

Short-answer questions

  1. Q1.Distinguish a fault and a failure.
  2. Q2.What is regression testing?
  3. Q3.Name the phases of the STLC.
  4. Q4.What is random testing?
  5. Q5.Distinguish statement and branch coverage.
  6. Q6.Distinguish severity and priority.

Long-answer questions

  1. Q1.Explain the levels and types of software testing.
  2. Q2.Explain the testing life cycle and test planning.
  3. Q3.Explain black-box test design strategies with examples.
  4. Q4.Explain white-box adequacy criteria and defect tracking.

Stuck on this unit?

Message SBS on WhatsApp for help with Software Testing and Quality Assurance, or to ask about studying B.Sc IT at Synetic.

WhatsApp us