Testing basics

principles, SDLC, STLC, levels

How do QA, QC and testing differ?

Testing is checking the product: running it, finding defects, comparing with the expected result.
QC (Quality Control) is quality control of the finished product. Testing is its main part. The focus is on the product: find defects.
QA (Quality Assurance) is assuring the quality of the process so that defects don't appear: standards, requirement reviews, retrospectives, process improvements. The focus is on the process: prevent defects.

That is, testing ⊂ QC ⊂ QA.

In an interview: Testing is the search for defects in a product. QC is quality control of the product, and testing is its main part. QA is wider: it is work on the process so that defects don't appear at all, with requirement reviews, standards, process improvements. Testing is part of QC, and QC is part of QA.

Name the 7 testing principles.

Testing shows the presence of defects, not their absence.
Exhaustive testing is impossible, so prioritisation and test design techniques are needed.
Early testing saves time and money: a bug in requirements is cheaper than a bug in production.
Defect clustering: most bugs are concentrated in a few modules.
The pesticide paradox: the same tests stop finding new bugs over time, and they must be updated.
Testing depends on context: banking and a landing page are tested differently.
The absence-of-errors fallacy: a product with no bugs that users don't need is still a failure.

In an interview: Testing shows the presence of defects, not their absence. Exhaustive testing is impossible, so we prioritise. Testing should happen as early as possible. Defects cluster in a few modules. The same tests stop finding bugs over time: the pesticide paradox. Testing depends on context. And a product with no bugs that users don't need is still a failure.

How does verification differ from validation?

Verification is "are we building the product right?": conformance to the specification and requirements. Often static: review of requirements, design, code.

Validation is "are we building the right product?": does it solve the user's real problem. Usually dynamic: testing the working system, UAT.

In an interview: Verification answers whether we are building the product right, that is, whether it matches the specification. Validation answers whether we are building the right product, that is, whether it solves the user's problem. A product can fully match the requirements and still be unneeded.

What are SDLC and STLC?

SDLC is the software development life cycle: requirements → design → development → testing → release → support. Models: Waterfall, the V-model, iterative, Agile.

STLC is the testing life cycle within the SDLC:

Requirements analysis: what to test, what the risks are, questions for the PM.
Planning: strategy, scope, resources, entry and exit criteria.
Test design: test cases, checklists, test data.
Environment setup.
Test execution and defect reports.
Closure: a report, metrics, lessons.

In an interview: SDLC is the life cycle of developing a product from requirements to support. STLC is the testing life cycle inside it: requirements analysis, planning, test design, environment setup, test execution and closure with a report. In a role where QA is responsible for the whole cycle, these are exactly the stages.

What test levels are there?

Unit: individual functions or classes, usually written by developers.
Integration: the interaction of modules or services: API, database, queues.
System: the whole system as one, against the requirements. This is QA's main work.
Acceptance: is the product ready for the business: UAT, alpha and beta.

A related idea is the testing pyramid: many fast unit tests, fewer integration tests, the fewest expensive e2e tests.

In an interview: The levels are unit, integration, system and acceptance testing. Unit is written by developers, integration checks the interaction of components, system checks the whole system against requirements, and acceptance checks readiness for the business. The testing pyramid says there should be more fast low-level tests than expensive end-to-end ones.

How does static testing differ from dynamic testing?

Static is without running code: review of requirements, mockups, test cases, code, static analysis. It finds defects earliest and cheapest.

Dynamic is with running the program: everything we usually call testing.

The job description directly asks to "validate requirements and provide early feedback": this is static testing of requirements, and it is worth mentioning with an example.

In an interview: Static testing is without running the program: review of requirements, design, code. Dynamic is when we run the system and check its behaviour. Static is cheaper, because it finds problems before they are coded: for example, I find a contradiction in the requirements already at grooming.