QA - Miscellaneous

story points

a relative unit of measure used in agile development to estimate the overall effort of a user story, considering its complexity, amount of work, and uncertainty

exploratory testing

a software testing approach where test design, execution, and learning happen simultaneously

Equivalence Partitioning

a black-box testing technique that divides the input data of a software application into partitions, or groups, of data that are expected to be processed in a similar way

Black Box testing

Black-box testing is based off the requirements documents.

Acceptance Test Driven Development (ATDD)

a software development methodology where stakeholders like customers, developers, and testers collaboratively define acceptance tests before development begins

a software development methodology where acceptance tests are created collaboratively by developers, testers, and business stakeholders before coding begins. This process focuses on clarifying requirements and defining what a "successful" outcome looks like from the user's perspective, using the tests as executable specifications. Key benefits include reduced miscommunication, better alignment with business needs, and the creation of software that meets user expectations.  

Root Cause Analysis

a systematic problem-solving method used to identify the fundamental reason behind a problem or event, rather than just addressing its immediate symptom

Exhaustive Testing

a theoretical testing method that aims to test a software system with every possible input combination and execution path.

Traceability

the ability to link test cases to their source artifacts, such as requirements or user stories, and to track them throughout the development lifecycle

Test Manager

responsible for overseeing all testing activities to ensure a software product meets quality standards before release. This role involves creating test strategies, managing and mentoring the testing team, defining and implementing test processes, and communicating results and issues to stakeholders. 

testing

a process of evaluating a software system or its components to determine whether it satisfies specified requirements and to identify any defects, errors, or missing functionalities. It aims to ensure the quality, reliability, and performance of the software before its release and throughout its lifecycle. 

debugging

the process of identifying, analyzing, and resolving errors or "bugs" found within a software program's source code. It is a crucial step that follows the detection of a defect during the software testing phase.

Risk Register

a fundamental tool for implementing a strategy known as risk-based testing (RBT). This approach prioritizes testing efforts and resources by focusing on the areas of the software that are most likely to fail or would have the highest business impact if they

test first approach

a software development methodology where developers write automated tests before writing the actual production code for a feature. This requires developers to first define the desired outcome and specifications for a piece of code by creating a test that will initially fail. Then, they write the minimum amount of code necessary to make the test pass. This method helps clarify requirements, guides design, and ensures that every piece of functionality has an associated test from the beginning. 

confirmation testing

verifies that a bug fix was successful

the process of re-testing a product to verify that a previously identified bug has been successfully fixed and that no new issues have been introduced. It is also used in other contexts to confirm the results of an initial, less precise test. In software, this is also called re-testing and involves running the exact same tests that initially found the bug to ensure it is gone. In toxicology, it involves using a more precise method to confirm the results of an initial screening test. 

regression testing

the process of re-testing a product to verify that a previously identified bug has been successfully fixed and that no new issues have been introduced. It is also used in other contexts to confirm the results of an initial, less precise test. In software, this is also called re-testing and involves running the exact same tests that initially found the bug to ensure it is gone. In toxicology, it involves using a more precise method to confirm the results of an initial screening test. 

retrospective

a regular meeting for a team to reflect on a recent period of work, such as a sprint, to identify what went well, what could be improved, and to brainstorm actionable steps for future sprints

DevOps

a fundamental shift in how quality assurance is integrated into the software development lifecycle. It moves beyond traditional, isolated testing phases to embed quality practices throughout the entire process, from initial development to deployment and operations.

statement testing

a white-box testing technique that creates test cases to ensure every executable statement in a program's source code is run at least once. It's a metric for measuring code coverage, calculated by dividing the number of statements executed by the total number of executable statements in the code. The goal is to identify potential issues by thoroughly checking the internal structure and logic of the software

transition testing

a black-box software testing technique that verifies how a system moves between different states in response to specific events or inputs. It checks that the system's behavior is correct as it changes from one condition to another, ensuring that states and transitions are handled as expected and helps identify defects related to state management

CI/CD

the integration of Quality Assurance (QA) activities, particularly automated testing, into the Continuous Integration and Continuous Delivery/Deployment (CI/CD) pipeline. This integration ensures that software quality is continuously validated throughout the development and release process.

Boundary Value Analysis

a software testing technique that focuses on testing the values at the edges or boundaries of input ranges, such as the minimum, maximum, and values just above or below them. The goal is to find defects that may occur at these boundaries, which are often where errors are more likely to be found. For a range of values from 1 to 100, a BVA would test values like 0, 1, 2, 99, 100, and 101. 

Risk Likelihood

the probability or frequency that a potential defect or failure will occur in a software system. It's a key component of risk-based testing, used along with risk impact to prioritize testing efforts by focusing on the areas that are most likely to have issues and are most critical to the business. 

Risk Impact

the measure of the potential negative consequences if a specific risk or defect occurs, affecting the project's quality, cost, or schedule. It's a critical component of risk management and risk-based testing, where the impact is considered alongside the likelihood of the risk happening to prioritize testing efforts on the most critical areas. 

Experience Based Testing

a QA approach where testers use their intuition, expertise, and knowledge from past projects to find defects. Instead of following rigid test cases, testers dynamically create and execute tests based on their understanding of the system, similar products, and potential failure points. Common techniques include error guessing, exploratory testing, and checklist-based testing. 

Testing Quadrants

a model that organizes testing into four categories based on two dimensions: business-facing vs. technology-facing and supporting the team vs. critiquing the product. It helps teams ensure comprehensive test coverage, moving from automated, technology-focused tests that support development to manual, business-focused tests that critique the final product.

Behavior Driven Development

an Agile software development methodology that focuses on defining application behavior from a user's perspective, using a clear, plain language that all team members can understand. In the context of QA testing, BDD is a collaborative approach that involves developers, testers, and business stakeholders (often called the "Three Amigos") working together from the very beginning of a project.

Formal Test Summary Report

a document that provides a comprehensive overview of all testing activities performed for a specific project, release, or milestone. Created at the end of a testing cycle, its primary purpose is to communicate the final results, status, and overall quality of the software to various stakeholders, such as project managers, developers, and clients. 

Enterprise Resource Planning (ERP) Implementation

the quality assurance process of verifying and validating the functionality, performance, and usability of a new or updated ERP system before it goes live. This is a critical part of the implementation project to ensure the system meets business requirements, prevents costly failures, and smooths the transition by identifying defects, errors, or bugs through various types of testing. 

Configuration Management

the process of systematically managing and controlling changes to the configuration of a system or software throughout its lifecycle, with a specific focus on ensuring the quality and consistency of the testing environment and related artifacts.

Non-Functional testing

assesses a software application's quality attributes like performance, security, and usability, rather than verifying its specific functions. It answers the "how" of an application—how fast it runs, how secure it is, and how easy it is to use—by evaluating criteria like response time, load capacity, and reliability

Confirmation Testing

the process of re-testing a specific bug fix to verify that the defect is gone and the software now works as expected. It involves executing the same test cases, with the same data and environment, that originally exposed the bug to ensure the problem has been successfully resolved. 

Test Objective

a specific, measurable goal for a testing phase that answers "why" the test is being performed. Objectives provide a clear purpose for testing, such as finding defects, verifying that a product meets requirements, and ensuring it is reliable, secure, and performs as expected. They guide the entire testing strategy and help determine if the testing effort has been successful. 

Software Development Life Cycle (SDLC)

a framework that outlines the entire process of building and maintaining software, from planning to deployment and beyond. Quality Assurance is integrated into each phase of the SDLC, rather than being a single step, to ensure a high-quality product by identifying and fixing defects early and verifying that all requirements are met. 

Sequential Development Model

a linear, phase-based approach where each stage must be completed before the next begins, such as the Waterfall model.

Incremental Development Model

a system is built and tested in small, manageable parts or "increments". QA testing is performed on each completed increment, and new features are integrated into the previously tested version. This approach allows for the early release of working software, continuous refinement, and risk reduction by identifying issues in each stage rather than at the end. 

Iterative Development Model

a software development approach where a project is broken into small, repeating cycles (iterations or sprints). Each iteration involves planning, designing, coding, and testing a subset of features, with each cycle building upon the last until the final product is complete. QA plays a crucial role in each cycle, testing the features developed in that iteration to provide feedback for future cycles. 

Shift-Left Approach

a strategy to move testing activities to the earliest possible stages of the software development lifecycle, like requirements and design, rather than waiting until the end

Test Approach

the specific implementation of a test strategy for a particular project, defining how testers will execute their tasks

Dynamic Testing

a software testing method that involves executing the code of an application to validate its behavior in real-time. It checks for defects, security vulnerabilities, and performance issues by running the software with different inputs and observing the results, which can include things like memory and CPU usage. This is in contrast to static testing, which analyzes the code without executing it. 

Decision Table Testing

a black-box testing technique used in Quality Assurance (QA) to systematically test complex business logic where the system's behavior depends on multiple input conditions and their combinations.B

Branch Testing

a white-box software testing technique that focuses on ensuring the thoroughness of test coverage by examining the execution of different branches or decision points within a program's source code. 

absence-of-defects fallacy

the incorrect assumption that a software system is high-quality just because it has no bugs. This is a fallacy because a system can still be unusable and fail to meet user needs even if it is technically defect-free, such as if the requirements were misunderstood or the system is difficult to use.

Coverage Items

an attribute or a combination of attributes derived from a test condition that a test suite must execute to demonstrate its thoroughness. These items are used to measure how well tests cover specific parts of a system, such as requirements, code, or decision outcomes. Examples include statement coverage, branch coverage, or requirement coverage. 

Test Pyramid Model

a model that outlines a balanced strategy for automated software testing by dividing tests into three layers: unit tests at the base, integration tests in the middle, and end-to-end (E2E) tests at the top. The pyramid shape signifies that a larger number of fast, simple unit tests should exist, with progressively fewer integration and end-to-end tests, which are more complex, slower, and costly to maintain. 

Test Implementation

the phase where the previously designed test cases are transformed into executable test procedures or scripts, and the necessary test environment and data are prepared for test execution. It bridges the gap between test design (defining what to test) and test execution (actually running the tests)F

Additional Coverage Prioritization Technique

a strategy where test cases are ordered to maximize code coverage by prioritizing the test that covers the most uncovered statements at each step. This iterative process starts with the test case that covers the most statements, then selects the next test case that adds the most new coverage until all statements are covered. This technique is a form of code-coverage-based test case prioritization. 

The 7 Testing Principles

1. Testing shows the presence of defects, not their absence 

2. Exhaustive testing is impossible 

3. Early testing saves time and money 

4. Defect clustering 

5. Pesticide paradox

6. Testing is context-dependent

7. Absence-of-errors is a fallacy 

Testing shows the presence of defects, not their absence

Testing can prove that defects exist, but it cannot prove that a system is completely defect-free

Exhaustive testing is impossible 

• Testing every single combination of inputs and conditions is not practical for all but the simplest software.

• It is important to use risk-based testing to prioritize the most critical areas. 

Early testing saves time and money 

• Defects found earlier in the development lifecycle, through activities like static testing (e.g., document reviews) and dynamic testing (e.g., unit tests), are less expensive to fix. 

Defect clustering 

• A small number of modules often contain most of the defects.

• This principle suggests that testing efforts should be concentrated on these "hot spots". 

Pesticide paradox

• If the same tests are run repeatedly, they will eventually become less effective at finding new bugs.

• To overcome this, test cases must be reviewed and updated regularly to discover new defects. 

Testing is context-dependent

• The way a system is tested should be adapted based on its specific context, such as the nature of the application or business risks.

• For example, testing an e-commerce site will differ from testing a medical device. 

Absence-of-errors is a fallacy 

• A system that is 99% bug-free may still be unusable if it doesn't meet the user's needs or if the fundamental requirements were wrong.

• Finding and fixing all defects is not enough; the system must also be usable and meet user expectations. 

Data Migration Testing

the process of verifying that data is transferred accurately, completely, and without errors from a source system to a target system

3 Cs Technique

1. Card

2. Conversation

3. Confirmation

Card

• This is the initial user story, typically written on a physical or digital card.

• It contains a concise description of the feature and its value, serving as a reminder for future discussion.

• It is intentionally brief, as the details are not meant to be fully contained on the card itself. 

Conversation

• This is the core of the process where all stakeholders (developers, testers, product owners, etc.) discuss the details of the user story.

• Through dialogue, the team clarifies requirements, asks questions, and builds a shared understanding of what needs to be built.

• This conversation is crucial for refining the story and ensuring everyone is on the same page before development begins. 

Confirmation

• This is the process of agreeing on how to confirm that the story has been successfully completed.

• It involves developing clear acceptance criteria that will be used to verify that the functionality meets the user's needs and the business requirements.

• This step ensures a shared definition of "done" and is often automated using Behavior-Driven Development (BDD) practices. 

Test Execution

the process of systematically running pre-written tests to check if a software application's actual results match the expected results, based on the original requirements. It is a crucial phase of the software testing life cycle where testers execute test cases (both manually and automatically) and document the outcomes, such as passes, failures, or errors

Quadrant 1 (Technology Facing, Supports the Team)

consists of technology-facing, automated tests that support the development team. The main focus is on the internal code quality and verifying the functionality of individual components or code units, such as with unit tests and component tests. 

Quadrant 2 (Business Facing, Supports the Team)

Focuses on business requirements and includes tests that verify the product is being built to meet those needs. Examples include functional tests, story tests, and performance simulations based on acceptance criteria.

Quadrant 3 (Business Facing, Critiques the Product)

This quadrant uses manual and business-facing tests to critique the product from a user's perspective. Examples include usability testing, exploratory testing, and user acceptance testing (UAT).

Quadrant 4 (Technology Facing, Critiques the Product)

This quadrant involves technology-focused tests that critique the product's non-functional aspects. Examples include performance, load, security, and stress tests. 

State Transition Coverage

the extent to which the different states and transitions of a system under test have been exercised during testing. It is a metric used in state transition testing, a black-box test design technique, to ensure comprehensive coverage of the system's behavior as it moves between various states.

product quality metric

a measurable criterion used to assess how well a product meets quality standards and customer expectations. These metrics can track a product's performance, reliability, and customer satisfaction, and include examples like defect rates, scrap rates, customer complaints, and first-pass yield in manufacturing.