Quality Assurance Testing Flashcards

Question 1

What is the difference between quality assurance and quality control?

Accepted Answer

Quality assurance is a process-focused activity that aims to prevent defects by improving how work is planned and performed. Quality control is product-focused and checks outputs against requirements to find defects that already exist. Both support delivering reliable products, but assurance works upstream while control works on the finished or intermediate results.

Question 2

What is a software defect, and how does it differ from a failure?

Accepted Answer

A defect is a flaw in code, design, or documentation that can cause incorrect behavior. A failure is the observable result when a defect is executed and the system deviates from expected behavior. One defect may cause no failure in some scenarios, and one failure may trace back to several defects.

Question 3

What does the phrase shift left mean in software testing?

Accepted Answer

Shift left means moving testing activities earlier in the development lifecycle so that defects are found when they are cheaper and easier to fix. Teams do this by reviewing requirements, writing test cases alongside design, and involving testers in planning discussions. The goal is faster feedback and fewer defects reaching later stages.

Question 4

Why is the cost of fixing a defect usually higher when it is found late?

Accepted Answer

A late defect often requires rework across several artifacts, such as code, design documents, test scripts, and release plans. Each affected item must be revisited, retested, and approved again, which adds time and coordination. Early discovery limits that spread, so the fix is smaller and less disruptive.

Question 5

What is exhaustive testing, and why is it generally impossible?

Accepted Answer

Exhaustive testing means executing every possible combination of inputs and conditions for a system. It is generally impossible for real software because the number of combinations grows far too quickly. Testers therefore use risk, priority, and techniques to select a manageable, representative set of tests that gives adequate confidence.

Question 6

What is the purpose of a quality management plan for a software project?

Accepted Answer

A quality management plan describes how quality will be defined, measured, and controlled on a project. It identifies the standards, roles, review activities, test strategy, entry and exit criteria, and tools to be used. The plan gives the team and stakeholders a shared reference for what success looks like.

Question 7

What is the difference between verification and validation?

Accepted Answer

Verification checks that the product is built correctly, meaning it conforms to its specifications and design documents. Validation checks that the right product is built, meaning it meets the real needs of users and stakeholders. Verification asks whether we built it right, while validation asks whether we built the right thing.

Question 8

Why do teams use entry and exit criteria for test phases?

Accepted Answer

Entry criteria define the conditions that must be met before a test phase can begin, such as a stable build and approved test environment. Exit criteria define the conditions for finishing, such as executed test coverage and no open critical defects. Together they give a clear, objective basis for starting and stopping testing.

Question 9

What are the four common test levels in a typical software project?

Accepted Answer

The common test levels are unit, integration, system, and acceptance testing. Unit testing checks individual components in isolation. Integration testing checks that components work together through their interfaces. System testing checks the complete application against requirements, and acceptance testing confirms it meets business needs for release.

Question 10

What is regression testing, and when should it be performed?

Accepted Answer

Regression testing re-executes existing tests to confirm that previously working functionality still works after a change. It is performed after code changes, bug fixes, configuration updates, or new feature additions. Because changes can affect unrelated areas, regression suites are often automated and run frequently.

Question 11

What is the difference between functional and non-functional testing?

Accepted Answer

Functional testing checks what the system does, verifying features, inputs, outputs, and business rules against requirements. Non-functional testing checks how well the system performs, covering qualities such as performance, security, usability, reliability, and accessibility. Both are needed because a feature can work correctly yet still be too slow or insecure to use.

Question 12

What is smoke testing, and how does it differ from sanity testing?

Accepted Answer

Smoke testing is a shallow, broad check of a new build's critical functions to judge whether it is stable enough for deeper testing. Sanity testing is a narrow check of a specific fix or change to confirm the problem appears resolved. Both are quick, lightweight checks.

Question 13

What is exploratory testing, and when is it most useful?

Accepted Answer

Exploratory testing is an approach where testers simultaneously learn about the product, design tests, and execute them without relying entirely on scripted cases. It is most useful when requirements are incomplete, time is limited, or testers need to uncover unexpected behavior. Findings guide the next steps, and session notes record what was covered.

Question 14

What is black-box testing, and what information does a tester need?

Accepted Answer

Black-box testing evaluates a system based on its inputs and expected outputs, without examining its internal code structure. The tester needs requirements, specifications, user stories, or other descriptions of expected behavior. This approach reflects the user's view and works well for acceptance and system testing.

Question 15

What is white-box testing, and which coverage measures does it commonly use?

Accepted Answer

White-box testing designs tests from the internal structure of code, such as its branches, decisions, and statements. Common coverage measures include statement coverage, branch coverage, and condition coverage, which show how much of the code the tests exercise. High coverage does not guarantee correctness, but gaps reveal untested paths.

Question 16

What is the purpose of user acceptance testing before release?

Accepted Answer

User acceptance testing lets intended users or customer representatives confirm that the system supports their real business tasks. It is usually run with realistic scenarios and data in an environment close to production. A successful result supports the release decision, while failures indicate gaps between the product and stakeholder expectations.

Question 17

What is equivalence partitioning, and why is it useful?

Accepted Answer

Equivalence partitioning divides input data into groups, or partitions, where the system is expected to behave the same way for every value in the group. Testers select one representative value from each partition. This reduces the number of tests needed while still covering each distinct kind of input.

Question 18

What is boundary value analysis, and where do defects often appear?

Accepted Answer

Boundary value analysis tests values at the edges of each partition, including the minimum, maximum, and values just inside and outside those limits. Defects often appear at boundaries due to off-by-one errors, wrong comparison operators, or misread requirements. For a field accepting ages 18 to 65, testers check 17, 18, 65, and 66.

Question 19

What is decision table testing, and when is it appropriate?

Accepted Answer

Decision table testing organizes business rules into a table of conditions and resulting actions, so each combination of conditions becomes a test case. It is appropriate when behavior depends on several interacting conditions, such as discount eligibility or insurance approval rules. The table also helps reveal missing or conflicting rules.

Question 20

How does state transition testing work, and what does it check?

Accepted Answer

State transition testing models a system as a set of states, events that trigger changes, and transitions between states. Test cases cover valid transitions, invalid events in each state, and sequences that lead to important states. It is useful for workflows such as order processing, login lockouts, or device controls.

Question 21

What is pairwise testing, and why does it reduce the number of tests?

Accepted Answer

Pairwise testing selects test cases so that every combination of values for any two parameters appears in at least one test. Full combinations grow rapidly as parameters are added, but many defects are triggered by interactions between only two factors. This approach gives strong coverage with far fewer tests than testing every combination.

Question 22

What is error guessing, and what kind of experience does it rely on?

Accepted Answer

Error guessing is a technique where testers use their knowledge of past defects, common mistakes, and system weaknesses to predict where failures are likely. It relies on experience with similar products, typical developer errors, and known risky areas such as complex calculations or file uploads. It works best alongside systematic techniques.

Question 23

How do testers use risk-based testing to set priorities?

Accepted Answer

Risk-based testing ranks features or components by the likelihood of failure and the impact if they fail. Testers give more time and deeper coverage to high-risk areas, such as payment processing or safety functions, and lighter coverage to low-risk areas. Risk ratings are reviewed as the project changes so priorities stay current.

Question 24

What is the benefit of designing tests from requirements before coding starts?

Accepted Answer

Designing tests early exposes unclear, ambiguous, or missing requirements while they are still cheap to correct. Testers who write expected results first can spot contradictions and incomplete acceptance criteria. Early test design also gives developers a concrete target and helps plan automation and environments before delivery.

Question 25

What information should a good defect report contain?

Accepted Answer

A good defect report includes a unique identifier, a clear summary, the environment and build version, and exact steps to reproduce the problem. It also states the expected result, the actual result, the severity, and any supporting evidence such as logs or screenshots. Clear reports help developers reproduce and fix issues quickly.

Question 26

What is the difference between defect severity and defect priority?

Accepted Answer

Severity describes how seriously a defect affects the system, such as causing data loss, a crash, or only a cosmetic issue. Priority describes how urgently the defect should be fixed, based on business needs and release timing. A defect can be high severity but low priority, or low severity but high priority.

Question 27

What is the defect life cycle, and what are its typical stages?

Accepted Answer

The defect life cycle is the path a defect follows from discovery to closure. Typical stages include new or open, assigned, in progress, fixed or resolved, verified by retesting, and closed. Some workflows also include reopened or rejected states when a fix fails or the report is not valid.

Question 28

What is root cause analysis, and why is it valuable for quality?

Accepted Answer

Root cause analysis is a structured investigation that identifies the underlying reason a defect occurred, rather than only the symptom. Common methods include asking why repeatedly or drawing cause-and-effect diagrams. It is valuable because fixing the root cause can prevent whole classes of similar defects in the future.

Question 29

What is defect leakage, and how is it used as a measure?

Accepted Answer

Defect leakage is the number of defects that escape a test phase and are found later, often in production by users. It can be expressed as a percentage of all defects found, comparing defects found in one phase against those found afterward. Rising leakage suggests that test coverage or test design needs improvement.

Question 30

What is a defect density metric, and what does it help teams compare?

Accepted Answer

Defect density is the number of confirmed defects divided by a size measure, such as thousands of lines of code or function points. It helps teams compare quality across modules, releases, or projects of different sizes. Because size definitions vary, density should be interpreted carefully alongside context and trends.

Question 31

Why is it important to avoid duplicate defect reports?

Accepted Answer

Duplicate reports waste triage and development time, because several people investigate the same problem without knowing it is already tracked. They also distort defect counts and metrics, making quality look worse or better than it is. Testers should search existing reports before filing and link any duplicates to the original.

Question 32

What is a known issue, and how should it be communicated to stakeholders?

Accepted Answer

A known issue is a defect that has been confirmed but not fixed in the current release, often because a workaround exists or the risk is accepted. It should be communicated with a clear description, its impact, any workaround, and the planned fix or decision. Transparent reporting lets support teams and customers prepare.

Question 33

What are the main phases of a typical test process?

Accepted Answer

A typical test process includes planning, analysis and design, implementation, execution, and completion. Planning defines scope, resources, and schedule. Analysis and design turn requirements into test conditions and cases, while implementation prepares data and environments. Execution records results, and completion evaluates the outcome and captures lessons learned.

Question 34

What is a test metric, and what makes a good one?

Accepted Answer

A test metric is a measured value that describes some aspect of testing progress, coverage, or quality. A good metric is clearly defined, easy to collect consistently, and tied to a decision someone will make. Metrics become misleading when teams treat a single number as the whole picture of quality.

Question 35

What is the difference between a test case and a test script?

Accepted Answer

A test case describes what to test, including preconditions, inputs, steps, and expected results, independent of how it is executed. A test script gives the detailed, executable instructions for carrying out a test case, often in a scripting language or step-by-step manual form. One test case may have manual or automated scripts.

Question 36

What is test automation, and which kinds of tests are good candidates?

Accepted Answer

Test automation uses scripts and tools to run tests, compare actual results with expected results, and report outcomes without manual effort. Good candidates include stable, repeatable, high-value tests such as regression suites, smoke tests, and data-driven checks. Exploratory and usability testing usually remain manual because they depend on human judgment.

Question 37

Why can test automation fail to deliver value, and how can teams avoid that?

Accepted Answer

Automation often fails when teams automate unstable features, write brittle scripts tied to screen layouts, or neglect maintenance as the product changes. Teams can avoid this by choosing stable, valuable tests, designing scripts that are easy to update, and reviewing failures regularly. Automation supports testing but does not replace thoughtful test design.

Question 38

What is continuous integration, and how does testing fit into it?

Accepted Answer

Continuous integration is a practice in which developers merge code changes frequently into a shared branch, and each change triggers an automated build and test run. Testing fits in as fast automated checks, such as unit and regression tests, for quick feedback. Failing checks signal the team to fix problems before they accumulate.

Question 39

What is the purpose of a test summary report at the end of a test cycle?

Accepted Answer

A test summary report communicates what was tested, what was found, and whether the exit criteria were met. It typically includes execution totals, pass and fail counts, open defects by severity, risks, and a recommendation about readiness. It gives stakeholders the evidence they need to make an informed release decision.

Question 40

How does a team decide when testing is complete enough to release?

Accepted Answer

Teams usually decide by checking exit criteria, such as planned tests executed, critical and high defects resolved or accepted, and coverage targets met. They also weigh residual risk, the results of recent regression runs, and stakeholder judgment. Testing is never proven complete in an absolute sense, so the decision is a reasoned judgment.

Quality Assurance Testing Flashcards

1Foundations of Quality Assurance

2Test Levels and Test Types

3Test Design Techniques

4Defects and Defect Management

5Test Process, Metrics, and Automation

Learning Resources