Ok, I’m not sure if “reportability” is a real dictionary word. But it is a word. That I may or may not invented. Anyway, here’s the thing: You tested your app, or feature, or an API, and you found something unexpected. Like this one parameter value crashes the server. As Read more…
in the last post we talked about the failing builds trend as an indicator of success of implementation. The final metric we’ll look at, that can indicate how our process will go, is also related to broken builds. It is the “time until broken builds are fixed” or TUBBF. Ok, Read more…
Each stage of implementation is hard in its own way. When we start out with a new effort or process, we think of it as: Sure, it will be hard in the beginning, but it’s going to become easier as we continue. It’s true, and then after a while a new challenge Read more…
This is the 5th and final part of the series about analyzing what we’re coding, and therefore what to test. Last time, we actually got to writing the tests. Let’s do some cleanup. Step 8: Review Once we have the tests, it’s time to review both the code and tests. But Read more…
This is the 4th part of the series about analyzing our code and deciding what to test. Last time, we talked about design constraints. Now we’re moving towards the code itself. Almost there. Step 6: Prepare existing code This is an obvious step in test-after. We want to test the existing code, and Read more…
This is the 3rd part of the series about analyzing what we’re coding, and therefore what to test. Last time, we talked about test categorization and design considerations regarding testability. We haven’t touched or written any code yet. Nor will we before the end of this post. Patience is a virtue Read more…
