Conference Presentations

The Next Stop in Test Automation: Test Environment Setup

To achieve the most effective test automation, you need to go beyond automated test case creation and implement automated environment setup. In tracking the testing time spent over several projects, the Clustering group Amit Mathur worked with found that more staff time was being spent on setup than on actual testing. He discusses and demonstrates the Environment Configuration System (ECS) his group developed to automatically set up test environments and trigger automated test execution. Find out how ECS has dramatically improved the ability to automate many more manual tests. ECS employs a scripting language (Perl) and libraries for environment setup and test cases. Based on interface specifications and dependency rules, ECS bundles environment setups and test cases for complex test scenarios. Learn how you can adapt the ECS approach for your applications and environment.

Amit Mathur, VERITAS Software Corporation
How Much Quality is Enough?

Are you striving for more quality than you really need? How would you know? "Good enough" quality does not mean "substandard" or "mediocre" but is actually an optimal and responsible economic principle we use everyday. Managing test lead for Quardev Laboratories, Jon Bach says because quality is expensive, the "good enough" framework provides the criteria to enhance decision-making about when to ship. He discusses the perils of quality-at-all-cost techniques and shares examples of software that features sufficient quality. Find out how testers and test managers can help project stakeholders know whether they are releasing software with too little quality or are unnecessarily striving for too much quality.

Jon Bach, Quardev Laboratories
It's 2005, Why Does Software Still Stink

We've now been writing software for an entire human generation. Yet software is arguably the least reliable product ever produced. People expect software to fail, and our industry has developed a well-deserved and widely accepted reputation for its inability to deliver quality products. James Whittaker explores the history of software development over the last generation to find out why. He uncovers several attempts to solve the problem and exposes their fatal flaws. James then looks forward to a world without software bugs and offers a roadmap-practical techniques that can be implemented today-for how to get there from here. Join James on this journey through the past and into the future-and be sure to bring something to scrape the bugs off your windshield.

James Whittaker, Florida Institute of Technology
Choosing the Best of the Plan-Driven and Agile Development Methods

We seem to be under a curse in our profession. Although not cast by a witch or a wizard, the curse affects us just the same. It is the curse of "either/or"-the curse that we must choose either "this" or "that" but we cannot choose parts of both. Nowhere is this more evident than in today's struggle between the adherents of the traditional "plan-driven" and newer "Agile" approaches to software development. What most overlook is that both groups want to achieve exactly the same goal: quality software that meets customer needs within the constraints of time, budget, staff, and technology. They differ only on the strategies to achieve this goal. For example, both groups agree that system requirements must be understood; their differences lie in questions of "how much of what to do and when to do it." Lee Copeland offers insights and suggestions on the methods and approaches that will be most valued on your project-control vs.

Lee Copeland, Software Quality Engineering
Six Impossible Truths about Developing Software - All Before Breakfast

Alice laughed. "There’s no use trying," she said, "one can't believe impossible things."

"I daresay you haven't had much practice," said the Queen. "When I was younger, I always did it for half an hour a day. Why, sometimes I've believed as many as six impossible things before breakfast."

--Alice in Wonderland

Tim Lister, Atlantic Systems Guild, Inc
Transitioning to Agile Development

The Agile development movement has started to transform the software landscape. Since February 2001 when the Agile Manifesto was published, Agile development has gone past the early adopter phase and now is regularly in use by such mainstream organizations as CapitalOne, the Federal Reserve Bank, Microsoft, Sun Microsystems, and major development departments in other organizations. For Agile practices to take hold-and more importantly to be sustained-all of the dysfunctional behaviors that organizations have acquired over the past twenty years or more must be discarded-and that is not easy or fun. However, the overwhelming benefits and value of Agile development are there, and for organizations in which software is their lifeblood, the effort will be made.

Jean Tabaka, Rally Software Development
Building a Requirements Foundation with Customer Interviews

Whether you are building a brand new product or evolving an existing system, understanding the business needs of your customers is the foundation of a marketable product or valuable internal application. Few of us are experts in interviewing techniques, and few customers talk about their tasks, needs, and context in neat, concise statements about requirements. Hone your elicitation skills and learn what it takes to get beneath the surface and understand your customers: their world, how they work, and what really bothers them. With effective interviewing techniques and skills, you will get inside their heads and better understand their needs within their context.

Esther Derby, Esther Derby Associates Inc
Negotiating the Defect Minefield for a Successful Product Release

Software success is strongly influenced by how you finish a project. For that, a special set of skills is required. Many projects fail in their endgame during testing, not because of the testing itself but because of the late discovery of defects and functional gaps that show the software as not viable. Join Robert Galen as he focuses on a set of high level practices and techniques that will help improve your management and steering within the endgame. Learn about a release framework with the right testing tempo and key milestones. Define formal release criteria and add flexibility and depth to your defect fix-don't fix decisions. As a manager in the difficult release endgame, your behavior and leadership can make the difference between a successful release and perceived failure. Robert’s guidance will increase the odds of successfully delivering your release.

Robert Galen, Thomson/Dialog
Twelve-Step Program for a Better Test Process

We can't make software better by testing the quality into it. However, if we manage our testing processes and educate the rest of the team about what it takes to make better software, we can make a difference. First, we have to get the testing world under control and work to reasonable expectations; then, we can spread the word to the rest of the organization. Judy McKay describes how to gain control of the test process-while still getting the real work done-and shares ways to educate the rest of the team about quality awareness. Using Judy's twelve-step program, test managers and testers will regain their sanity as they take control of the testing workflow and share it with the project team. By allowing developers to become part of your world, quality assurance can become a reality in your organization.

Judy McKay, Test & Automation Consulting LLC
(Almost) Painless Code Reviews

Peer code review is universally acknowledged as a valuable practice that often catches 60 percent to 90 percent of the bugs in code. So why would most developers rather be poked in the eye with a sharp stick than attend a Fagan style inspection meeting? Take a cue from the crowd working on Wine (www.winehq.com), an open source implementation of the Windows API. The Wine team has evolved code review practices to avoid the chaos and poor communication that can result from a team of part-time developers distributed across the globe. Frederic Boulanger explains how to adapt the Wine code review system to the needs of a commercial software development team. The "single committer" review method improves code quality, helps keep errors out of source control, and quickly integrates new developers into your team.

Frederic Boulanger, Macadamian Technologies Inc

Pages

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.