[Rakuten TechConf2014] [G-4] Beyond Agile Testing to Lean Development

Editor's Notes

• #2: BEYOND AGILE TESTING TO LEAN DEVELOPMENT - Jim Coplien • Testing is a business function that should be focused on risk  • Lean defines testing as waste — why do it?  • Automated tests should reflect requirements, but testers shouldn't test requirements  • Testers are the team's conscience 50 Minutes
• #3: Mike Cohn’s testing triangle
• #11: http://qz.com/196200/toyota-is-becoming-more-efficient-by-replacing-robots-with-humans/ Max Niesen, April 7, 2014 James Bach: “Testing Requires Inference.” “Exploratory inference may sound like a strange idea. It means one idea leading to another in ways you can’t predict in advance” [and, therefore, can’t script].
• #13: What if the methods we break them down with are private and used just to make the code more readable? I'm sure you could pronounce it faster... And I'm sure that it takes less time to read individual sentences than to read all of Moby Dick. But readability isn't the entire story, and comprehension is a big part of that. Appreciation comes in the whole. You don't appreciate the beauty of the Mona Lisa by studying only her nose: you take in the whole. It is more than the sum of its parts, just as understanding must be more than the sum of its parts. There are some strange loops going in the other direction, and this is where I've picked up a new tool in the past weeks: Weinberg's law of decomposition. Each part is much more than a decomposition of the whole. Because it is so much more, it is harder to understand as an entity than it is to understand when contextualized by its surroundings. So the phrase, "Frankly, dear, I don't give a damn" has some meaning in its own right but 100 times as much meaning when read in the context of "Gone With The Wind." Poetry is about about compression: about using cultural context, and the context of the rest of the work, to amplify meaning. Great software is group poetry writing. If you're not doing that, you're just a machine automating the generation of some object code in an assembly language called Java.
• #14: What if the methods we break them down with are private and used just to make the code more readable? I'm sure you could pronounce it faster... And I'm sure that it takes less time to read individual sentences than to read all of Moby Dick. But readability isn't the entire story, and comprehension is a big part of that. Appreciation comes in the whole. You don't appreciate the beauty of the Mona Lisa by studying only her nose: you take in the whole. It is more than the sum of its parts, just as understanding must be more than the sum of its parts. There are some strange loops going in the other direction, and this is where I've picked up a new tool in the past weeks: Weinberg's law of decomposition. Each part is much more than a decomposition of the whole. Because it is so much more, it is harder to understand as an entity than it is to understand when contextualized by its surroundings. So the phrase, "Frankly, dear, I don't give a damn" has some meaning in its own right but 100 times as much meaning when read in the context of "Gone With The Wind." Poetry is about about compression: about using cultural context, and the context of the rest of the work, to amplify meaning. Great software is group poetry writing. If you're not doing that, you're just a machine automating the generation of some object code in an assembly language called Java.
• #15: What if the methods we break them down with are private and used just to make the code more readable? I'm sure you could pronounce it faster... And I'm sure that it takes less time to read individual sentences than to read all of Moby Dick. But readability isn't the entire story, and comprehension is a big part of that. Appreciation comes in the whole. You don't appreciate the beauty of the Mona Lisa by studying only her nose: you take in the whole. It is more than the sum of its parts, just as understanding must be more than the sum of its parts. There are some strange loops going in the other direction, and this is where I've picked up a new tool in the past weeks: Weinberg's law of decomposition. Each part is much more than a decomposition of the whole. Because it is so much more, it is harder to understand as an entity than it is to understand when contextualized by its surroundings. So the phrase, "Frankly, dear, I don't give a damn" has some meaning in its own right but 100 times as much meaning when read in the context of "Gone With The Wind." Poetry is about about compression: about using cultural context, and the context of the rest of the work, to amplify meaning. Great software is group poetry writing. If you're not doing that, you're just a machine automating the generation of some object code in an assembly language called Java.
• #17: Type 2: Weinberg’s Law of Decomposition Type 4: Keeping tests that never fail
• #18: Last point: Most tests are irrational: i.e., you can never presume software correctness from the tests. But we do feel better by having checked, so we test anyhow.
• #20: Be customer-focused
• #22: Debug Complexity: How Assertions Affect Debugging Time. Sergey Ignatchenko and Dmytro Ivanchykhin, Overload, October 2014
• #25: Conscience… Curmudgeonly and like Emperor’s New Clothes — not in the sense of standing in the way. That’s business’s job.
• #26: No unit - subsystem - system - integration - acceptance test leveling.