Zenergy Technologies recently exhibited at one of these conferences last week in Las Vegas, the Agile Development Practices Conference. Hosted by SQE, publisher of Better Software Magazine and StickyMinds, this conference provided the leadership at Zenergy a chance to do one of its favorite things: take the pulse of the software development community, specifically, a segment of the Agile populace.

As attendees visited our booth in search of information about our company and solutions, tchotchkes, and the iPad we planned to give away at the SQE drawing, although not necessarily in that order—we know most people just wanted the iPad; we wanted one too—we took the opportunity to ask them how long they had been using Agile methodologies. While our survey was by no means scientific, the answers pointed to the fact that the majority of attendees we met with had been using Agile for about 18 months, long enough to begin to feel at ease after having stepped outside their comfort zone of the traditional waterfall methodology, but still new enough to experience a variety of challenges. Three challenges in particular were popular topics at our booth:

• NUnit

• JUnit

• FitNesse

• Selenium

• Ruby Watir

Our recommendation to the company when evaluating the available automation software, was to consider them falling into one of three categories:

For example, some common risks you find in test plans include: 

• Requirements are incomplete and/or ambiguous
• There are limited testing resources available for the project
• Previously established deadlines for other activities have been allowed to slip, but QA’s execution start and completion dates remain fixed 

When identifying risks and determining contingencies for inclusion in a test plan, it’s important to go beyond the standard issues and evaluate the ones likely to occur. To do this, it may be helpful to view risks as falling into one or more of the following categories:

• Identifying test objectives and scope
• Assessing and accounting for risks and contingencies
• Determining component/application priorities
• Estimating the size/length of the test effort

For starters, the workshop facilitator discussed the importance of test planning, even in lean/agile development shops. Although test planning is imperfect because it involves assumptions and estimates in areas where too many variables lie outside our control, the act of planning provides teams with insight into their needs, constraints, and capabilities, thus defining a roadmap of activities we can manage to. 

One of the early points made was test teams tend to develop the objectives of a test effort without truly considering or understanding the needs of the business. That is, we tend to focus on what we think we can/should test and don’t account for how well those items might align with the business’ objectives. For example, some common test objectives might include the following:

• Execute all new functional tests to identify defects introduced during the development of the application.
• Perform load, volume, and stress testing to identify system performance constraints.
• Utilize exploratory testing to identify latent defects in module <x> of the application.

Honestly, there is nothing wrong with any of these test objectives, but the question is, are they important to the business goals? Or, by focusing on these objectives, do we

Citcon was interesting because it runs the conference using Open Space. If you are not familiar with the concept, you can read about it in detail here, but the general idea is the conference participants set the agenda by proposing subjects they want to discuss, then everyone votes on the topics. Some attendees volunteer as facilitators, typically individuals who are familiar, if not experts on the agreed upon topics, but the ensuing sessions are essentially discussions where ideas and information flow freely back and forth. At first, I was skeptical of the Open Space format,