Blogs

Exactly what to do in your test program is context-dependent. Don’t take this as the way to create a test program, but instead as one way, a way I have seen work at several companies, paying less for testing and getting better results than their peers. Some of the readers here won’t really have a test “program,” not

A few years ago I worked with a team implementing a continuous integration system. The system was pretty simple. It checked out the code and ran unit-tests, then waited an hour to run again. The manager counted not only the number of passing assertions per day, but also the growth rate. Of course, some programmer

One of the barriers to organizations embracing Codeless Test Automation has been the lingering question of how to manage legacy tests written in other testing frameworks. For most organizations, that means Selenium. The prospect of recreating thousands of Selenium tests, even using a codeless solution, is understandably daunting and has been a barrier to many

Retrofitting a test automation tool on top of an existing application is no joke. As Fred Brooks puts it in the software engineering classic The Mythical Man Month, many a dinosaur has died in those tar pits. Unlike the dinosaurs of old, we keep re-creating the problem with automation projects. Even if we start the development

You hear it at the conference, in the session with the performance consultant. It all sounds so helpful. She points out that you already have functional test automation. Those run through realistic scenarios, end to end. So put them on a grid, maybe in the cloud, then use them as the basis of your load

The Agile Manifesto has twelve principles, that include “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” For its time, the Manifesto was revolutionary. Today, that speed seems quaint. Agile Machismo has taken over, with one-week sprints better than two, and continuous deployment,