Unit 3: Test Administration

I. Foundations of Test Administration

Test administration is the coordinated process of planning, designing, organizing, executing, tracking, and maintaining testing activities throughout the software development life cycle. It connects business requirements with test cases, resources, environments, schedules, evidence, defects, and release decisions.

Defining characteristics:

• Traceability: Each test case should connect to a requirement, user story, risk, or acceptance criterion through identifiers such as REQ-12 and TC-45.
• Repeatability: A test must define its inputs, preconditions, actions, and expected results clearly enough for another tester or an automation tool to reproduce it.
• Coverage: Testing should address functional behavior, quality attributes, interfaces, error conditions, and important business risks.
• Control: Plans establish scope, responsibilities, schedules, entry criteria, exit criteria, and procedures for managing changes.
• Visibility: Test status is communicated through execution results, defect reports, coverage measures, and progress dashboards.
• Evidence: Logs, screenshots, reports, input data, and actual results support conclusions about software quality.
• Maintenance: Test assets must be updated when requirements, interfaces, test data, environments, or implementation details change.

II. Test Planning — Establishing the Testing Strategy

A. Goal of Test Planning

The goal of test planning is to define how testing will provide sufficient evidence about product quality within available time, cost, people, and technical constraints.

• Scope definition: The plan identifies features that will and will not be tested; for example, release 3.2 may include checkout testing but exclude the deferred recommendation engine.
• Risk control: Testing effort is prioritized by probability and impact.
  • A payment-calculation defect has high business impact and therefore receives deeper testing.
  • A minor alignment issue may receive lower priority unless accessibility or usability is affected.
• Shared expectations: Stakeholders agree on test levels, responsibilities, deliverables, and acceptance conditions before execution begins.
• Resource coordination: The plan assigns testers, environments, devices, tools, test data, and execution time to specific activities.
• Feasibility assessment: Dependencies such as an available API sandbox, valid accounts, or supported browsers are identified early.
• Decision support: Exit criteria provide an objective basis for release recommendations; an example is “all critical tests passed and no unresolved severity-one defects.”
• Change management: The plan defines how new requirements, delayed builds, unavailable environments, or discovered risks will alter scope and schedule.

B. Test Planning Topics

Test planning topics are the major decisions recorded so that testing can be executed, measured, and governed consistently.

• Objectives and scope: State the product areas, test levels, interfaces, and quality characteristics covered by the plan.
• Test basis: Identify authoritative inputs such as requirements, user stories, architecture diagrams, API specifications, and acceptance criteria.
• Test strategy: Select suitable approaches, including risk-based, requirements-based, exploratory, regression, performance, security, and compatibility testing.
• Test levels and types: Distinguish component, integration, system, and acceptance testing, then assign functional or non-functional tests to each level.
• People and responsibilities: Define ownership using named roles; developers may run unit tests while a QA team manages system-level regression.
• Environment and data: Document operating systems, browsers, databases, services, credentials, data-reset procedures, and privacy controls.
• Schedule and estimates: Record milestones, dependencies, effort, and contingency. Estimation may use historical execution rates, such as 120 regression cases per tester-day.
• Entry and exit criteria: Entry criteria might require a deployed build and completed smoke test; exit criteria might require 95% planned execution and no open critical defects.
• Defect management: Specify severity, priority, workflow states, required evidence, retesting rules, and closure authority.
• Metrics and reporting: Use measures such as pass rate and requirement coverage:

Pass rate = Passed test cases / Executed test cases × 100
Coverage  = Covered requirements / Total requirements × 100

• Risks and contingencies: Record triggers and responses, such as replacing an unavailable external service with an approved test double.

III. Test Case Planning — Converting Objectives into Test Assets

A. Goals of Test Case Planning

The goals of test case planning are to determine what cases are needed, how they demonstrate coverage, and how they can be executed and maintained economically.

• Requirement verification: Every testable requirement should have at least one linked test condition; REQ-LOGIN-04, for example, may require account locking after repeated failures.
• Risk-based depth: High-risk behavior receives positive, negative, boundary, recovery, and authorization cases rather than only a normal-flow case.
• Defect detection: Cases are chosen to expose likely failures, including invalid states, incorrect calculations, missing validation, and broken integrations.
• Balanced coverage: Planning includes valid inputs, invalid inputs, boundaries, alternate paths, and relevant combinations without attempting every possible value.
• Efficient execution: Reusable setup, shared data, and prioritized suites reduce duplication and support smoke, regression, and release testing.
• Automation selection: Stable, repeatable, deterministic, and frequently executed cases are strong automation candidates; rapidly changing visual behavior may remain manual.
• Maintainability: Cases should describe business intent clearly and avoid unnecessary dependence on unstable implementation details.

B. Test Case Planning Overview

Test case planning transforms the test basis into test conditions, test cases, data requirements, suites, and execution priorities.

• Analyze the test basis: Inspect each requirement for inputs, outputs, rules, states, actors, interfaces, and exceptions.
• Identify test conditions: Convert behavior into statements such as “registered customer can reset a password using a valid, unexpired token.”
• Select techniques: Apply equivalence partitioning, boundary-value analysis, decision tables, state-transition testing, use-case testing, or experience-based testing.
• Define expected outcomes: Expected results must be observable, such as HTTP status 400, database state LOCKED, or message “Invalid postal code.”
• Prepare dependencies: Determine accounts, files, devices, service stubs, database records, and environment configuration required for execution.
• Prioritize cases: Assign priorities using business impact, failure likelihood, execution frequency, and dependency order.
• Review and baseline: Stakeholders check correctness, completeness, duplication, and traceability before cases become an approved baseline.
• Plan maintenance: Requirement changes trigger impact analysis to identify obsolete, modified, and newly required cases.

C. Test Case Organization and Tracking

Test case organization and tracking preserve control over large test inventories and make coverage and execution status visible.

• Unique identifiers: Stable IDs such as TC-CART-017 allow reliable links among requirements, defects, reports, and automation code.
• Hierarchical grouping: Organize cases by product area, test level, feature, or suite; for example, Commerce > Checkout > Payment > Negative.
• Standard metadata: Store title, requirement link, owner, priority, preconditions, data, platform, automation status, and last review date.
• Lifecycle states: Typical design states include Draft, In Review, Approved, Deprecated, and Blocked.
• Execution states: Record Not Run, Passed, Failed, Blocked, or Skipped; a failed result should include the actual outcome and supporting evidence.
• Traceability matrix: A requirement-to-test mapping reveals uncovered requirements and redundant cases.
• Defect linkage: A failed case links to a defect such as BUG-284, while retest results demonstrate whether the fix is effective.
• Version control: Automated tests belong in source control, while managed manual cases require history, baselines, and audit information.
• Metrics: Dashboards may show execution progress, failure trends, blocked cases, requirement coverage, and automation coverage without treating case count alone as quality.

D. Test Case Design

Test case design systematically derives a small but effective set of cases from the behavior and risks under examination.

• Equivalence partitioning: Divide inputs into classes expected to behave alike; an age rule accepting 18–65 creates valid and invalid partitions.
• Boundary-value analysis: Test values at and around limits; for the same rule, useful values are 17, 18, 65, and 66.
• Decision-table testing: Represent combinations of conditions and actions, such as valid credentials, active account, and multifactor approval.
• State-transition testing: Verify allowed and forbidden transitions; an order may move from PAID to SHIPPED but not directly from CANCELLED to SHIPPED.
• Use-case testing: Follow end-to-end actor goals, including main, alternate, and exception flows.
• Pairwise testing: Select combinations so every pair of parameter values appears when exhaustive combination testing is impractical.
• Error guessing: Use defect history and technical knowledge to test empty files, duplicate submissions, expired sessions, and interrupted network calls.
• Test quality: A well-designed case is traceable, independent where practical, reproducible, unambiguous, and focused on one clear objective.

IV. Test Case Construction — Manual and Automated Implementation

A. Building Manual Test Cases

Building manual test cases means writing precise instructions and expected observations for execution by a human tester.

• Case header: Include ID, title, requirement, priority, author, environment, and version; a title such as “Reject expired reset token” expresses behavior directly.
• Preconditions: Specify required state, such as an active user account and a reset token older than 30 minutes.
• Test data: Provide controlled values or a reference to protected data; never place production passwords or personal data in the case.
• Steps: Use numbered, atomic actions with visible targets.
  1. Open the password-reset URL containing the expired token.
  2. Enter a compliant new password.
  3. Select Submit.
• Expected result: State an observable result for the relevant step: the password remains unchanged, access is denied, and an expiry message appears.
• Postconditions: Describe cleanup, such as deleting generated accounts or restoring modified configuration.
• Evidence and outcome: Record build number, actual result, status, screenshots, logs, and linked defect IDs.
• Writing discipline: Avoid vague instructions such as “check the page works”; identify the field, action, data, and required response.

B. Building Automated Test Cases Using Java Framework Tools

Building automated test cases with Java framework tools converts repeatable checks into executable code that can run locally or in continuous integration.

• Core toolchain: JUnit 5 or TestNG supplies lifecycle and assertion APIs; Maven or Gradle resolves dependencies and runs suites; Selenium WebDriver automates browsers.
• Test structure: Use setup, action, assertion, and cleanup phases so failures are localized and test intent remains readable.
• JUnit example: A deterministic business-rule test can verify an exact boundary without browser overhead.

import static org.junit.jupiter.api.Assertions.assertFalse;
import org.junit.jupiter.api.Test;

class PasswordTokenTest {
    @Test
    void rejectsTokenOlderThanThirtyMinutes() {
        PasswordToken token = PasswordToken.minutesOld(31);

        boolean accepted = token.isValid();

        assertFalse(accepted, "Expired token must be rejected");
    }
}

• Browser automation: Selenium locates elements using stable attributes such as id or data-testid, performs user actions, and verifies observable page state.
• Synchronization: Explicit waits should monitor a condition such as element visibility; fixed sleeps like Thread.sleep(5000) are slow and unreliable.
• Framework organization: Page Objects encapsulate page interactions, test-data builders create controlled inputs, and JUnit tags separate smoke from regression.
• Independence: Each test should create or reset its own data and must not depend on another test’s execution order.
• Assertions and diagnostics: Assertions compare actual and expected behavior, while logs, screenshots, and reports provide evidence when failures occur.
• Continuous integration: Maven can execute tests through mvn test; the pipeline should publish reports and fail when required checks fail.
• Maintenance controls: Code review, source control, naming conventions, dependency updates, and removal of obsolete tests keep the suite reliable.