In TDD, there are always more potential scenarios to test, other than the “happy path” of desirable behavior. We need a way to decide how far to go.
This is often a question of risk assessment. Having a framework for thinking about risk can be useful. Consider this framework that has two dimensions: Likelihood and severity. Crossing these produces a four-quadrant matrix. Continue reading “A Framework for Thinking About Risk”
In many large organizations there is a kind of wall between development and testing. Developers do their work and “throw it over the wall” to be tested. This can create negative attitudes on both sides.
Developers see testers either as a source of no information (“it works? Yeah we knew that”) or bad news (“there are bugs to find and fix, ugh”). Testers are adversaries to overcome before developers can be said to have succeeded.
Testers see developers as a source of hard work, and code that must be wrestled with. Often testing lags hopelessly behind development and because of this testers see developers as a source of a never-ending avalanche of work.
Continue reading “TDD Makes Developers and Testers into Valued Colleagues”
An intermediary practice is a practice that works indirectly on what you are trying to achieve. Before discussing examples and the risks of intermediary patterns, let’s look at some of the things needed to achieve flow (realizing value without delay):
- Removing delays in workflow (hand-offs and waiting for others), feedback, learning, and between getting and using information
- Manual testing
- Technical debt
By working directly on these, here is what you would have. Continue reading “Intermediary Practices vs. Practices That Work Directly on Flow”
Project Managers and Product Owners are sometimes dubious about the development team doing TDD. They are concerned that the team will slow down because they’ve been burdened with additional work, and that developers might “game” the system with bogus tests to satisfy the process. Also, it seems like a nonsensical idea to write a test for something before that thing exists.
All of these concerns are addressed by the observation that, despite its name, TDD is not really a testing activity. The “tests” that are written in TDD are actually the specification of the system.
The effects of this shift in thinking are profound. Continue reading “TDD Provides Value to Everyone in the Development Process”
Defects can either be prevented or detected.
Let’s say you write a method in C# that takes, as its parameter, one of the nine players on a baseball team.
If you decide to make that parameter an integer (1 is the pitcher, 2 is the catcher, and so forth), then the code will still compile if a number greater than 9, or less than 1, is passed into the method. You will have to take some action in the code if that happens: correct the data, throw an exception, something along those lines. This code would be written to “detect” the defect, and would be driven from a failing test in TDD.
On the other hand, we would not have to allow for the possibility that someone will pass a non-integer, like 1.5, into the method, because the compiler will not allow this. Anything the compiler, linker, IDE, etc. will not allow is considered a “prevented” defect. Continue reading “Figuring Out the Test You Missed is Job One”
I’ve created a new design for my book and am pretty excited about it. There are five parts to it:
- Part 1: Workbook: understanding what’s required for flow in your organization
- Part 2: Workbook: Using FLEX to transform your organization
- Part 3: Topics in depth
- Part 4: Using FLEX w/SAFe
- Part 5: Resources on the Net Objectives Portal
The first two parts cover the basics of FLEX. They present what the effective enterprise of the future looks like, giving a vision for the transformation. They are designed as workbooks to guide readers via a way to learn by doing. They are also relatively short so they represent a quick overview of the entire approach.
Part 3 provides an in-depth explanation of the topics used in the first parts. Part 4 discusses how to take advantage of FLEX’s Lean portfolio & prod management approach for those using SAFe.
The last part of the book is online, providing the latest ideas and practices we are coming up with.
If you are looking for a more effective approach than either SAFe or LeSS, I invite you both to look at the book as it is uploaded. If you are interested in using it to help with your own adoption, let me know as I am looking to work with a few people while it is being written
To see the book, go to Going Beyond Lean and Agile: Introducing FLEX (FLow for Enterprise Transformation) (online book)
It’s not unusual these days for development organizations to adopt a code coverage requirement. This is usually expressed as a percentage: at least X% of all code developed must be covered by tests.
Measurement tools are used as a process gate, where the team must achieve this minimum coverage level before code can be checked in. This is pointless and may be dangerously misleading. Code coverage tools can only measure how many lines of code are executed by tests, but not what the test do with the results of that execution. Continue reading “TDD and Code Coverage”
Simply put, the Theory of Flow focuses on two areas:
- The steps it takes from conception of an idea until value is realized from it
- Reducing the Cost of Delay, the revenue or opportunity lost because of delays in realizing value
Reducing Cost of Delay (CoD) is essential to the goal of business agility, the quick realization of value predictably, sustainably and with high quality. Continue reading “Using the Theory of Flow to Illustrate Impediments in Two Hours Instead of Two Weeks”
You cannot meaningfully test that which you do not adequately understand. The time to find that out is before you start development. TDD tells us what we do not know. Sometimes, it tells us what our stakeholders don’t realize they also don’t know.
Imagine you are developing the software for a casino’s poker slot machine (loosely based on a real case). Part of the behavior needed is to shuffle the “cards”, mixing them up into a new order. That would be the stated requirement. If we try to write a test about this, we realize that this is not nearly detailed enough. What is meant by a “new order”? How new? How will we know when the shuffling is adequate? Are there any regulatory requirements about this? Industry standards? Not being casino experts, the developers probably don’t know and would ask the customer. The customer might realize that they aren’t clear themselves.
Testing something requires far more rigor than most people apply to their businesses, and that means the development team that does TDD not only finds good questions to ask, but can also help the customer to more fully understand their own business domain. At times, this leads them to realize even more business value than they knew they wanted.
A typical question those adopting TDD ask is: How much testing is enough? Or, put another way, does everything really need to be tested? How do you decide what to test and what not to test?
It’s an interesting question, but I prefer to address it this way: everything will be tested. The real question is, by whom? Will it be you, or someone else? Continue reading “How Much Testing is Enough?”