ISTQB Agile Term | Description |
| Acceptance criteria | Specific conditions that a product or feature must meet to be considered complete and satisfactory to the customer. |
| Acceptance test automation | The use of automated tools and software to perform acceptance testing. |
| Acceptance test-driven development (ATDD) | An agile approach where the acceptance criteria are defined before the development begins and are used as a basis for creating automated tests. |
| Acceptance testing | Testing conducted to determine if a system or product meets the acceptance criteria and is ready for delivery. |
| Agile | A software development methodology that emphasizes collaboration, flexibility, and rapid iteration. |
| Agile coach | An experienced professional who helps teams and organizations adopt and implement agile practices. |
| Agile contracting | A flexible approach to creating contracts that allows for changes in project scope and requirements during the development process. |
| Agile development methods | A set of iterative and incremental software development approaches that prioritize flexibility, customer collaboration, and response to change. |
| Agile documentation | A lightweight documentation approach that emphasizes capturing just enough information to support development and communication needs, rather than exhaustive documentation. |
| Agile estimation | The process of predicting the effort, time, and cost required for software development tasks within an agile environment. |
| Agile estimation techniques | A variety of techniques used to estimate software development tasks within an agile environment, including planning poker, wideband Delphi, and affinity mapping. |
| Agile frameworks | Prescribed sets of practices, roles, and artifacts intended to guide and support the implementation of agile development methods, such as Scrum, Kanban, and XP. |
| Agile manifesto | A set of guiding values and principles for agile software development, emphasizing customer collaboration, working software, and flexibility. |
| Agile manifesto and principles | The Agile Manifesto consists of four values and 12 principles that serve as the foundation for agile development methods, including customer satisfaction, frequent delivery of working software, and continuous improvement. |
| Agile mindset | A way of thinking that values individuals and interactions, customer collaboration, responding to change, and working software as the primary measure of progress. It emphasizes flexibility, adaptation, and continuous improvement. |
| Agile modeling | An approach to software development that focuses on creating and maintaining models and documentation that are just enough and just in time. It values communication, simplicity, and feedback, and it embraces change as a natural part of the process. |
| Agile principles | A set of 12 guiding values and beliefs for software development that prioritize customer satisfaction, working software, and collaboration among self-organizing teams. They emphasize flexibility, adaptability, and continuous improvement. |
| Agile product owner | The person responsible for defining and prioritizing the product backlog, collaborating with stakeholders to understand their needs, and ensuring that the team delivers value to the customer. The product owner is the primary interface between the development team and the business. |
| Agile project management | An iterative and incremental approach to managing projects that emphasizes flexibility, adaptation, and continuous improvement. It values customer collaboration, working software, and self-organizing teams, and it uses feedback to guide decision-making. |
| Agile project metrics and KPIs | Measures and indicators used to track progress, evaluate performance, and improve outcomes in an Agile project. They focus on delivering value to the customer, improving quality, and increasing efficiency, and they are often based on collaboration, communication, and feedback. |
| Agile requirements | An approach to defining and managing requirements in an Agile project that values collaboration, communication, and flexibility. It emphasizes user stories, acceptance criteria, and prioritization, and it uses feedback to adapt to changing requirements and customer needs. |
| Agile requirements management | Agile requirements management refers to the process of managing the requirements for software development in an Agile environment. This involves collaborating with stakeholders, breaking down requirements into smaller pieces, prioritizing them based on business value, and continuously refining and updating them throughout the development process. The goal is to ensure that the requirements are aligned with the business needs and are flexible enough to accommodate changes in the project scope or requirements. |
| Agile retrospectives | Agile retrospectives are periodic meetings held by Agile teams to reflect on their processes, identify areas of improvement, and develop action plans to address them. These meetings are typically held at the end of each iteration or sprint and involve all members of the team. The goal is to continuously improve the team’s performance, productivity, and effectiveness by identifying and addressing issues and finding ways to work more efficiently and collaboratively. |
| Agile software development | Agile software development is an iterative and incremental approach to software development that emphasizes collaboration, flexibility, and customer satisfaction. It involves breaking down the development process into small, manageable chunks called iterations or sprints, each of which involves planning, designing, building, testing, and delivering a working piece of software. The goal is to deliver high-quality software that meets the customer’s needs and is adaptable to changing requirements and priorities. |
| Agile software testing techniques | Agile software testing techniques are testing methodologies and practices that are tailored to Agile development processes. They include practices such as continuous integration, automated testing, exploratory testing, and test-driven development. The goal is to ensure that software is thoroughly tested and that defects are identified and addressed as early as possible in the development process. This helps to reduce the risk of defects being introduced into the production environment and to improve the overall quality of the software. |
| Agile team dynamics | Agile team dynamics refer to the interpersonal relationships and interactions between members of an Agile team. These dynamics are critical to the success of an Agile project, as they can impact communication, collaboration, motivation, and productivity. Effective Agile teams have a culture of trust, transparency, and openness, where members feel comfortable expressing their opinions and ideas, sharing knowledge and skills, and working collaboratively to achieve shared goals. |
| Agile team roles and responsibilities | Agile team roles and responsibilities are defined roles and responsibilities within an Agile team that help to ensure the success of an Agile project. These roles typically include a product owner, a Scrum master, and development team members. The product owner is responsible for defining and prioritizing the product backlog, while the Scrum master is responsible for facilitating the Scrum process and ensuring that the team is following Agile practices. Development team members are responsible for designing, building, testing, and delivering working software. The goal is to ensure that each member of the team has a clear understanding of their role and responsibilities and is working effectively to achieve project goals. |
| Agile testing | Agile testing is the practice of testing software in an Agile environment, where software development is done iteratively and incrementally. Agile testing is focused on ensuring that software is tested continuously throughout the development process, using practices such as automated testing, exploratory testing, and test-driven development. The goal is to ensure that software is thoroughly tested and that defects are identified and addressed as early as possible in the development process. This helps to reduce the risk of defects being introduced into the production environment and to improve the overall quality of the software. |
| Agile testing and development process | Agile testing and development process is an iterative approach to software development that emphasizes flexibility, collaboration, and customer satisfaction. It involves continuous testing and feedback to ensure that the software meets the changing requirements of the customer. |
| Agile testing approaches | Agile testing approaches refer to the various testing techniques used in Agile methodology, such as Test-driven development (TDD), Behavior-driven development (BDD), Acceptance Test-driven development (ATDD), and Exploratory testing. |
| Agile testing automation | Agile testing automation is the process of automating testing tasks in an Agile environment. It involves using tools and frameworks to write and execute automated tests, allowing teams to perform tests quickly and efficiently. |
| Agile testing challenges and strategies | Agile testing presents several challenges, such as managing changing requirements, maintaining quality, and ensuring timely delivery. Agile testing strategies include continuous testing, collaboration, and early feedback to address these challenges. |
| Agile testing for distributed teams | Agile testing for distributed teams involves using communication and collaboration tools to ensure that testing activities are aligned with the development team’s objectives. It involves maintaining clear communication channels and using agile testing methodologies that facilitate remote testing. |
| Agile testing for non-functional requirements | Agile testing for non-functional requirements involves testing software for performance, scalability, security, and other non-functional requirements. It involves using automated testing tools and techniques to ensure that the software meets these requirements. |
| Agile testing metrics and measurements | Agile testing metrics and measurements are used to track the progress of testing activities in an Agile environment. Metrics such as test coverage, defect density, and velocity can provide insights into the effectiveness of testing activities and help teams identify areas for improvement. |
| Agile testing mindset | A way of thinking in which testing is viewed as an integral part of the Agile development process, with a focus on continuous testing and quality improvement. |
| Agile testing process | A set of testing activities that are aligned with Agile principles and values, including iterative development, continuous integration, and feedback loops. |
| Agile testing quadrants | A model that categorizes testing activities into four quadrants based on the purpose and type of testing, with a focus on both functional and non-functional aspects. |
| Agile testing quality | The level of excellence in the testing process that enables the Agile team to deliver high-quality products that meet customer requirements and expectations. |
| Agile testing strategies | The approaches, plans, and techniques used by the Agile team to manage testing activities, including test automation, exploratory testing, and risk-based testing. |
| Agile testing strategies and techniques | The specific methods and tools used by the Agile team to design, execute, and evaluate tests, including acceptance testing, behavior-driven development, and test-driven development. |
| Agile testing tools | Tools used to support the testing activities in an Agile development process, such as test management or CI/CD tools. |
| Agile transformation | The process of transitioning an organization from traditional development methodologies to Agile methodologies. |
| Automated acceptance tests | Tests that are automatically executed to validate whether the system meets the acceptance criteria specified by the customer or product owner. |
| Backlog | A list of features, enhancements, and bugs that need to be developed, maintained and tested in an Agile development process. |
| Backlog grooming | The activity of refining the backlog items to make them ready for implementation and testing. |
| Backlog refinement session | A collaborative meeting in which the development team and the product owner discuss and refine the backlog items. |
| Behavior-driven development | A software development methodology that uses a shared language between stakeholders to describe and verify the system’s behavior. |
| Behavior-driven testing | A testing approach that uses a shared language and automated tests to validate the system’s behavior. |
| Burn-down chart | A graphical representation of the remaining work in a sprint or iteration. It shows the amount of work remaining on the y-axis and time on the x-axis. The chart is used to track progress and identify potential issues in completing the work within the iteration. |
| Code coverage | A measure of how much of the source code is executed during automated testing. It helps to ensure that the tests are comprehensive and that there are no untested areas of the code. |
| Code refactoring | The process of restructuring the code without changing its external behavior. It is done to improve the code’s quality, maintainability, and readability. |
| Collaborative games | Interactive games that are used to promote collaboration, communication, and teamwork among Agile team members. They are often used during Agile ceremonies such as sprint planning or retrospective. |
| Continuous delivery | A software development practice where code changes are automatically built, tested, and prepared for release to production. |
| Continuous delivery and deployment pipelines | A set of automated processes that are used to build, test, and deploy code changes to production environments. |
| Continuous deployment | A software development practice where code changes are automatically released to production as soon as they pass automated tests. |
| Continuous deployment pipeline | A set of automated processes that are used to build, test, and deploy code changes to production environments automatically and continuously. |
| Continuous feedback | A process of providing feedback continuously throughout the development cycle to ensure that the team is building the product as per the customer’s requirements. It is a vital part of Agile methodologies that helps to improve the product quality and customer satisfaction. |
| Continuous feedback loops | Continuous feedback loops refer to the feedback mechanisms used in Agile development that ensure that feedback is delivered throughout the development process, enabling the team to make changes and adjustments as they go. It helps to identify and fix issues quickly, ensuring that the project stays on track and meets the customer’s needs. |
| Continuous improvement | The process of continually improving the product and the development process over time. It is an Agile principle that focuses on delivering value to the customer and improving the team’s performance. Continuous improvement involves making small, incremental changes to the process and product to deliver better results. |
| Continuous improvement through retrospectives | Retrospectives are meetings held at the end of each iteration or sprint, where the team reflects on the previous iteration’s work and discusses what went well, what didn’t, and how they can improve. It is a process of continuous improvement that helps to identify areas for improvement and take corrective actions. |
| Continuous integration (CI) | Continuous integration (CI) is a practice of merging all the developers’ code changes into a central repository frequently. It involves running automated tests and builds to identify and fix issues as soon as possible. Continuous integration is essential for ensuring that the codebase is always in a working state and ready for release. |
| Continuous integration and deployment | Continuous integration and deployment (CI/CD) is a practice of continuously integrating code changes, running automated tests and builds, and deploying the changes to production automatically. It is a critical component of Agile development that enables the team to deliver features quickly, reliably, and with high quality. |
| Continuous testing and integration | This refers to the practice of testing and integrating code continuously throughout the development cycle, rather than waiting until the end. This ensures that any issues are caught and resolved early on, reducing the risk of delays and errors in the final product. |
| Continuous testing culture | A culture in which testing is an integral part of the development process, and all team members are responsible for ensuring that quality standards are met. This involves creating an environment in which testing is seen as a collaborative effort, and everyone is encouraged to contribute to the testing process. |
| Cross-functional team | A team that consists of members with diverse skill sets and areas of expertise, who work together to achieve a common goal. In an Agile context, this often means that the team includes developers, testers, designers, and other specialists, all working together to deliver a high-quality product. |
| Customer collaboration | A practice in which the development team works closely with the customer or end user to ensure that the product meets their needs and requirements. This involves regular communication and feedback, and a willingness to make changes based on user input. |
| Daily stand-up meeting | A brief daily meeting in which team members gather to discuss progress, plans, and any issues or challenges they are facing. The purpose of the meeting is to ensure that everyone is on the same page and that any issues are addressed quickly. |
| Definition of done (DoD) | A shared understanding among the team of what constitutes a completed user story or task. This ensures that everyone is working towards the same goal and that the product meets the necessary quality standards. |
| Definition of ready (DoR) | A shared understanding among the team of what constitutes a user story that is ready to be worked on. This includes things like a clear description, acceptance criteria, and any necessary design or architecture work. |
| Definition of ready (DoR) for user stories | A shared understanding among the team of what constitutes a user story that is ready to be pulled into a sprint. This includes things like a clear description, acceptance criteria, and any necessary design or architecture work, as well as any dependencies that need to be resolved. |
| DevOps | DevOps is a software development approach that combines development and operations teams to increase efficiency and productivity. |
| DevOps culture | DevOps culture is a collaborative, iterative and continuous approach to software development that fosters teamwork and communication. |
| DevOps in Agile | DevOps in Agile is an extension of Agile methodology that includes DevOps practices, such as continuous integration and deployment. |
| DevOps pipeline | DevOps pipeline is a set of tools and processes that enable the automated building, testing and deployment of software applications. |
| Empirical process control | Empirical process control is an Agile project management approach that involves making decisions based on actual data and progress. |
| Enabling requirements | Enabling requirements are the features and capabilities that are necessary for a system or application to work as intended. |
| Epics | Epics are large user stories or projects that are broken down into smaller, more manageable pieces called user stories. |
| Example mapping | A technique used in Agile to elicit and refine requirements through a collaborative process that involves stakeholders, developers, and testers. It involves creating examples of how the system should behave and using those examples to drive development and testing. |
| Exploratory testing | A type of testing that emphasizes learning about the system, its behavior, and its risks through experimentation, investigation, and ad-hoc testing. It involves simultaneous test design, execution, and learning, and can be used in any phase of the testing cycle. |
| Exploratory testing charter | A document that outlines the goals, scope, and approach of an exploratory testing session. It includes information such as the features or areas to be tested, the types of testing to be performed, and the timebox or duration of the session. |
| Exploratory testing cycle | A series of exploratory testing sessions that are planned, executed, and evaluated over the course of the project. The cycle may include multiple sessions that focus on different areas or aspects of the system, and the results of each session inform the planning of subsequent sessions. |
| Exploratory testing in Agile | A testing approach that is well-suited to the iterative and collaborative nature of Agile development. It emphasizes rapid feedback, continuous learning, and a willingness to adapt to changing requirements and conditions. |
| Exploratory testing session | A period of time during which one or more testers perform exploratory testing on a specific aspect or feature of the system. The session may be guided by an exploratory testing charter, and the results of the session are documented and used to inform subsequent testing. |
| Extreme Programming (XP) | An Agile software development methodology that emphasizes collaboration, simplicity, and customer satisfaction. XP includes practices such as test-driven development, pair programming, continuous integration, and frequent releases, and places a strong emphasis on code quality and customer feedback. |
| Facilitation techniques for Agile meetings | Facilitation techniques are methods used to guide and structure Agile meetings to ensure that they are productive and effective. These techniques help to keep the meeting focused and on track, and encourage active participation and collaboration among team members. Examples include visual aids, brainstorming, and timeboxing. |
| Feature slicing | Feature slicing is a technique used in Agile development to break down large features or user stories into smaller, more manageable pieces that can be completed in a shorter time frame. This enables the team to deliver value to the customer more frequently, and also helps to reduce the risk of project delays or failure. |
| Feature teams | Feature teams are cross-functional teams that are responsible for delivering a specific feature or set of features within an Agile project. These teams are typically composed of developers, testers, designers, and other specialists, and work closely together to ensure that the feature is delivered on time and to a high standard. |
| Feature-driven development (FDD) | Feature-driven development (FDD) is an Agile software development methodology that focuses on delivering working software in small, frequent releases. FDD emphasizes the importance of a strong project management structure, and includes a number of specific practices, such as feature teams, regular progress reporting, and code ownership. |
| Feedback-driven development | Feedback-driven development is an Agile development approach that emphasizes the importance of gathering and incorporating feedback from stakeholders throughout the development process. This feedback can come from a variety of sources, including customers, end-users, and team members, and is used to refine and improve the product as it is being developed. |
| Frequent releases | Frequent releases are a key feature of Agile development, and involve delivering working software to the customer on a regular basis, typically every few weeks or months. This enables the customer to see progress and provide feedback throughout the development process, and also helps to ensure that the project stays on track and meets its goals. |
| Hardening sprint | A sprint in Agile development that is dedicated to resolving technical debt, stabilizing the system, and preparing for the final release. |
| Impact mapping | A technique in Agile development that helps identify the impact of a feature or project by creating a visual map of goals, actors, and impacts. |
| Impact-driven testing | A testing approach in Agile development that focuses on testing the features or areas of the system that are most critical to business goals. |
| In-sprint testing | Testing performed within an iteration or sprint in Agile development, often automated and continuously integrated into the development process. |
| Incremental delivery | A strategy in Agile development where the product is released to the customer in small, incremental chunks, allowing for early feedback and testing. |
| Incremental development | An approach in Agile development where the product is built incrementally, adding new features and functionality in small iterations to deliver value faster. |
| Incremental testing | A testing approach in which small and incremental changes are made to the software system, and each change is tested before the next one is made. |
| Incremental testing strategies | Approaches used to implement incremental testing, such as top-down or bottom-up testing. |
| Information radiators | Visual displays that convey information in a way that is easily understood by team members and stakeholders, such as burndown charts or Kanban boards. |
| Integration testing | A testing phase that focuses on testing how the various components or modules of a software system work together. |
| Iterative development | A software development approach in which small and incremental changes are made to the system through repeated cycles of planning, development, and testing. |
| Iterative testing | A testing approach that involves continuously testing and refining the software system in small and incremental steps. |
| Just-in-time (JIT) development | A development approach that emphasizes delivering features just in time to meet the changing needs of customers and stakeholders. |
| Kaizen | Kaizen is a Japanese word that means “continuous improvement.” In an Agile context, it refers to the practice of continuously improving processes and workflows to achieve greater efficiency and effectiveness. |
| Kanban | Kanban is a visual process management system that helps teams to improve workflow and increase efficiency. It is commonly used in Agile software development to visualize and manage work items. |
| Kanban board | A Kanban board is a visual tool used to manage the flow of work in an Agile project. It typically consists of a board with columns representing the stages of the project and cards representing individual tasks. |
| Kanban boards and workflows | Kanban boards and workflows refer to the visual management system used in Kanban methodology to monitor and manage the flow of work, from the initial request for work to its completion. It helps to identify bottlenecks and manage the work-in-progress. |
| Lean concepts and principles | Lean concepts and principles are derived from the Lean manufacturing philosophy developed by Toyota. They are a set of principles that focus on maximizing customer value while minimizing waste. In an Agile context, they provide guidance on how to create efficient and effective software development processes. |
| Lean portfolio management | Lean portfolio management is an Agile approach to portfolio management that focuses on creating and managing a portfolio of products and services that deliver value to the customer. It uses Lean principles to prioritize and manage the portfolio based on the business goals and customer needs. |
| Lean software development | Lean software development is an Agile methodology that focuses on delivering high-quality software products by minimizing waste and maximizing value. It uses Lean principles to guide the software development process and emphasizes continuous improvement and customer feedback. |
| Lean-Agile | A software development methodology that combines principles of Lean manufacturing and Agile development. It focuses on delivering value to the customer in the most efficient way possible, while being adaptable to change and continuously improving processes. |
| Lean-agile principles | A set of guiding values and principles that underpin the Lean-Agile methodology. These include prioritizing customer value, embracing change, delivering working software frequently, collaborating with customers and within teams, and continuously improving processes. |
| Minimum marketable feature | The smallest set of functionalities that can be released to the market and provide value to the customer. It is a key concept in Agile development, as it allows teams to deliver value early and frequently, and to get feedback from customers to guide further development. |
| Minimum viable experiment | A small-scale experiment designed to test a hypothesis or validate a product concept. It involves creating a minimal version of the product or feature, and testing it with a small group of users to gather feedback and validate assumptions. It is a key concept in Lean Startup methodology. |
| Minimum viable product | The smallest set of features that can be released to the market and provide value to the customer. It is a key concept in Lean Startup methodology, and it focuses on getting a product to market quickly to validate assumptions, gather feedback, and guide further development. |
| Mob programming | A software development practice where a group of developers work together on a single computer or workstation. It is intended to improve collaboration, knowledge sharing, and team productivity, as well as to reduce defects and improve code quality. |
| Non-functional requirements in Agile | Non-functional requirements in Agile refer to the characteristics of a software system that are not related to its behavior, but are equally important, such as performance, usability, security, and scalability. |
| Non-functional testing | Non-functional testing is a type of software testing that focuses on testing the non-functional requirements of a software system, such as performance, reliability, and usability. |
| Pair development | Pair development is a collaborative development approach in which two developers work together on a task, sharing a computer and working on the same code. |
| Pair programming | Pair programming is a software development technique in which two developers work together at a single computer, sharing one keyboard and one mouse, to code, test, and design software. |
| Pair programming in Agile | Pair programming in Agile is a software development practice in which two developers work together to write code, with the aim of producing higher quality code, reducing errors, and sharing knowledge. |
| Pair testing in Agile | Pair testing in Agile is a collaborative testing approach in which two testers work together to test a software system, sharing knowledge and skills, and improving the quality of the testing effort. |
| Planning poker | A collaborative estimation technique used in Agile development to estimate the relative size or effort required to complete a particular task or feature. Team members participate by assigning numerical values to each item being estimated, and then discussing their rationale and assumptions behind the values assigned. |
| Planning poker for Agile estimation | A technique used to estimate the effort required to complete a particular task or feature in an Agile development environment. It is a variation of the traditional Planning Poker technique, but with a focus on Agile principles such as iterative development and continuous feedback. |
| Potentially shippable product increment | An Agile development concept that refers to a completed subset of product functionality that is of sufficient quality to be potentially released to users or customers. The goal is to deliver value to stakeholders with each increment, and to continuously improve the product with each subsequent increment. |
| Product backlog | A prioritized list of product features, enhancements, and defects that the development team maintains for an Agile development project. It serves as a central repository of requirements that are continually refined and reprioritized throughout the project. |
| Product increments | Iterative releases of the product that provide additional functionality and value to the end-users or customers. Each increment builds on the previous one, and is designed to be potentially shippable. |
| Product owner | A key member of the Agile development team responsible for defining and prioritizing the product backlog items. The product owner is typically the primary interface between the development team and stakeholders, and has the authority to make decisions on behalf of the stakeholders. |
| Product roadmap | A high-level visual representation of the product vision and the planned features and enhancements that the development team intends to deliver over time. It serves as a strategic guide for the team to align their efforts towards a common goal. |
| Quality characteristics and testing in Agile | Quality characteristics refer to the attributes of a software product that contribute to its overall quality. Testing in Agile involves continuous testing throughout the development lifecycle to ensure that the product meets the desired quality standards. |
| Refactoring | Refactoring is the process of improving the internal structure of code without changing its external behavior. It aims to improve code readability, maintainability, and scalability while reducing technical debt. |
| Refactoring tests | Refactoring tests involve modifying existing tests to ensure that they continue to provide accurate results after refactoring the code. This helps to ensure that code changes do not introduce new defects or issues. |
| Refinement | Refinement is the process of continuously reviewing and updating the product backlog to ensure that it is up-to-date, well-defined, and prioritized. This helps to ensure that the team is working on the most valuable and relevant items at all times. |
| Regression testing | Regression testing involves retesting previously tested functionality to ensure that it continues to work as expected after code changes, new features, or bug fixes. It helps to ensure that changes do not introduce new defects or impact existing functionality. |
| Release planning | Release planning involves identifying the features, functionality, and scope of a release and determining the timeline, resources, and priorities needed to achieve it. It helps to ensure that the team is aligned and focused on delivering a valuable product increment. |
| Retrospective | Retrospective is a meeting held at the end of an iteration or sprint where the team reflects on their performance and identifies areas for improvement. It helps to foster a continuous improvement culture and promotes learning and growth within the team. |
| Retrospectives | An Agile practice where the team reflects on the previous iteration to identify areas for improvement. |
| Risk-based testing | A testing approach that prioritizes testing efforts based on the likelihood and impact of risks. |
| Risk-based testing in Agile | Incorporating risk-based testing practices into the Agile methodology to prioritize testing efforts based on risks. |
| Scrum | An Agile framework that emphasizes iterative and incremental development, teamwork, and collaboration. |
| Scrum ceremonies and events | Pre-defined time-boxed events in the Scrum framework, including sprint planning, daily standups, sprint reviews, and sprint retrospectives. |
| Scrum framework | A framework for Agile software development that consists of roles, events, artifacts, and rules. |
| Scrum master | A Scrum Master is a facilitator and servant-leader for the Scrum Team, responsible for ensuring the team adheres to Scrum principles. |
| Scrum of Scrums | A Scrum of Scrums is a meeting that brings together multiple Scrum teams to coordinate their work and identify and resolve dependencies. |
| Scrum roles and responsibilities | Scrum defines three roles: Product Owner, Scrum Master, and Development Team. Each role has specific responsibilities within the Scrum framework. |
| Shippable product increment | A shippable product increment is a usable and potentially releasable version of the product that has been completed during a sprint. |
| Specification by example | Specification by Example is a technique for defining requirements and validating them by using concrete examples. |
| Sprint | A sprint is a time-boxed period (usually 1-4 weeks) during which the Scrum team completes a set of product backlog items and creates a shippable product increment. |
| Sprint backlog | A prioritized list of items or user stories that the development team plans to complete during the upcoming sprint. It is created during Sprint Planning and is owned by the development team. |
| Sprint backlog and task boards | A physical or digital board that displays the tasks that need to be completed to achieve the Sprint Goal. It is used to monitor progress during the sprint and ensure the team stays on track. |
| Sprint goal | A short statement that describes the objective of the sprint and what the development team plans to achieve by the end of the sprint. It provides a clear direction for the team to work towards. |
| Sprint planning | A meeting where the development team plans the work they will undertake during the upcoming sprint. The team discusses the sprint backlog, creates a plan to achieve the sprint goal, and estimates the effort required to complete each item. |
| Sprint retrospective | A meeting held at the end of each sprint where the development team reflects on the sprint and identifies what went well and what could be improved. The team uses this information to identify areas for improvement and adjust their processes for the next sprint. |
| Sprint retrospective and continuous improvement | The practice of regularly reflecting on the team’s processes and making adjustments to improve efficiency and productivity. It involves conducting regular sprint retrospectives and using the feedback obtained to make continuous improvements to the development process. |
| Sprint review | A meeting held at the end of a sprint in Agile methodology, where the team demonstrates the work they have completed. |
| Story mapping | A technique used in Agile development to help teams visualise the user’s journey and plan the development of features. |
| Story point | A unit of measure for expressing the overall size or effort required to develop a user story in Agile methodology. |
| Story points for Agile estimation | A technique for estimating the amount of work required to complete a user story using story points. |
| System testing | A type of testing conducted on a complete and integrated system to evaluate its compliance with its specified requirements. |
| Test automation engineer | A professional responsible for developing and implementing automation scripts and tools to support software testing. |
| Test automation framework | A set of guidelines, standards, and best practices that provide a structured way of developing and maintaining automated tests. It includes tools, libraries, and reusable components that help testers to create, execute, and manage automated tests efficiently. A good test automation framework helps in reducing test maintenance effort, improving test coverage, and increasing test reliability. |
| Test automation metrics | A set of quantitative measurements that help in evaluating the effectiveness, efficiency, and coverage of automated tests. Test automation metrics can be used to track the progress of automated testing, identify bottlenecks, and improve the quality of test automation. Some common test automation metrics are test execution time, test failure rate, test coverage, and code coverage. |
| Test automation pyramid | A testing strategy that suggests dividing automated tests into three layers or levels, based on their scope and purpose. The layers are: unit tests, service/API tests, and UI tests. The idea behind the test automation pyramid is to have a majority of tests at the unit level, followed by a smaller number of tests at the service/API level, and the smallest number of tests at the UI level. This approach helps in reducing the overall cost of test automation and increasing its efficiency and reliability. |
| Test automation pyramid in Agile | A variant of the test automation pyramid that is adapted for Agile development methodologies. In this approach, the emphasis is on developing and executing tests that provide fast feedback and support continuous integration and delivery. The layers of the test automation pyramid in Agile are: unit tests, integration tests, API tests, and UI tests. The main goal is to have a balanced mix of tests at each layer, with an emphasis on testing the most critical and high-risk functionality. |
| Test automation script | A set of instructions or code that is used to automate a specific test case or scenario. Test automation scripts can be created using programming languages, testing frameworks, or record-and-playback tools. A good test automation script is easy to read, maintain, and extend, and provides clear and actionable test results. |
| Test automation strategies in Agile | A set of guidelines, principles, and best practices that help in planning, designing, and implementing test automation in Agile development methodologies. Some key strategies for test automation in Agile are: starting early, automating regression tests, using the test automation pyramid, integrating testing with continuous integration and delivery, and focusing on critical and high-risk functionality. The goal is to create a test automation strategy that is aligned with the overall Agile development process and delivers high-quality software at a faster pace. |
| Test automation strategy | A high-level plan or approach for implementing test automation in an organization. A good test automation strategy defines the scope, objectives, timelines, and resources required for test automation, and outlines the tools, technologies, and methodologies to be used. It also considers factors such as test environment, data management, and team skills and expertise. A well-defined test automation strategy helps in reducing costs, improving test coverage and efficiency, and ensuring the quality of software releases. |
| Test case design in Agile | Test case design in Agile is the process of creating test cases for software testing in an Agile development environment. This process involves creating test cases that align with the Agile principles of flexibility, collaboration, and continuous improvement. Test case design in Agile typically involves creating test cases in smaller increments, with a focus on high-priority features and functionality. Test cases are often reviewed and refined as development progresses, to ensure that they remain relevant and effective. |
| Test coverage | Test coverage in Agile refers to the degree to which a set of test cases covers the functionality of a software application. Test coverage is an important metric in Agile development, as it helps teams to identify gaps in their testing efforts and ensure that all critical areas of the application are thoroughly tested. Test coverage can be measured using a variety of techniques, including code coverage analysis and risk-based testing. The goal of test coverage in Agile is to ensure that the application is thoroughly tested and meets the requirements of stakeholders. |
| Test design techniques in Agile | Test design techniques in Agile refer to the various approaches and methodologies that are used to create effective test cases in an Agile development environment. These techniques may include exploratory testing, user story testing, acceptance testing, and behavior-driven development. Test design techniques in Agile are designed to be flexible and adaptable, allowing teams to create and refine test cases as the application evolves. These techniques are often collaborative, with testers working closely with developers, product owners, and other stakeholders to ensure that testing efforts are aligned with the needs of the project. |
| Test environment | The test environment in Agile refers to the hardware, software, and other resources that are used to conduct software testing. The test environment is an important consideration in Agile development, as it can have a significant impact on the quality and reliability of testing results. In an Agile environment, the test environment may need to be updated frequently to reflect changes in the application, and testers may need to work closely with developers to ensure that the environment is properly configured and maintained. |
| Test pyramid | The test pyramid in Agile is a testing strategy that involves dividing testing efforts into three layers: unit tests, integration tests, and end-to-end tests. The test pyramid is designed to ensure that testing efforts are focused on the areas of the application that are most likely to contain defects, while minimizing the time and resources required for testing. Unit tests are typically automated and focus on testing individual code components, while integration tests focus on testing how different components work together. End-to-end tests are designed to test the application as a whole, from the user interface to the back-end systems. |
| Test-driven deployment | Test-driven deployment in Agile is a development approach that emphasizes the importance of automated testing in the deployment process. Test-driven deployment involves creating tests for new features and functionality before they are implemented, and then using these tests to ensure that the deployment process is smooth and error-free. Test-driven deployment is designed to minimize the risk of errors and defects in the deployment process, and to ensure that new features and functionality are thoroughly tested before they are released to users. |
| Test-driven development (TDD) | A software development process where tests are written before the code, and the code is developed incrementally to pass the tests. |
| Test-driven development (TDD) cycle | The sequence of steps involved in TDD, typically comprising of writing a failing test, writing code to pass the test, and refactoring. |
| Test-driven development (TDD) cycles | The repetition of TDD cycles until the desired software behavior is achieved, typically involving multiple tests and code iterations. |
| Test-driven development (TDD) frameworks | Pre-built structures that facilitate the implementation of TDD, providing a set of rules, guidelines, and best practices. |
| Test-driven development (TDD) in Agile | The integration of TDD principles in Agile software development, where TDD is used to ensure the timely delivery of high-quality software. |
| Test-driven development (TDD) tools | Software tools that aid in the implementation of TDD, such as testing frameworks, unit testing tools, and automated testing tools. |
| Test-driven improvement | Test-driven improvement is an Agile approach where the development and testing activities are driven by a continuous feedback loop. This feedback loop involves identifying areas for improvement, implementing changes, and testing those changes to verify that they meet the desired outcome. The goal of test-driven improvement is to improve the overall quality and effectiveness of the software development process. |
| Test-first approach | A Test-first approach is an Agile practice where testing is integrated into the development process from the very beginning. This approach involves creating automated tests before any code is written. Once the tests are in place, the development team writes code that satisfies the tests. The goal of the test-first approach is to improve the quality of the code by catching defects early in the development process. |
| Test-first development | Test-first development is an Agile practice where testing is an integral part of the software development process. This approach involves creating automated tests before any code is written. Once the tests are in place, the development team writes code that satisfies the tests. The goal of test-first development is to catch defects early in the development process and to ensure that the code meets the desired specifications. |
| Test-first development in Agile | Test-first development in Agile is an approach to software development that emphasizes testing as a fundamental part of the development process. In this approach, tests are created before any code is written, and the development team writes code to satisfy the tests. Test-first development helps to ensure that the code meets the desired specifications and catches defects early in the development process. |
| Time and materials (T&M) contract | A Time and Materials (T&M) contract is an agreement between a customer and a vendor that specifies the time and materials required to complete a project. In a T&M contract, the customer pays for the time and materials used to complete the project, rather than a fixed price. T&M contracts are often used in Agile projects because the requirements may change frequently, and it may be difficult to estimate the total cost of the project upfront. |
| Timeboxing | Timeboxing is an Agile project management technique where a fixed amount of time is allocated for a specific task or activity. Timeboxing helps to ensure that the project stays on track and that the team does not spend too much time on any one activity. If the team is unable to complete the task within the allocated time, the task is either re-prioritized or broken down into smaller, more manageable tasks. Timeboxing helps to improve project predictability and transparency. |
| User acceptance testing (UAT) | A process of verifying that a software system meets the user’s requirements and is fit for purpose. UAT is typically performed by the end-users or customer representatives to ensure that the system meets their expectations and is ready for deployment. |
| User acceptance testing (UAT) in Agile | In Agile, UAT is typically conducted as part of the sprint or iteration, with the end-users or customer representatives working closely with the development team to provide feedback on the product increment. The feedback is used to refine the product and ensure that it meets the user’s needs. |
| User experience (UX) design | The process of designing the user interface and interactions of a software system to ensure that it is user-friendly, efficient, and enjoyable to use. UX design involves understanding the users’ needs and goals, creating user personas, conducting user research, and iterating on designs based on user feedback to create a high-quality user experience. |
| User stories | Short, simple descriptions of a feature or requirement from the perspective of the end-user or customer. User stories are used in Agile to define the work that needs to be done and provide a common understanding of the requirements. They typically follow a specific format, including a description of the user, what they want, and why they want it. |
| User stories and acceptance criteria | Acceptance criteria are the specific conditions that must be met for a user story to be considered complete. They provide a shared understanding of what is required for a user story to be accepted by the product owner or customer. User stories and acceptance criteria work together to define the scope of work and ensure that the development team and the customer are aligned on the expected outcome. |
| User stories as a communication and collaboration tool. | User stories are often used as a communication and collaboration tool in Agile development. They help to ensure that everyone involved in the development process has a shared understanding of the user’s needs and goals, and they provide a clear definition of the scope of work. By using user stories as a collaboration tool, teams can work together more effectively and produce high-quality software that meets the user’s needs. |
| User story mapping | A collaborative technique used in Agile development to visualize and prioritize user requirements in the form of user stories. It involves arranging user stories in a hierarchy based on user goals and priorities, and helps teams identify gaps, overlaps, and dependencies. |
| User story mapping session | A facilitated meeting in which team members and stakeholders collaborate to create a user story map. During the session, the team discusses user needs, identifies key personas, and creates a high-level backlog of user stories. |
| User-centered design (UCD) in Agile | A design philosophy that emphasizes understanding user needs, behaviors, and preferences to create software that is easy to use, efficient, and satisfying. In Agile development, UCD involves iterative testing and validation of design concepts with users, and incorporating feedback into the development process. |
| Value stream mapping | A lean technique used to analyze and optimize the flow of value through a system or process. In Agile development, value stream mapping helps teams identify and eliminate waste, reduce cycle time, and improve the overall efficiency and effectiveness of the development process. |
| Value-driven delivery in Agile | A development approach that emphasizes delivering the most valuable features and functionality to users first, based on their needs and priorities. In Agile development, value-driven delivery involves continuous prioritization, testing, and feedback from users to ensure that the software meets their needs and delivers maximum value. |
| Velocity | A metric used in Agile development to measure the amount of work completed by a team in a given sprint or iteration. Velocity is calculated by summing up the story points or task points completed by the team during the sprint, and is used to forecast the amount of work that can be completed in future sprints. |
| Velocity chart | A graphical representation of the amount of work completed by an Agile team during a sprint, usually measured in story points. |
| Burndown chart | A graphical representation of the remaining work to be completed in a sprint, usually measured in story points. |
| Whole team approach | An Agile approach that emphasizes the involvement and collaboration of all team members, including developers and testers. |
| Whole-team testing | An Agile approach to testing where all team members, including developers and testers, are responsible for testing. |
| Work-in-progress (WIP) limits | A technique used in Agile development to limit the amount of work in progress at any given time, with the aim of improving productivity and flow. |
| Working agreements | A set of guidelines or ground rules established by the Agile team to ensure everyone is on the same page, improving collaboration and efficiency. |
| Working software over comprehensive documentation | An Agile principle emphasizing that the primary measure of progress is the working software delivered to customers, rather than exhaustive documentation. |
| Zero defect mindset | A mindset in Agile development where the team strives for continuous improvement by preventing defects from occurring in the first place, rather than just detecting and fixing them. |