investigating software

I was raised in a world full of rules, like all of us, though as I grew up in a military family in and around military bases - so maybe a bit more so for me. As a parent myself, rules are at play - "no son you can't bang our wooden table with an old hammer". Even the business world is full of rules, don't agree? Speak to your bank's payments or compliance department or your lawyer or accountant and get back to me. We soak up all sorts of rules like sponges, implicitly.  Like my toddler son when he found my old hammer, "no the rule is I can't bang the table with the hammer - when you are in the room" - while he has reverse engineered the rule and context perfectly - Though I feel he didn't pick up on the full spirit of the rule. The late author David Graeber had a talent for analysing rules in societies old and new. He used "opposites" as a way to elucidate the rules and assumptions at play in fiction and in society. A good example he us...

I was recently struck by a glaring difference between how I and a programmer prepared for testing. Unlike the majority of the testing I am involved in, this particular testing 'phase' had to be scheduled in advance and we couldn't "just do it". This also meant we had more time to prepare and plan than we typically do. This 'waiting period' had its uses. We had time to create tools that might be useful and check the configuration of the systems we would be testing. The team, familiar with the concepts of exploratory testing, were comfortable with an approach that meant we did not spend the majority of the time pre-scripting tests [be they coded or in a spreadsheet etc]. We did however build a high-level checklist of areas to test and used this to drive our program of tools and configuration checking/fixing/building. The key difference I observed was the absolute nature of the programmers comparisons between our test systems and our live-production syste...