Software Testing Basics

Introduction

Software Testing Basics introduces you to practical software testing as it is used in training companies, IT departments, software teams, and vocational projects. You will learn how to plan tests, design useful test cases, execute them carefully, record evidence, report defects clearly, and decide what should be tested again after a change.

Software testing is more than clicking through an application. It includes evaluating requirements and other work products, looking for defects, checking whether specified requirements are fulfilled, reducing product risk, and giving stakeholders information for decisions. Testing and debugging are related but different: testing can reveal a failure or defect, while debugging identifies and removes the cause of a failure.

The testing pyramid is a useful mental model for automation: many fast checks can be performed close to individual components, while fewer broad end-to-end checks exercise the complete product. The exact balance depends on the system, risks, technology, and team.

Learning goals: By the end of this aiMOOC, you should be able to explain core testing terms, distinguish important test levels and test types, write traceable test cases, use basic black-box techniques, document defects, perform regression checks, and communicate test results in a professional way.

A useful vocational mindset is: be curious, be systematic, and make your evidence reproducible. Your goal is not to prove that software has no defects. Your goal is to provide useful information about quality and risk.

Why Software Testing Matters

Software can fail because people make mistakes, requirements are unclear, interfaces behave unexpectedly, environments differ, or changes affect existing behavior. A human error can introduce a defect into a work product. When a defect is executed under suitable conditions, the software may produce an observable failure.

Testing contributes to quality by finding defects early, evaluating the product, and reducing uncertainty. Early feedback is valuable because an unclear requirement found during a review may be easier and cheaper to correct than the same problem discovered after release.

Testing is not the same as quality assurance. Testing is product-oriented quality control. Quality assurance is process-oriented and aims to improve how development and testing work are performed.

Seven Practical Testing Principles

The following principles are widely taught in foundation-level software testing and are useful in everyday work:

Testing shows the presence of defects: A test can demonstrate that a problem exists, but successful tests cannot prove that no undiscovered defects remain.
Exhaustive testing is impossible: Except for trivial cases, you cannot test every possible input, path, device, configuration, and timing combination.
Early testing saves time and money: Reviews, examples, and tests started early can prevent defects from spreading into later work products.
Defects cluster together: Some modules or features often contain more defects than others, so observed defect concentration can inform risk-based testing.
Tests wear out: Repeating exactly the same tests may become less effective at finding new problems, so test data and test ideas should evolve.
Testing is context dependent: A medical device, an online shop, an internal script, and a game need different priorities and evidence.
Absence of defects does not guarantee usefulness: Software can satisfy documented requirements and still fail to meet user or business needs.

Testing in the Software Development Lifecycle

Testing belongs throughout the software development lifecycle. In sequential approaches, test activities may be mapped to development stages. In iterative and agile approaches, analysis, development, testing, and feedback can happen repeatedly within short cycles.

The V-model illustrates the relationship between development work and corresponding test activities. It is useful for understanding traceability: requirements lead to acceptance-oriented tests, system specifications lead to system tests, and detailed design or components lead to lower-level tests. Real projects may organize the work differently.

Static and Dynamic Testing

Static testing evaluates work products without executing the software. Examples include reviewing requirements, user stories, acceptance criteria, source code, or test cases. Static analysis tools can also inspect code or other artifacts automatically.

Dynamic testing executes the software and compares actual behavior with expected behavior. Manual exploratory checks, automated unit tests, API checks, and system tests are all dynamic when the software is executed.

A trainee can contribute to static testing even before a feature exists. For example, you can read a user story and ask whether the acceptance criteria cover invalid input, permissions, error messages, and important boundary cases.

Test Levels

A test level groups test activities around a particular scope and objective. A modern foundation-level view distinguishes five useful levels:

Component testing: Tests an individual component in isolation, often with a unit-test framework.
Component integration testing: Tests interfaces and interactions between components.
System testing: Tests the behavior and capabilities of the complete system or product.
System integration testing: Tests interfaces between the system under test and other systems or external services.
Acceptance testing: Validates readiness and whether the system fulfills user or business needs.

In vocational practice, always ask what the test object is. A calculation function, a web service, a full application, and a connection to a payment provider need different test environments and evidence.

Test Types

A test type groups test activities according to a particular objective or quality characteristic. A test type can often be used at more than one test level.

Functional testing asks what the software should do. Examples include checking that a login works with valid credentials or that an invoice total is calculated correctly.

Non-functional testing asks how well the software behaves. Depending on the product, this can include performance efficiency, usability, reliability, security, compatibility, maintainability, portability, or safety.

Black-box testing derives tests from requirements, behavior, interfaces, or specifications without relying on internal code structure. White-box testing derives tests from the internal structure of the implementation. Experience-based testing uses tester knowledge, defect history, intuition, checklists, and exploration.

Confirmation and Regression Testing

After a defect is fixed, confirmation testing checks whether the specific fix solved the reported problem. Regression testing checks whether the change caused failures in previously working areas.

Example: A developer fixes a discount-calculation defect. First, repeat the test that exposed the wrong discount. Then run relevant regression tests for normal prices, tax, coupons, totals, and checkout because the change may affect related behavior.

The Test Process in Practice

A professional test process is usually iterative rather than a strict one-way sequence. Important activities include test planning, monitoring and control, test analysis, test design, test implementation, test execution, and test completion.

Test planning defines objectives, scope, priorities, resources, risks, and the approach. Test analysis asks what should be tested. Test design turns test conditions into test cases and decides how to test. Test implementation prepares scripts, data, environments, and suites. Test execution runs the tests and records results. Test completion summarizes status, unresolved risks, lessons learned, and useful testware for future work.

For apprentices, the most important habit is traceability: connect a requirement or risk to a test case, connect the test case to a result, and connect a failed result to a defect report.

Writing Good Test Cases

A test case should be clear enough that another trained person can understand what is being checked and how the result was obtained. Exact templates differ between organizations, but a useful test case often contains:

Identifier and objective: A short unique ID and a statement of what you are checking.
Preconditions: Required accounts, permissions, system state, data, or configuration.
Test data: Inputs such as user values, files, dates, or records.
Steps: Actions performed in a clear order.
Expected result: Observable behavior that should occur.
Actual result and status: What happened and whether the test passed or failed.
Traceability: Links or references to the requirement, user story, risk, or defect.

Example scenario: A registration form accepts ages from 18 through 65. A weak test checks only age 30. A stronger set also checks values at and around the limits, invalid text, missing data, and any relevant business rules.

Basic Black-Box Test Design

You rarely have enough time to try every possible value. Test techniques help you select a smaller set of high-value tests.

Equivalence Partitioning

With equivalence partitioning, you divide input or output values into groups that are expected to be handled in a similar way. You then select representative values from relevant valid and invalid partitions.

Example: If an age field accepts 18 to 65, you can think of three simple partitions: below 18, from 18 to 65, and above 65. Representative values might be 17, 35, and 66.

Boundary Value Analysis

Boundary value analysis focuses on values at boundaries because defects are often found near the edges of valid ranges. For the range 18 to 65, useful checks include values around both boundaries, such as 17, 18, 19, 64, 65, and 66.

Boundary tests should be derived from the specification. Do not guess whether a boundary is inclusive or exclusive; confirm the rule in the requirement or with the responsible stakeholder.

Decision Tables and State Transitions

Decision table testing is useful when outcomes depend on combinations of conditions. For example, free shipping may depend on order value, membership status, and destination.

State transition testing is useful when behavior depends on the current state and an event. For example, an account may move from active to locked after repeated failed login attempts, and different actions may be allowed in each state.

Exploratory Testing

Exploratory testing combines learning, test design, and execution. You investigate the product with a purpose, observe behavior, form new questions, and adapt your next tests based on what you learn.

A useful exploratory session has a charter, such as: “Explore the shopping cart with unusual quantities and rapid changes to identify calculation or state problems.” Take notes, capture evidence, and record important coverage and findings.

Exploration is not random clicking. Skilled exploratory testing is structured by risk, models, checklists, time boxes, observations, and critical thinking.

Defect Reporting

A defect report should help another person understand, reproduce, investigate, and prioritize a problem. A useful report normally contains a concise title, environment, preconditions, reproducible steps, expected result, actual result, evidence, severity or impact, and references to related requirements or tests.

A defect can move through different workflow states depending on the tracking tool and team process. Do not assume that every organization uses the same state names. What matters is that the current status, responsibility, evidence, and decision are visible.

Example title: “Checkout total ignores ten-percent member discount after quantity change” is more useful than “Checkout broken”.

When reporting, describe observable facts. Avoid blaming individuals. If you cannot reproduce a failure consistently, record the exact environment, test data, timing, logs, screenshots, and frequency.

Manual Testing and Test Automation

Manual testing is performed by a person who interacts with the software, evaluates results, explores behavior, or reviews work products. It is especially useful when human judgment, usability, visual observation, or rapid exploration matters.

Automated testing uses scripts and tools to execute checks, compare results, and report outcomes. Automation is valuable for repeatable regression checks, large data sets, frequent builds, and fast feedback. Automation also has costs: tests must be designed, implemented, maintained, and interpreted.

A good automation candidate is stable enough to automate, executed often enough to justify the work, and important enough that fast repeatable feedback is valuable. Not every test should be automated.

Test-driven development is one test-first approach in which a developer creates a test, observes it fail for the expected reason, writes enough production code to make it pass, and then improves the code while preserving the test result.

Testing in a Vocational Workplace

In a training company or apprenticeship project, software testing is a team activity. Developers, testers, product owners, support staff, users, and trainees can all contribute useful information about quality.

Professional behavior includes asking precise questions, protecting test data, respecting privacy, documenting evidence, communicating risk without exaggeration, and separating facts from assumptions. If production data is sensitive, use approved test environments and anonymized or synthetic data according to organizational policy.

Typical trainee activities include reviewing acceptance criteria, preparing test data, executing manual test cases, writing simple automated checks, reproducing reported problems, updating defect reports, and presenting test results in a team meeting.

Workplace Example: Testing a Booking Form

Imagine you are testing a booking form for a vocational training center. The user selects a course, enters contact data, chooses a date, and submits the booking.

A sensible test approach combines several ideas. Check a normal successful booking. Test required fields and invalid formats. Use boundary analysis on date or quantity rules. Check duplicate submissions. Verify permissions if staff and learners see different information. Inspect error messages for clarity. Test the interface with the email or database service. Confirm that data is stored correctly. Re-test fixed defects and run regression checks on related booking functions.

Your test evidence should make it possible to answer: What was tested? In which environment? With which data? What happened? Which requirements or risks were covered? What remains uncertain?

Interactive Tasks

Quiz: Test Your Knowledge

What is a main purpose of software testing? (Provide information about quality and risk) (!Prove that software contains no defects) (!Replace all quality assurance activities) (!Guarantee that every user is satisfied)

Which activity is static testing? (Reviewing a requirement without executing software) (!Running a checkout test in a browser) (!Calling an API and checking its response) (!Executing an automated unit test)

Which test level focuses on an individual component in isolation? (Component testing) (!System testing) (!Acceptance testing) (!System integration testing)

Which test type evaluates what the software should do? (Functional testing) (!Performance testing) (!Usability testing) (!Reliability testing)

What does confirmation testing check after a defect fix? (The specific problem has been fixed) (!Every possible defect has been removed) (!The complete system needs no more testing) (!The test environment matches production exactly)

What is the purpose of regression testing after a change? (Check that existing behavior was not adversely affected) (!Replace the need for confirmation testing) (!Prove that all requirements are correct) (!Measure only the speed of the changed feature)

Which technique focuses on values near the edges of input ranges? (Boundary value analysis) (!State transition testing) (!Decision table testing) (!Checklist based testing)

What should a good defect report contain? (Reproducible steps and observed results) (!Only the name of the tester) (!Only a screenshot without context) (!A guess about who caused the defect)

Which statement about test automation is correct? (Automated tests require maintenance) (!Every useful test should be automated) (!Automation removes the need for human judgment) (!Automation always finds more defects than exploration)

Why is traceability useful in testing? (It connects requirements tests results and defects) (!It guarantees zero residual risk) (!It eliminates the need for test data) (!It makes every test case identical)

Memory Game

Defect	A flaw in a work product that may cause a failure
Failure	Observable incorrect behavior during execution
Regression	Unintended impact on existing behavior after change
Boundary	Edge of an input or output partition
Traceability	Connection between basis tests results and findings
Charter	Focus and mission for an exploratory test session
Assertion	Automated check that compares an actual condition with an expected one

Drag and Drop

Match the correct terms.	Topic
Checks one component in isolation	Component testing
Checks interactions between components	Component integration testing
Checks the complete product behavior	System testing
Checks interfaces with external systems	System integration testing
Checks readiness for user or business needs	Acceptance testing

...

Crossword Puzzle

Regression	What testing checks for unintended effects on existing behavior after a change
Boundary	What word describes the edge of an input range used in a focused test technique
Defect	What term describes a flaw in a software work product
Integration	What kind of testing focuses on interactions between connected parts
Acceptance	What testing validates readiness and user or business needs
Assertion	What automated check compares an actual condition with an expected condition

LearningApps

Cloze Text

Software testing provides information about software

and risk. A human mistake can introduce a

into a work product. When a defect is executed it may cause a visible

. Reviewing requirements without executing the program is a form of

testing. Testing an individual component in isolation is called

testing. Testing values near the edge of a valid range is known as

value analysis. After a defect fix confirmation testing checks the specific

. Regression testing looks for unintended effects on

behavior. A useful defect report includes steps evidence and the observed

. Traceability connects requirements tests results and

.

Open-Ended Tasks

Easy

Test case writing: Choose a simple calculator or form and write three test cases with preconditions, steps, data, expected results, and space for actual results.
Boundary value analysis: Find one field with a clear range rule and create a small visual showing useful tests just below, at, and just above each boundary.
Defect report: Use a safe practice application or teacher-provided example, observe one problem, and write a defect report that another learner could reproduce.
Testing interview: Interview a developer, tester, support worker, or instructor about how software problems are discovered and documented in their workplace, then summarize the answers.

Standard

Exploratory testing: Plan and conduct a thirty-minute exploratory session using a clear charter, then submit your notes, evidence, coverage, and findings.
Regression testing: Imagine that a discount calculation was changed and design a focused regression suite covering related price, tax, coupon, total, and checkout behavior.
Decision table testing: Model a workplace rule with at least three conditions, create a decision table, and derive test cases for the important rule combinations.
Test presentation: Produce a three-minute video or live demonstration explaining one tested feature, the main risks, the evidence collected, and the current quality status.

Advanced

Risk-based testing: Analyze a small application, identify product risks by likelihood and impact, prioritize them, and justify how your test effort follows the risk assessment.
Test automation: Automate a small stable regression scenario with an approved tool, record the test code and result, and compare the maintenance cost with a manual alternative.
System integration testing: Design a test approach for an application that exchanges data with an external service, including success, timeout, invalid response, and unavailable-service scenarios.
Testing process improvement: Observe or simulate a complete mini test cycle, identify one weakness in planning, evidence, traceability, or reporting, and propose a measurable process improvement.

Learning Assessment

Test strategy: Given a small vocational software project, select suitable test levels, test types, and techniques, and justify each choice using product risks and available resources.
Traceability assessment: Build a traceability map that connects selected requirements to test cases, results, and defects, then explain what coverage and gaps the map reveals.
Defect triage: Compare several defect reports, rank their urgency using impact and likelihood, identify missing evidence, and defend your prioritization to a simulated project team.
Change impact analysis: Analyze a proposed code or requirement change, predict which existing areas could be affected, and design a confirmation and regression approach.
Test evidence portfolio: Submit a compact portfolio containing a review finding, a designed test case, an executed result, a defect report, and a reflection on what each artifact proves or does not prove.
Quality communication: Prepare a short release recommendation that distinguishes passed tests, failed tests, untested areas, residual risks, and assumptions without claiming more certainty than the evidence supports.

Evidence of Learning

Knowledge: You can explain core terms such as error, defect, failure, static testing, dynamic testing, test level, test type, confirmation testing, regression testing, and traceability.

Skills: You can analyze requirements, derive practical tests, use equivalence partitions and boundary values, execute tests systematically, collect evidence, reproduce failures, and communicate findings.

Products: Your portfolio can include test cases, test data, exploratory notes, decision tables, automated checks, defect reports, traceability maps, and test summaries.

Transfer achievements: You can select and adapt testing approaches for unfamiliar workplace scenarios, prioritize based on risk, explain the limits of your evidence, and collaborate with developers, users, and other stakeholders.

OERs on the Topic

Useful further study includes the official software testing terminology used in professional practice, Unit testing, Integration testing, System testing, Acceptance testing, Regression testing, Black-box testing, White-box testing, Exploratory testing, and Test-driven development.

Linked Learning Areas

Software testing

aiMOOC Projects

Diesen aiMOOC als Battle spielen: Englisch, Klasse 5-6, G-Niveau

Inhalte werden geladen ...

Mediathek wird aus dem Wiki geladen ...

Frag mich zum aktuellen Lerninhalt oder wähle eine kurze Hilfe.

Textmodus bereit

Sprache

English:Software Testing Basics