investigating software

Have you ever had trouble explaining to a non-tester why you appear to be intent on breaking their software? It can be difficult to explain why it's important. So I thought a video might help... If you want to read more about the scientific method, check out the hunky-dory hypothesis .

People want to believe. If you are a tester then you've probably seen this in your work. A new build of the software has been delivered. "Just check it works" you're told, It's 'a given ' for most people that the software will work. This isn't unusual, it's normal human behaviour. Research has suggested  that it's in our nature to believe first. Then secondly, given the opportunity, we might have doubt cast upon those beliefs. We see this problem everywhere in our daily lives. Quack remedies thrive on our need to believe there is a simple [sugar] pill or even an mp3  file that will solve our medical problems. Software like medicine is meant to solve problems, make our lives or businesses better, healthier. Software release are often presented to us as a one-build solution to a missing feature or a nasty bug in the code. As teams, we often under-estimate the 'unknown' areas of our work. We frequently under-estimate the time taken to

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 ,

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

At a client site, a few years ago, I had an interesting discussion with a 'senior programmer'. Our discussion centred on a configurable home-page. A user could decide what news or other information etc, they wanted to display on their home page. They'd start off by being given a generic page - and the customer could add or remove certain types of content to customise their page. Once they saved the 'new look' site, their choices would be saved on the web-server. The company didn't want to force people to login, or even make them sign-up for an account. The goal was to keep it simple for the user. But they needed a way to uniquely identify the users, so they used an existing feature of the website. The first time a user came to the site, they were cookied with a 'unique' id 'code'. We could then use this identifier as a key in our database to store the details of what the users had configured their homepage to look like. The testers reading th

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