Rebuilds are nearly impossible to do accurately. You need to match up the source code, and build process and hardware and build tools and .....

Today's entry discusses a practical approach to pretty good rebuilds.

Read more...

After CITCON Denver, members of the Denver testing community decided to put together their own local testing open spaces conference. Congratulations are in order for Ben Simo and Heidi Harmes-Campbell who did a fantastic job getting the conference off the ground.

Agile methodologies were a big topic both in sessions and in the hallways throughout the conference. I was struck by a consistency between horror stories of switching to agile and the success stories. When the developers and testers worked closely together, Agile methodologies tended to work pretty while. When the developers and testers were kept far apart - or were outright antagonistic towards each other, experiments with Agile tended to fail. Short iterations simply don't leave enough time for poor communication or petty squabbling. Developers and testers need to work closely together (often literally) to be successful and keep everyone able to contribute well through the whole iteration.

Automated functional testing was a popular topic as well and the session on maintainable automated tests was excellent. Ruby seems to be increasingly the language of choice for building open source based test harnesses with Waitr getting a good deal of attention at the conference. Most teams still seem to have limited amount of automation but even the teams not doing much automated testing seem to be looking into it. Automated tests are ideal for basic regression testing and should free the time of manual testers who were doing that regression work to find bugs hidden deeper in the applications.

I did see limited awareness and interest in continuous integration and life cycle automation from most of the testers.  As automated testing starts playing a bigger and bigger role, integrating those tests into the rest of the build and release process will be a more obvious activity. In the meantime, those of us in the CI community need to do a better job reaching out to testers rather than just developers and release managers.

It was great to see another open spaces meeting in action and interact with Denver's testing community. - Eric Minick

One technique that we are seeing more and more often with larger customers is the automatic creation of projects. This core idea of this approach is to develop a very consistent way of implementing the life-cycle for a class of projects so that adding a new project requires only a handful of changes from a previous project. These values might be things like build target, source control information, and numbering information.

Historically, teams that were doing this well would copy the existing project, trim out old, unneeded branches and make the handful of changes needed. Five or ten minutes later they had a new project ready to build for the first time. Pretty good, but not good enough for everyone.

Some groups are automating this process using the AnthillPro API. Some are using the operational projects introduced in 3.5 to do this. An operational workflow that takes a template project from a drop down, and then prompts for the values that change project to project. Other teams came to AnthillPro with project description files of one sort or another, that they parse and use to create projects using the remote scripting API. Others are using XML files that they've created to do the same thing. Some are using a combination of techniques. A source control trigger like the ones that start builds are used to start a configuration workflow whenever a new XML file is dropped into source control. The file is picked up, parsed out and then a new project is created based on it's contents.

Automatic project creation is a very nifty trend, but is it needed in order to be successful with AnthillPro? No. Not at all, but getting the project configurations consistent enough so that automatic project creation would be possible is absolutely a goal worth pursuing.