investigating software

I play a card game called cribbage. I often play it with my son . One interesting part of the game is the muggins rule. This means that you can claim points from other players turns, if they miscount the score.  The scoring is slightly nerve racking, with each of us double and triple checking our scores, to avoid falling foul of ‘muggins’, that’s part of the fun.  But my son and I also find ourselves discussing other hands of cards, in a sort of alternate history version of the game. “So if I had a 7 instead of a 2 of hearts, then I’d get a double run and score at least 8 more points”.   “Yes Dad, if you had different cards then you would likely have a different score, but you don’t” he says while rolling his eyes.  This sort of bitter-sweet history rewriting is a convenient tool for us to swallow the awkward truth of the real world. We often create alternate things to object to.  Take Chat GPT 4 and tools like Copilot X. These are powerful tools, capable of doing useful tasks quicker

Take a pack of cards, shuffle them well, and place them on the desk in front of you. Could you accurately tell me what the order of the cards would be, without looking?   By Rosapicci - Own work, CC BY-SA 4.0 Now spend 2 weeks in a software development team, writing code & using services, and deploy that code to your cloud server environments. Could you tell me where the bugs would be, before looking? In both cases we have a rough idea of what’s in the product at the end. But the detail, how its actually going to play out? we have no realistic idea. Skeptical? Take the playing cards… If we lay the cards out one card at a time. Then the order in which they are laid out, has probably never been seen before. Ever.The number of permutations of the well-known 52 playing card pack is 80,658,175,170,943,878,571,660,636,856,403,766,975,289,505,440,883,277,824,000,000,000,000. OK, now let’s get back to our code. Even trivial apps, include dozens of code libr

Ever feel like your team is in a deadlock? The product owner wants Gizmo+ to be shipped, your senior engineers are split between grokking Gizmo+ and fixing Widget++ . Meanwhile the SDETs are franticly updating automated checks/BDD scripts and exploratory testers are uncovering that Widget+ and Gizmo+ should have been named ...+10 given the number of surprise bonus features they are finding. As a consequence feature delivery can start to slow and quality is inevitably hit as difficult decisions are made on what to fix. The typical reactions to such a situation can depend on your project's context, but to highlight a few common ones: Ramp up team size. Push back on deadlines. Push back on new features. Delay releases until 'it all gets sorted' ... I don't have to break it to you that these options are 'far from optimal'. In summary they all revolve around costing more and delivering less (from my time as a programme manager I can tell you - thats wha

Last week I was performing another of my 5 minute testing exercises. As posted before, if I get a spare few minutes I pick something and investigate. This time, I'd picked Google Calendar. One thing people use calendars for is logging what they have done. That is, they function as both schedulers and record keepers. You add what you planned to do, and they also serve as a record of what you did - useful for invoicing clients or just reviewing how you used your time. Calendars and software based on them are inherently difficult to program and as such are often a rich source of bugs. People make a lot of assumptions about time and dates. For example that something ends after it starts. That may sound like something that 'just is true', but there are a number of reasons why that might not be the case. Some examples are: You type in the dates the wrong way round (or mix up your ISO and US dates etc) You're working with times around a DST switch, when 30min after 0

Once upon a time there was a young and naive tester, he was new to the world of software testing. He often felt he didn't have what it took to be a tester. Sure, he found the odd bug, and he enjoyed his work, but he also often missed bugs, issues or problems. After a while, he admitted to himself that this was a problem, and decided to seek help. He stood up from his desk and walked over to his test manager's desk. His manager was wise and experienced. He was the Mr Miyagi of testing, and as such was always offering zen-like advice for his team. A simple question about where the stapler had escaped to could turn into a somewhat baffling series of Haiku , leaving our young tester baffled. Our novice explained his problem, and his concerns about how maybe he wasn't cut out for testing. The wise test manager smiled, thought for a moment and then opened his little Moleskine notebook. He turned carefully through the pages, settled on a page, looked up and said: "I over

Why do we refer to our ancestors as Cavemen? The evidence of course! The cave paintings, the rubbish piles found in caves all round the world. It's simple, Cavemen lived in caves, they painted on the walls and threw rubbish into the corner of the cave. Thousands of years later we find the evidence, demonstrating they lived in caves. Hence the moniker 'caveman'. How many caves have you seen? Seriously, How many have you seen or even heard of? Now I'm lucky, as former resident of Nottingham [in the UK], I've at least heard of a few . But if you think about it, you probably haven't seen that many. Even assuming you've seen a fair-few, how many were dry, spacious and safe enough for human habitation? As you can guess, my point is: there probably isn't a great selection of prime cave real-estate available. It doesn't add up: The whole of mankind descended from cave [dwelling] men? Before you roll your eyes, and think I'm some sort of Creationist ,

I'm watching my son, a toddler, at play. He picks up his toy train, a hefty piece of wind-up fisher-price-esque technology, and hurls it at the water bottle. I'll not pass judgement - but suffice to say - the bottle is still standing - several other objects in the room are not. He reaches down with both arms and picks up the train again. He steps a bit further away, turns his back on the bottle, and slings it back over his shoulder. A few more similar attempts end in much the same result, Until finally the killer-move is identified: You stand point-blank over the bottle and drop/throw the train down onto the bottle. A chip off the old block. I'm glad my son is having fun. But I'm interested - What's he thinking? No, that's not it... How is he thinking? What he's doing has strong parallels with what his father does for a living. I spend much of my time learning how [for example] a tool works or, maybe more often, how they don't work. If that takes the ap