Agile Testing: A Practical Guide for Testers and Agile Teams

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