Hiccupps

I'm reading Rick Rubin's The Creative Act: A Way of Being . It's spiritual without being religious, simultaneously vague and specific, and unerring positive about the power and ubiquity of creativity.  We artists — and we are all artists he says — can boost our creativity by being open and welcoming to knowledge and experiences and layering them with past knowledge and experiences to create new knowledge and experiences.  If that sounds a little New Age to you, well it does to me too, yet also fits with how I think about how I work. This is in part due to that vagueness, in part due to the human tendency to pattern-match, and in part because it's true. I'm only about a quarter of the way through the book but already I am making connections to things that I think and that I have thought in the past. For example, in some ways it resembles essay-format Oblique Strategy cards and I wrote about the potential value of them to testers 12 years ago. This week I found the f

On Friday, in the weekly ensemble I have with some of the medical practitioners at work, I suggested we take a look at the first challenge from The Testing Map .  We all spend a lot of time testing although the others focus more on the domain side than the pure software side. That focus was reflected in the kinds of checks they tended towards: input strings that have obvious human semantics but which, for a seasoned software tester, would probably fall into a single equivalence class. While exploring some those strings we stumbled into security testing with the input "I don't know" because, due to the apostrophe, the testing challenge credited us with an attempted SQL injection. From there we were able to talk about script and HTML injection, and that slid into opening the developer tools in our browser and poking around the source, network traffic, cookies, and so on. The consensus when debriefing was that coverage can be improved when looki

"How did you work that out so quickly?" my friend asked earlier this week when I sent him a handful of additional ways to view the problem we'd been pairing on.   "Stack Overflow and lots of small, fast, cheap experiments," I replied. And that's often true. It might not be Stack Overflow, but it's usually breaking a problem down, iterating on coherent chunks of it, composing the pieces into larger chunks, and building back to the original problem. The approach is reliable for me, but asking if it will be quick is like asking how long the proverbial string is . Sometimes it takes longer and I need to iterate on the approach itself, finding other "seams" along which to break the problem apart into units that can be addressed independently.  Sometimes I just give up and wait for the next opportunity to learn . Whether this is the right thing depends on all sorts of factors including whether I need an answer, whether I need the answer,