Skip to main content

Posts

Showing posts with the label Scientific Method

Bug Automation

In many of my clients, more effort is spent on 'test automation' than on other forms of testing or quality assurance. That can be the right choice, for example, I worked on a Data Warehousing project where we needed to write some test automation before we could test the data and its processing. Many other projects in different technology areas also spend a lot of time on their test automation. To be precise, they spend an increasing amount of time fixing & maintaining old 'tests' and 'frameworks'. There are great tools around to help us write these automated checks quickly. But as with many software systems: maintenance, in the long term, is where the time and money goes. That is why I'm surprised we don't use short term automation more. We have the skills. One good example of short term automation is Bug Automation . A simple script / executable that recreates or demonstrates a bug. This isn't a new idea, I've been doing it for year

Controlling software development

Do you ever feel like we do all this work and maybe we needn't of bothered? Things might have worked-out without our intervention. Or we are actually worse off, now, after the work? You're not alone. This is a common problem in any role where you need to investigate the effects of changes. What you're feeling is a lack of control . A control is a view of the world, without your work. It's an alternate view of the world where everything is the same except for your fix/hack/intervention. They behave like 3D TV, they let your mind's-eye 'see' the effects, by making them standout from the background. They are commonly used in scientific and especially pharmaceutical research studies. They let the researchers know how effective a treatment was, compared with similar patients who received placebo (or  older established medicine) pills rather than the new treatment. The researchers can tell whether, for example, a new flu remedy actually helped the patients. O

Why so negative?

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 .

Believing you don't know

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

The Hunky-dory Hypothesis

"If we just run it with this data, and it looks Ok, we'll know it works" the architect says expectantly, "Right?" "You're right, We might see 'it work'", "How would that help?" I answer. "Well errh, it works, so we can put it live tomorrow." We've seen this situation before; it can arrive in conversation like the above, or from a review of Acceptance Test results or in a host of other forms. The premise is: everything is fine, we've done the work - we have evidence everything is done and working. But, how can demonstrating that the application can 'work' help? How will seeing the acceptance test results as 'green' help? That might sound nonsensical, but seriously: how does it help our customer make the decision to ship [or not]? Or help them distribute people and resources better? It may seem that telling them 'its all hunky-dory' is news and good news at that, but it isn't. It