Fundamentals

Black-box tests behavior through the interface with no knowledge of internals — focus on requirements. White-box tests with full access to code and structure — focus on paths and branches. Grey-box combines both: you test from outside but use partial knowledge of internals (DB, API) to design smarter checks.

A bug report is a documented description of a defect that lets others reproduce and fix it. Core fields: a clear title/summary, environment, preconditions, numbered steps to reproduce, the expected result versus the actual result, severity and priority, plus attachments (screenshots, screencasts, logs, stack traces). The expected-vs-actual pair is its heart.

Severity is how badly the defect impacts the system's functioning (blocker, critical, major, minor) — a technical measure usually set by the tester. Priority is how urgently it must be fixed — a management measure set by the lead/manager from business impact. They are independent: a typo on the logo can be low severity but high priority.

Smoke testing is a shallow, wide sanity check that the build's critical paths work and it is worth testing further; a small, fast set run first on every build. Regression testing re-checks that new changes did not break existing functionality; it is broader and deeper. Pick smoke cases by criticality — the few flows that must work; pick regression cases by impact analysis — the areas a change could touch, plus historically fragile spots. A small hotfix may need only smoke around the fix.

Bugs come mostly from human factors and process gaps: human mistakes in design and coding, requirements that change mid-project, misunderstood or ambiguous specifications, time pressure that forces shortcuts, poor prioritization of what to test, confusion between software versions, and the sheer complexity of the system. Most defects trace back to communication and requirements, not just typing errors in code.

An error (mistake) is a human action that produces a wrong result — e.g. a developer misreads a requirement. That error introduces a defect (fault) in the code or document. When the defective code runs and behaves wrongly, the result observed in operation is a failure. So the chain is error → defect → failure: human cause, static flaw, runtime effect.

Positive testing feeds valid data and expected scenarios to confirm the system does what it should ("happy path"). Negative testing feeds invalid data, wrong formats, and unexpected actions to confirm the system rejects them gracefully — showing an error when it should and not crashing. Good practice: start positive, then cover negative cases.

The software life cycle spans from the first concept to the moment the product can no longer be used. Typical stages are: idea and requirements, design, implementation, testing, deployment and configuration, operation and support, and eventual retirement. Testing is not a single late phase — it runs across the whole cycle: requirements are reviewed statically, code is checked dynamically, and support keeps verifying fixes in production.

Unit tests verify a single component in isolation. Integration tests check interactions between components. System testing validates the whole integrated product against requirements. Acceptance testing confirms it meets business needs and is ready to ship.

Functional testing checks what the system does against requirements; non-functional checks how well it does it (performance, security, usability). Smoke is a shallow build-acceptance check; sanity is a narrow check of one fix; regression re-verifies existing features after changes.

Verification checks that the product is built according to its specification — "are we building the product right?". Validation checks that the product meets the user's real needs and intended use — "are we building the right product?". Verification compares against requirements/design; validation compares against actual expectations.

A defect flows New → Assigned → Open (in progress) → Fixed → Retest, then Closed if verified. If the fix fails retest it becomes Reopened and re-enters the fix loop. Invalid or duplicate reports are Rejected or marked Duplicate instead of fixed.

Suspension criteria pause testing temporarily when continuing is pointless — a blocking defect, too many bugs, missing access/builds, or changed requirements; testing resumes once the blocker is gone. Exit (completion) criteria end testing for this cycle: planned tests run, coverage and risk are acceptable, and no open blocker/critical defects remain (or time/budget ran out).

SDLC is the overall software lifecycle: requirements, design, development, testing, deployment, maintenance. STLC is the testing-specific lifecycle nested inside it: requirement analysis, test planning, test design, environment setup, execution, and closure. STLC runs in parallel, not after SDLC.

The seven: testing shows the presence of defects (not their absence); exhaustive testing is impossible; early testing saves time and money; defects cluster; the pesticide paradox (repeating the same tests stops finding new defects); testing is context-dependent; and the absence-of-errors fallacy (a bug-free system is still useless if it doesn't meet user needs).

QA is a process-oriented activity that prevents defects by improving the whole development process. QC is product-oriented and detects defects in the built product. Testing is one QC technique — executing the product to find defects.

Do not close it after one failed retry. Re-run the exact steps on the reporter's build, environment, and account, because a defect reaches Closed only through real verification. Re-read the report for missing preconditions, data, or timing, match the reporter's device and network, and scan the logs and crash reports. Close it only once it genuinely will not reproduce.

A good requirement is complete (nothing missing), unambiguous (one interpretation), consistent (no conflict with others), necessary, feasible, and — crucially — testable/verifiable: you can write a check that confirms or refutes it. A requirement you cannot verify is a defective requirement, because no test can ever prove it was met.

Shift-left moves testing earlier in the lifecycle — reviewing requirements, writing unit tests with code, testing each build — so defects are caught when they are cheap to fix. Trade-offs: higher upfront effort, the need for testable design, and pressure on still-unstable early specs.

Shift-right extends testing into production — monitoring, logging, alerting, real-user metrics, and canary or A/B releases — so defects that only surface under real load are caught fast. It complements shift-left, not replaces it: early testing prevents defects, shift-right catches escaped ones and feeds them into the defect lifecycle. The trade-off: it acts on issues real users may already hit.

Testing is the process of checking that a product's real behavior matches its expected behavior. Its purpose is to find defects, reduce risk, and give stakeholders confidence about quality — not to prove the software is bug-free. It spans the whole lifecycle, both static (reviewing docs) and dynamic (running the system).