Hiccupps

Eric Proegler was in town last week and I asked him if he'd be up for re-running his recent TestBash talk, Continuous Performance Testing, at our office. Good news! he was, and he told us the story of how a lumbering testing dinosaur who watched the agile asteroid crashing into his world could become a nimble testing ninja, slotting valuable and targeted performance tests confidently into modern continuous integration. Bad news! I continued my adventures in sketchnoting and they're not the greatest.

"Do you have generic strategies for the prioritisation of tasks?" When  Iuliana Silvăşan  asked the question I realised that I probably did, but I'd never tried to enumerate them. So we went to a  whiteboard for 20 minutes, and we talked and sketched, and then afterwards I wrote brief notes, and then we reviewed them, and now here they are... We think these factors are reasonably generally applicable to prioritisation of tasks: Risk Value Cost Importance Urgency Time Goals Commitments Yes, they are generic and, yes, they will overlap. That's life. The last three perhaps merit a little additional explanation. Time is a compound factor and covers things like resource availability, dependency planning, and scheduling problems which could be split out if that helps you. Goals cover things like experience you want to get, skills you want to practice, or people you want to work with. This might not be a primary factor, but could help you to choose betwe

George Dinwiddie recently delivered a webinar, Distilling the Essence , on the topic of crafting good examples of acceptance criteria. From the blurb: When creating our scenarios, we want to fully describe the desired functionality, but not over-describe it ... Which details should we leave visible, and which should we hide? ... [We will see how we can] distil our scenarios down to their essence and remove distracting incidental details. I loved it and, naturally, wondered whether I could distil the essence of it . Here goes: Not just examples, but essential examples. An essential example promotes shared understanding, testability, clarity of intent. Remove incidental details; they obscure the important. Highlight essential details; they have the most communicative value. Essential details don't change with user interface, workflow, implementation technology. To help: name scenarios, abstract specifics, note explicit rules, conditions, and boundaries. Bottom-up is O