Software QA / Basic: reasoning and test design / Lesson 1
Quality, risk, and trustworthy evidence
Learn to turn a claim that software works into a bounded argument supported by observable evidence. A community training portal provides examples of correctness, usability, reliability, and the limits of testing.
On this page
Lesson goals
- Distinguish quality assurance, testing, defects, and failures.
- Choose observable oracles for user risks.
- Explain why coverage does not prove correctness.
Quality is a promise to people
A training portal can calculate every score correctly yet still prevent a keyboard user from submitting an assessment. Quality depends on the needs of affected people and on the circumstances of use. Start with outcomes: a learner can enroll once, see the correct price, and recover from an interrupted session without losing work. Quality assurance improves how work is defined and built; testing investigates the resulting product and supplies evidence. Neither activity belongs exclusively to a job title. Developers, designers, support staff, and learners can expose different risks.
Worked case: define the oracle first
An oracle is the basis for deciding whether observed behavior is acceptable. For a course priced at 120 units with an agreed discount of 25%, the independently calculated payable amount is 90 units. Record the pricing rule, currency precision, and whether tax is included before observing the screen. A second screen showing 90 is corroboration only if it does not reuse the same faulty calculation. Inspect the stored invoice and confirmation as separate observations, because a correct display can conceal an incorrect charge.
Separate mistake, defect, and failure
A developer may misunderstand whether a discount includes tax. That human error can introduce a defect in the calculation rule; executing a qualifying purchase may then produce a failure visible as an excessive charge. A defect need not fail on every input, and a failure can have several contributing causes. When investigating, preserve the input and environment rather than assigning blame. Static review can reveal the wrong rule before any purchase is executed. Dynamic testing exercises the system, while review examines artifacts such as designs and requirements.
Worked case: prioritize harm
Suppose the team can investigate only two issues today: a doubled payment, an inaccessible submit button, and an uneven heading margin. Payment threatens money; inaccessible submission excludes a group from completing the course; the margin mainly affects appearance. Priorities depend on exposure and available workarounds as well as severity. A rare problem can outrank a frequent cosmetic issue when harm is irreversible. Document who is affected and which assumptions remain untested so that the decision can be challenged constructively.
Risk | Observation | Useful next check
Duplicate charge | two invoices for one action | inspect retry handling
Keyboard exclusion | focus cannot reach submit | complete flow with keyboard
Heading margin | 4px visual difference | compare approved designThe table suggests investigation order; it does not assign a universal numeric severity.
Bound claims to the evidence
A passing test shows that a particular observation matched its oracle under stated conditions. It cannot establish that all users, devices, or future states behave correctly. Code coverage tells you which code was executed; requirement coverage tells you which stated obligations were checked. Both can miss a missing requirement or a weak assertion. Confidence also depends on independence of oracles, realistic data, recent changes, and unexplored risks. A useful report says which build, cases, and environments passed and what remains unknown, allowing others to make an informed decision.
Common errors and fixes
Treating every passing check as proof
- Why it happens
- The tested sample is confused with the entire behavior space.
- How to fix it
- Limit the claim to the tested conditions and record remaining risks.
- Prevent it next time
- Require an explicit scope statement in reports.
Copying expected prices from the application
- Why it happens
- The oracle repeats the implementation error.
- How to fix it
- Calculate expected totals from an agreed independent rule.
- Prevent it next time
- Review examples with the person responsible for pricing.
Making quality the testerโs responsibility alone
- Why it happens
- Review and design feedback arrive after implementation.
- How to fix it
- Bring risk questions into planning and design discussions.
- Prevent it next time
- Assign shared ownership of acceptance evidence.
Check your understanding
1. A dashboard says 100% statement coverage. What can you conclude?
Show worked solution
The measured run executed every measured statement. It may still lack checks for incorrect results, omitted requirements, or important combinations. Ask for the coverage scope, assertions, and risk evidence before making a release claim.
2. A price is 200 units with a 15% discount and no tax. Propose two observations.
Show worked solution
The independent total is 170. Verify the displayed payable amount and the persisted invoice amount both equal 170; also record that a payment provider is outside this isolated test. Their agreement supports consistency but does not prove the external debit.
Key takeaways
- State user outcomes, oracles, and observation limits.
- Use coverage as one measurement, alongside risk and evidence quality.