Expected Result
In software testing, the Expected Result is the predefined outcome that a system should produce for a given test case. It serves as the benchmark against which the actual result is compared to determine if the test passes or fails.
First used·1970s
Definitions·1
Synonyms·4
Category·Software Testing
Also known as
Definitions
What it means.
- 01
Expected Result in Software Testing
In the context of software testing, an Expected Result is the predefined, correct outcome that a software application is anticipated to produce after a specific set of actions or under a particular set of conditions. It is a fundamental component of a test case.
This predicted outcome serves as a benchmark or a 'test oracle' against which the 'Actual Result' (the behavior observed during test execution) is compared. The comparison between the expected and actual results determines the pass/fail status of a test.
Key Concepts
- Objectivity: It provides an objective basis for evaluation, removing ambiguity and subjective interpretation from the testing process.
- Requirement Traceability: Expected results are derived directly from system requirements, specifications, or user stories, ensuring that the tests validate the intended functionality.
- Scope: An expected result is not limited to what is visible on the user interface (UI). It can include changes in a database, a specific API response, the generation of a report, an entry in a log file, or the absence of an error.
Example Test Case
- Feature: User Login
- Test Scenario: Successful login with valid credentials.
- Test Steps:
- Navigate to the login page.
- Enter a valid username ('testuser').
- Enter the corresponding valid password ('password123').
- Click the 'Login' button.
- Expected Result: The system authenticates the user, redirects them to the user dashboard, and displays a welcome message, "Welcome, testuser!".
Origin
Where it comes from.
Etymology
The term is a straightforward combination of 'Expected' and 'Result'. 'Expected' originates from the Latin 'exspectare', meaning 'to look out for' or 'await'. 'Result' comes from the Latin 'resultare', meaning 'to spring back' or 'rebound'. In combination, it literally means 'the outcome that is awaited'.
Historical context
The concept of an Expected Result evolved alongside formal software testing methodologies. In the early days of computing (1950s-1960s), testing was often an ad-hoc activity performed by the developers themselves, without formally documented test cases or predefined outcomes. The primary goal was simply to see if the program ran without crashing.
As software systems became more complex and critical, the need for a more structured and rigorous approach became apparent. The 1970s marked a significant shift towards disciplined testing. Influential works, such as Glenford J. Myers' "The Art of Software Testing" (1979), emphasized that a key part of a proper test is defining the expected outcome before execution. This principle was crucial in transforming testing from a debugging activity into a professional discipline focused on verification and quality assurance. It established that a test's purpose is to find defects, which is only possible if you know what the correct behavior should be in the first place.
Usage
In context.
The test failed because the actual result did not match the Expected Result defined in the test case.
Before executing the test suite, the QA engineer meticulously documented the Expected Outcome for each scenario.
A good test oracle provides a reliable source for determining the correct Expected Behavior of the software under test.
For an API test, the Predicted Result might include a specific JSON payload and a 200 status code.
FAQ
Common questions.
Defining the Expected Result beforehand provides an objective and unbiased benchmark for evaluating the software's behavior. It prevents 'tester's bias,' where one might interpret an ambiguous actual result as correct. It forces the tester to thoroughly understand the requirements and ensures that the test has a clear, verifiable goal, making the pass/fail decision non-negotiable and repeatable.
Taxonomy
Filed under.
Categories
Tags