investigating software

Office meetings are interesting events. Seriously, even the most boring ones. There's usually an important reason for the meeting, even if that meeting has been lost in the sands of Outlook repeat-booking, or the present attendees feel strongly otherwise. There's usually some kind of agenda, although as the meeting progresses, you may suspect the real agenda is hidden. But none of that is what captures my imagination. What sticks in my mind is the perspectives of the people in the room, especially when they are talking about a subject close to my heart like testing. We can't help but give away our positions and perceived hierarchies when discussing what work we need to do, and how. For example have you heard someone utter, in a meeting, words to the effect of: "Just create a fully automated framework for our regression test pack, to test the future releases." Then continue on, as if they had asked to "borrow a pen", or if you could "just adjust t

For those of you that don't know, I'm somewhat of an amateur horologist. I love clocks, watches and all sorts of time and date keeping gadgets. To feed my passion I've decided to invest in my own custom made timepiece. This device will be my first custom made high value item, in what I hope will one day be a great collection. To ensure I get what I want, I've taken some time and documented the following requirements for my new clock. They list what I want from the timepiece, and also what I don't want or need. Have a read through, and hopefully you'll see what it is I'm after. A new clock should be developed for my new home in London. The clock will need to: - Display the time. - Display in roman numerals and modern  'arabic' numerals . - Be accurate enough for household use - approx' to with in a few minutes. - Be ornamental - preferably with a intricately styled clock face. - Have a traditional square brass clock face - Be construct

Recently, I was testing a new feature for a client, it had a known bug, that I'd found in prior testing, for which we'd figured-out a work-around. I was now performing further testing of the feature, hoping to discover more issues and figure out how it behaves a little better. Does not apply to testers. By this time, the work-around had become the norm - the expected mode of operation for the feature. Essentially this 'bug' had been found and was now fixed. Time had moved on. So what did I do? I ignored the work-around, applied my 'test load' to the system and activated the new feature. The failure was somewhat spectacular. A short while later the entire system was inoperable and a restart of several servers was required. This was interesting. If I'd had expectations of what would happen, then it would of been for something simpler, less severe and closer to what had happened when I first found the bug that required the workaround. After some invest

If you're a tester then you'll no doubt of heard phrases to the effect of "That's pretty unlikely", "Our users don't do that" or "Thats a fairly minor browser". Its been blogged about before , and elsewhere. The argument is many users are niche, novice, confused or from different backgrounds / viewpoints / languages. These are realistic and probably correct hypotheses, for many situations. From my experience, thats often where the discussion ends, someone makes a judgement call, and the issue is fixed, mitigated or ignored. More often, than not, its ignored. That decision should probably be a business decision, its their money. But can they make such a decision safely? We are asking for consent to 'not operate' or 'operate' on their software. To come to the right decision, they need to be fully informed. i.e.: Are we sure that the issue is indeed rare? Are they making a properly informed decision? For example what if th

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