QA, Testing, and Code Audit
A self-study textbook covering essential theory, comparative examples, guided practice, quality review, and a capstone exercise. Central question: How do we find failures before release and create evidence that prevents recurrence?
Learning Goals and Study Routine
How do we find failures before release and create evidence that prevents recurrence? You complete today’s lesson when you can answer this question in your own words, produce the required artifact, and review its quality.
Explain the test pyramid and each layer’s purpose.
Convert requirements into test cases.
Apply boundary-value and equivalence-partition techniques.
Distinguish regression from exploratory testing.
Perform basic OWASP-oriented security checks.
Report defects in a reproducible format.
Recommended self-study routine
- Explain why a problem occurs before memorizing its terminology.
- Describe the difference between good and poor examples using observable criteria.
- Attempt the capstone before opening the model answer.
- Mark missing conditions in a second color and revise your artifact.
Table of Contents
- Study Guide and Learning GoalsPage 02
- Chapter 1. Core Theory and Design PrinciplesPage 04
- Chapter 2. Guided Design PracticePage 05
- Chapter 3. Case Review and Quality CheckPage 06
- Chapter 4. Capstone and Model AnswerPage 07
- Glossary and Final ChecklistPage 08
- Self-study reference and guided practicePages 09–11
Submit the capstone artifact, score at least 80/100 on the self-review, and write your own answers to the four concept questions.
Core Theory: QA, Testing, and Code Audit
Each technical term exists to solve a recurring design problem. Study when and why the concept is needed, not merely its definition.
| Core concept | Working definition |
|---|---|
| Unit Test | A fast isolated check of a small logic unit. |
| Integration Test | A check of interaction among a database, API, or other components. |
| E2E Test | A check of an entire critical journey from the user’s perspective. |
| Boundary Value | A value near a minimum or maximum where defects often occur. |
| Regression Test | A test that prevents a corrected defect from returning. |
| Threat Modeling | Analysis of attackers, assets, entry points, and mitigations. |
Poor and Effective Approaches
Avoid
Click a button once and record “works correctly.”
Prefer
Record preconditions, input, steps, and expected result, then exercise normal, boundary, permission, and failure conditions.
[Requirement ID] + [Precondition] + [Input] + [Steps] + [Expected Result] + [Evidence]
A Six-Step Design Workflow
Define the problem
Prioritize testing by user impact and risk.
Extract the structure
Create normal, boundary, error, and authorization cases for each requirement.
Design the core flow
Place logic in unit tests, connections in integration tests, and critical journeys in E2E.
Add failure conditions
Reproduce failures, fix the cause, and preserve a regression test.
Connect policies
Audit authentication, authorization, validation, and secret exposure.
Verify and trace
Report environment, steps, expected and actual results, screenshots, and logs.
Worked Example
Questions for reading the example
- Are the input and initiating condition explicit?
- Are success and failure outcomes observable?
- Are duplication, authorization, concurrency, and dependency failure covered as needed?
- Can the result be traced back to a requirement?
Concept Check and Quality Review
- Why does 100% code coverage not prove the absence of defects?
- What cost does a flaky test impose?
- How do authentication and authorization tests differ?
- Why must a defect report include environment details?
Answer each in two or three sentences and add one example that supports your explanation.
Self-Assessment · 100 points
| Area | Standard | Points |
|---|---|---|
| Accuracy | Concepts and technical choices match the facts and requirements. | 25 |
| Completeness | Normal flow, boundaries, failures, and recovery are covered. | 25 |
| Consistency | Terms, IDs, states, and interfaces agree across artifacts. | 20 |
| Verifiability | Observable outcomes and completion criteria are present. | 20 |
| Reasoning | The choice and its tradeoffs can be explained clearly. | 10 |
Do not only correct the result. Record which question you failed to ask so your next design process prevents the same omission.
Capstone Exercise and Model Answer
Create a test matrix for a login API, including success, wrong password, nonexistent user, repeated failures, and SQL-injection-shaped input.
- List assumptions and unresolved decisions first.
- Produce the main design as a table, diagram, or code block.
- Include the normal flow and at least three failures or boundaries.
- Score it with the rubric and compare before and after revision.
Open the model answer
Responses should avoid exposing whether an account exists. Verify rate limiting or lockout for repeated failures, safe parameter handling for SQL-shaped text, correct token properties on success, and absence of passwords from logs.
How to use the answer
The model is not the only valid design. If yours differs, explain the requirement, cost, complexity, or risk that justifies your choice.
Glossary and Final Checklist
| Term | Plain-English meaning |
|---|---|
| Test Oracle | The source used to determine whether a result is correct. |
| Equivalence Partition | A group of inputs expected to behave alike. |
| Flaky Test | A test that intermittently fails without a code change. |
| Regression | A previously working behavior that breaks again. |
| OWASP | A community providing web-security risks and guidance. |
| Severity | The impact a defect has on the system or user. |
Eight checks before submission
- Can you answer today’s central question in your own words?
- Are inputs, conditions, and results explicit?
- Did you include failures and recovery, not only the happy path?
- Did you review concurrency, duplicate requests, and permissions?
- Did you account for dependency failure and timeouts?
- Can you explain the disadvantages and alternatives to your choice?
- Are terminology and states consistent across artifacts?
- Is there an observable or testable completion standard?
How do we find failures before release and create evidence that prevents recurrence? Answer it now using evidence from the artifact you created.
Key Terms in Context
Learn each term as a decision tool. Read across each row: definition, reason to use it, and the failure it prevents.
| Term | Plain definition | Why it matters | Example or caution |
|---|---|---|---|
| Unit test | An isolated check of a small unit such as a function or class. | It finds logic regressions quickly and precisely. | Control external dependencies with test doubles. |
| Integration test | A check that databases, APIs, and services work together. | It catches contract errors at boundaries. | Use schemas and configuration close to production. |
| End-to-end test | A user-level check of the full workflow, often through a browser. | It proves the critical business path in a realistic system. | Keep it focused because it is slower and more fragile. |
| Regression | Previously working behavior broken by a change. | Automated tests should detect this risk. | Add a reproduction test whenever fixing a bug. |
| Test double | A stub, fake, or mock replacing a real dependency. | It makes failures and edge cases controllable. | Avoid asserting irrelevant implementation details. |
| Static analysis | Type, rule, and vulnerability checks without executing the program. | It catches low-cost defects early. | It complements rather than replaces runtime tests. |
A registration feature must handle duplicate email, weak password, network retry, and permission errors.
Guided Practice and Troubleshooting
Practice scenario
A registration feature must handle duplicate email, weak password, network retry, and permission errors.
Complete in order
- Turn requirements into Given-When-Then test conditions.
- Prioritize happy, boundary, error, and permission cases by risk.
- Catch defects at the cheapest layer: unit, then integration, then E2E.
- Reproduce the failing test, fix it, and run the full regression suite.
Save one artifact, three assumptions, and at least three failure cases. A classmate should be able to reproduce your reasoning without asking what you meant.
If the result is wrong, diagnose it
| Observed symptom | Likely cause | Next action |
|---|---|---|
| Test fails intermittently | Time, network, or shared-state dependency | Use a fixed clock and isolated test data |
| Every refactor rewrites many tests | Tests are coupled to implementation | Assert public behavior and outcomes |
| Tests pass but production fails | Missing real-boundary coverage | Add representative integration and E2E checks |
Check Your Understanding
Retrieval check — answer before opening
What is the test pyramid?
Use many fast unit tests, a moderate integration layer, and a small number of critical E2E tests.
Is 100% coverage sufficient?
No. Coverage shows executed lines, not whether important claims and boundaries were asserted.
When is QA complete?
Major risks have reproducible tests with explicit expected results.
Explain the day's main decision, one failure mode, and one verification method without reading the page. If you cannot connect all three, return to the row or diagnostic case you missed.