Blackblot PMTK and Test-driven Development
Introduction
This review explores the compatibility of the Blackblot Product Manager's Toolkit® (PMTK), a market-driven product management methodology, with Test-driven Development (TDD), a software development technique.
Test-driven Development Background
The true origins of TTD are obscure. It possibly originated somewhere in the 1940s-1950s.
Kent Beck, an American software engineer, has been credited with further developing and promoting the use of TDD since the late 1990s.
In 1996 Mr. Beck was hired to help develop a payroll software application at Chrysler, a large automobile manufacturer in the USA.
The Chrysler project inspired Mr. Beck to create eXtreme Programming (XP), a software development method.
Mr. Beck is also a signatory on the Agile Manifesto, a proclamation document published in 2001 that lists preferred values and principles related to custom software development.
The Agile Manifesto is based on Lightweight Software Development principles, which advocate iterative and incremental software development.
The popularity of the Agile Manifesto has effectively rebranded Lightweight Software Development as Agile Software Development.
Consequently, TDD, XP, and Agile Software Development have become closely associated.
There is a noticeable growing interest in Test-driven Development (TDD) in the software engineering sphere.
Test-driven Development's Character
Test-driven Development is a software development technique whereby the product's functionality (features) are incrementally developed so that tests drive the development.
With TDD, test cases to test (verify) product functionality are prepared before writing the software's source code. Test verification occurs after the source code is written.
TDD's approach contrast with the more "traditional" Test-last Development (TLD), whereby test cases are written and tests are executed after the source code is prepared.
In the TLD approach, the development team first designs the product, then writes the source code, and only at the end of the development cycle the test cases are written, and the tests are executed.
TDD Pros and Cons
Proponents claim that TDD generates software code that is easier to maintain and more modular, code restructuring is streamlined, less debugging is required, and project costs are reduced.
Furthermore, proponents of TDD see it as a crucial enabler of agility.
The claim is that TDD helps build an automated test suite that reduces the time spent on re-testing the software following future code changes, which is one of the biggest challenges in software development.
However, critics of TDD claim the following:
- Software testing, in general, slows down the development process.
- TDD presents a steep learning curve.
- Software created with TDD is more costly due to maintaining and synchronizing the test code and the source code following changes in the product scope.
Proponents of TDD counter that most criticisms are not necessarily due to TDD in itself but rather towards automated testing in general.
Creating TDD Test Cases
TDD specifies that descriptions of expected system behavior are used as input to create test cases.
Optivem, a software development coaching company with solid expertise in TDD, advocates relaying on use cases, or user stories and acceptance criteria tandems, to develop TDD test cases.
Use cases are a very reliable and established concept in software development.
There are different interpretations of user stories, but there is some consolidation on the format of user stories that can be used to create TDD test cases.
PMTK and Use Cases
In the Blackblot PMTK™ Methodology, use cases describe how different personas put a solution to use and for which events.
Use cases define events (specific instances of usage) and describe who (persona) does what (interaction) with the product and for what purpose (goal).
In more precise terms, a use case is a specific way of using the system by performing some part of the functionality.
Each use case constitutes a complete course of action initiated by a persona, and it specifies the interaction between a persona and the system.
The collected use cases specify all the existing ways of using the system.
For more information, see the Blackblot PMTK Use Cases template.
PMTK Requirements and Use Cases
PMTK views the topic of "requirements" as a robust and proven technique for representing different levels of information required for product delivery.
Developed by Blackblot, the Blackblot Procedural Requirements Management™ Model (PRM Model) is a methodology to create high-quality, usable market and product requirements:
1. Market Requirements describe the market problem.
2. ProductRequirements describe the solution.
In PMTK, use cases are written by the Product Planner (AKA Product Manager) or the Product Architect, based on existing market and/or product requirements.
Accordingly, PMTK regards the transfer of information between product management and product development, starting with product management authoring market and product requirements and developing use cases.
Subsequently, uses cases are used by product development to create TDD test cases, help perform system structuring, and increase the potential to build better features by understanding product/user interaction.
Blackblot and Optivem endorse this approach.
Summary
Blackblot Product Manager's Toolkit® (PMTK) and Test-driven Development (TDD) are compatible.
While there are nuances to authoring uses cases, PMTK and Test-driven Development compatibility is an example of everything falling into place when you work according to sound principles.
A PMTK and Test-driven Development combination offers best practices in product management and product development and a proper interface between product management and product development without conflict or overlap.
Special thanks to Valentina Cupać from Optivem for her invaluable assistance with this review.