Agile Testing: A Practical Guide for Testers and Agile Teams

Glossary

This glossary contains the authors’ definitions of terms used throughout this book.

Acceptance Test

Acceptance tests are tests that define the business value each story must deliver. They may verify functional requirements or nonfunctional requirements such as performance or reliability. Although they are used to help guide development, it is at a higher level than the unit-level tests used for code design in test-driven development. Acceptance test is a broad term that may include both business-facing and technology-facing tests.

Application Programming Interface (API)

APIs enable other software to invoke some piece of functionality. The API may consist of functions, procedures, or classes that support requests made by other programs.

Build

A build is the process of converting source code into a deployable artifact that can be installed to run the application. The term “build” also refers to the deployable artifact.

Component

A component is a larger part of the overall system that may be separately deployable. For example, on the Windows platform, dynamic linked libraries (DLLs) are used as components, Java Archives (JAR files) are components on the Java platform, and a service-oriented architecture (SOA) uses Web Services as components.

Component test

A component test verifies a component’s behavior. Component tests help with component design by testing interactions between objects.

Conditions of satisfaction

Conditions of satisfaction, also called satisfaction conditions or conditions of business satisfaction, are key assumptions and decisions made by the customer team to define the desired behavior of the code delivered for a given story. Conditions of satisfaction are criteria by which the outcome of a story can be measured. They evolve during conversations with the customer about high-level acceptance criteria for each story. Discussing conditions of satisfaction helps identify risky assumptions and increases the team’s confidence in writing and correctly estimating all the tasks to complete the story.

Context-driven testing

Context-driven testing follows seven principles, the first being that the value of any practice depends on its context. Every new project and every new application may require different ways of approaching a project. All seven practices can be found on the website www.context-driven-testing.com/.

Customer team

The customer team identifies and prioritizes the features needed by the business. In Scrum, these features become epics or themes, which are further broken into stories and comprise the product backlog. Customer teams include all stakeholders outside of the development team, such as business experts, subject-matter experts, and end users. Testers and developers work closely with the customer team to specify examples of desired behavior for each story and turn those examples into tests to guide development.

Customer test

A customer test verifies the behavior of a slice or piece of functionality that is visible to the customer and related directly back to a story or feature. The terms “business-facing test” and “customer-facing test” refer to the same type of test as customer test.

Development team

The development team is the technical team that produces the software requested by the customer team. Everyone involved in delivering software is a developer, including programmers, testers, database experts, system administrators, technical writers, architects, usability experts, and analysts. This development team works together to produce the software and deliver value to the business, whether they are a co-located team or a virtual team.

Epic

An epic is a piece of functionality, or feature, described by the customer and is an item on the product backlog. An epic is broken up into related stories that are then sized and estimated. Some teams use the term “theme” instead of epic.

Exploratory testing

Exploratory testing is interactive testing that combines test design with test execution and focuses on learning about the application. See Chapter 10, “Business-Facing Tests that Critique the Product,” for an extensive definition of exploratory testing.

Fake object

A fake object replaces the functionality of the depended-on component with a simpler implementation. It emulates the behavior of the real depended-on component but is easier to use for testing purposes.

Feature

A feature is a piece of functionality described by the customer and is an item on the product backlog. A feature is broken up into related stories that are then sized and estimated. In agile development, the terms “epic” or “theme” are often used in place of “feature.”

Functional test

Functional tests verify the system’s expected behavior given a set of inputs and/or actions.

Greenfield

Greenfield projects are new application development projects starting from scratch with no existing code base. There are no constraints, so development teams have many options open to them.

Integrated Development Environment (IDE)

An Integrated Development Environment, or IDE, is a set of tools that support programming and testing. It usually includes an editor, compiler or intepreter debugger, refactoring capabilities, and build automation tools. IDEs usually enable integration with a source code control system and provide language-specific support to help with code design.

Iteration

An iteration is a short development cycle, generally from one to four weeks, at the end of which production-ready code can potentially be delivered. Several iterations, each one the same length, may be needed to deliver an entire theme or epic. Some teams actually release the code to production each iteration, but even if the code isn’t released, it is ready for release.

Java Messaging Service (JMS)

The Java Messaging Service (JMS) API is a messaging standard that enables application components based on the Java 2 Platform, Enterprise Edition (J2EE) to create, send, receive, and read messages.

Legacy System

A legacy system is one that does not have any (or few) automated regression tests. Introducing changes in legacy code, or refactoring it, might be risky because there are no tests to catch unintended changes in system behavior.

Multipurpose Internet Mail Extensions (MIME)

Multipurpose Internet Mail Extensions, or MIME, extend the format of Internet mail to enable non-textual messages, multipart message bodies, and non-US-ASCII textual messages and headers.

Mock Object

A mock object simulates the responses of an existing object. It helps with designing and testing interactions between objects, replacing a real component so that a test can verify its indirect outputs.

Product Backlog

Product Backlog is a Scrum term for the prioritized master list of all functionality desired in the product. This backlog grows over time as the organization thinks of new features they may need.

Product Owner

Product Owner is a Scrum term for the person responsible for prioritizing the product backlog, or stories. He or she is typically someone from a marketing role or a key business expert involved with development.

Quality Assurance (QA) Team

Quality Assurance, or QA, can be defined as actions taken to ensure compliance with a quality standard. In software development, the term “QA Team” is often used to refer to the team that does software testing. Test teams (see Test Team) provide stakeholders with information related to the quality of the software product. They perform activities to learn how the system under test should behave and verify that it behaves as expected. In agile development, these activities are fully integrated with development activities. Testers are often part of the development team along with everyone else involved in developing the software.

Production Code

Production code is the code for the system that is, or will be, used in production, as distinguished from the code that is written to test it. Test code invokes or operates on production code to verify its behavior.

Refactoring

Refactoring is changing code, without changing its functionality, to make it more maintainable, easier to read, easier to test, or easier to extend.

Regression Test

A regression test verifies that the behavior of the system under test hasn’t changed. Regression tests are usually written as unit tests to drive coding or acceptance tests to define desired system behavior. Once the tests pass, they become part of a regression test suite, to guard against unintended changes being introduced. Regression tests should be automated to ensure continual feedback.

Release Candidate

A release candidate is a version or build of the product that can potentially be released to production. The release candidate may undergo further testing or be augmented with documentation or other materials.

Return On Investment (ROI)

Return on investment, or ROI, is a term borrowed from the world of financial investments and is a measure of the efficiency of an investment. ROI can be calculated in different ways, but it’s basically the difference between the gain from an investment and the cost of that investment, divided by the cost of that investment. In testing, ROI is the benefit gained from a testing activity such as automating a test, weighed against the cost of producing and maintaining that test or activity.

SOAP

SOAP is a protocol for exchanging XML-based messages over networks, normally using HTTP/HTTPS. It forms the foundation layer of the web services protocol stack, providing a basic messaging framework upon which abstract layers can be built. A common SOAP messaging pattern is the Remote Procedure Call (RPC) pattern, in which the client network node sends a request message to the server node, and the server immediately sends a response to the client.

Story

A user story is a short description of functionality told from the perspective of the user that is valuable to either the user or the customer team. Stories are traditionally written on index cards. The card typically contains a one-line description of the feature. For example, “As a shopper, I can put items in my shopping cart so that I can check out with them later” is a story. Cards are only useable in combination with subsequent conversations between the customer team and the development team and some verification that the story has been implemented through writing and running tests.

Story Test

A story test defines expected behavior for the code to be delivered by the story. Story tests may be business-facing, specifying the functional requirements, or technology-facing, such as security or performance tests. These tests are used to guide development as well as to verify the delivered code. Most agile practitioners use the term “story test” synonymously with “acceptance test,” although the term “acceptance test” might be used for tests that verify behavior at a higher level than one story.

Story Board

The story board, also called the task board, is used to track the work the team does during an iteration. Task cards, which may be color-coordinated for the type of task, are written for each story. These cards, along with a visual cue of some kind, provide an easy mechanism for seeing the current status of an iteration’s progress. It may use columns or different colored stickers on cards for different states such as “To do,” “Work in Progress,” “Verify,” and “Done.” The story board might be a physical board on a wall or a virtual online board.

Task

Tasks are pieces of work needed to finish a story. A task might be action needed to implement a small piece of a story, or it might be for building a bit of infrastructure, or testing that encompasses more than one story. Generally it should represent a day or less of work.

Technical Debt

Ward Cunningham first introduced this metaphor. When a team produces software without using good practices such as TDD, continuous integration, and refactoring, it may incur technical debt. Like financial debt, technical debt accrues interest that will cost the team more at a later date. Sometimes this debt may be worthwhile, such as to take advantage of a sudden business opportunity. Usually, though, technical debt compounds and slows the team’s velocity. Less and less business value can be produced in each iteration because the code lacks a safety net of automated regression tests or has become difficult to understand and maintain.

Test Double

A test double is any object or component that’s installed in place of the real component for the express purpose of running a test. Test doubles include dummy objects, mock objects, test stubs, and fake objects.

Test-Driven Development (TDD)

In test-driven development, the programmer writes and automates a small unit test before writing the small piece of code that will make the test pass. The production code is made to work one test at a time.

Test-First Development

In test-first development, tests are written in advance of the corresponding production code, but the code is not necessarily made to work one test at a time. Customer or story tests may be used in test-first development as well as unit tests.

Test Stub

A test stub is an object that replaces a real component needed by the system under test with a test-specific object that feeds desired indirect inputs into the system under test. This enables the test to verify logic independently of the other components.

Test Team

A test team performs activities that help define and subsequently verify the desired behavior of the system under test. The test team provides information to the stakeholders about the external quality of the system, the risks that may be present, and potential risk mitigation strategies. In agile development, these activities are fully integrated with development activities. Testers are often part of the development team along with everyone else involved in developing the software.

Tester

A tester provides information to stakeholders about the software being developed. A tester helps customers define functional and nonfunctional requirements and quality criteria, and helps turn these into tests that guide development and verify desired behavior. Testers perform a wide variety of activities related to delivering high-quality software, such as test automation and exploratory testing. In agile development, everyone on the development team performs testing activities. Team members who identify themselves as testers work closely with other members of both the developer and customer teams.

Theme

A theme is the same as an epic or feature. It is a piece of functionality described by the customer and placed in the product backlog to be broken up into stories that are sized and estimated.

Unit Test

A unit test verifies the behavior of a small part of the overall system. It may be as small as a single object or method that is a consequence of one or more design decisions.

Velocity

A development team’s velocity is the amount of value it delivers in each iteration, measured in story points, ideal days, or hours. Generally, only completed stories are included in the velocity. Velocity is helpful to the business in planning for future features and releases. Agile teams use their velocity for the previous iteration to help determine the amount of work they can take on in the next iteration.

Web Service Description Language (WSDL)

Web Service Description Language (WDSL) is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information.