Conference Presentations

Taking Test Automation Mainstream

By now, most test organizations have implemented at least one test automation tool. However, the success of these tools is by no means guaranteed. Why is it that these products often fail to meet their potential? What can managers do to increase the tool's return on investment? Andrew Pollnew helps you with ways to ensure that tools support rather than hinder you. He discusses a number of common-but-flawed approaches to automation, then explains how to change them.
Andrew Pollner, ALP International Corporation
Adopting XP

Extreme Programming (XP) takes practices that are known to be good and combines and applies them in a revolutionary way. Before you turn your team on to XP, check out the steps to take, and pitfalls to avoid, to make your project an "Xtreme" success.
C. Keith Ray
August 1, 2002
Focused Improvement

Improving processes takes planning, time, and effort. A formal improvement project that applies the best practices of development to process improvement can help focus your team and effect real and lasting change.
Karen King
August 1, 2002
Agile Meetings

Does the thought of going to yet another meeting make your head spin? Read about how to increase your team's productivity by making your meetings short, frequent, and focused.
Linda Rising's picture Linda Rising
July 30, 2002
Ken Schwaber on Agile Processes

Agile processes are founded on an empirical model of process control theory, and they deliver value iteratively and incrementally. Customers and development teams collaborate to wrest the greatest value from advanced technologies and emerging requirements, which practitioners call "value-driven" software development. Here, the developer of the agile process Scrum gives his recommendations for sources on agile processes.
Ken Schwaber
July 30, 2002
Tinkerable Software

In what ways should software be like a house? In a recent issue of STQE magazine, Technical Editor Brian Marick’s musings about the concept of “tinkerable software” generated some interesting discussion about the very nature of software design. This week’s column runs a portion of that piece so that our Sticky-minded readers can sink their thoughts into the concept.
Brian Marick
July 30, 2002
Testing Mission Critical Software Changes

This paper is based on a recent experience implementing and testing a large new software capability in a
maintenance organization which had not dealt with a large change in some time. The capability was called
GPC Payload Command Filter (GPCF). While the task was completed successfully, it was not without
cost in terms of schedule slips and personal angst.
The purpose of this paper will be to help the verifier learn from what was done right and what was done
wrong, hopefully to avoid the pitfalls and emulate the successes. Specifically, the objective is as follows:
To provide guidance on how to successfully test a large new software capability using verification processes which have specialized over time to provide extremely effective results
for relatively small changes.
Alan Ogletree, United Space Alliance
Testing Your Software's Requirements

Many testing organizations focus primarily on software executable code, but that's not the only thing you can test. For instance, did you ever consider testing your software requirements? When you test only code, you face some big disadvantages, not to mention that design defects often aren't even fixable because they demand too much effort, too late in the release cycle. In fact, it's difficult to even report some requirements defects since the developers have already committed to the design strategy. But if you test your requirements early in the game, you can discover defects before they're cast into designs and code, consequently saving your organization potentially huge rework costs.
Brian Lawrence, Coyote Valley Software
Going Beyond QA: Total Product Readiness

The successful release of software requires more than just testing to ensure the product functions properly; success is also defined by how prepared the product is for advertisement, delivery, installation, training, support, etc. In this paper, we’ll discuss how testing can be expanded to cover all aspects of Total Product Readiness (TPR).
Douglas Thacker, Liberty Mutual Insurance Group
What's That Supposed to Do? The Archeology of Legacy Systems

In testing utopia, all software products submitted for testing have thorough and comprehensive documentation describing how every program function should work. On planet Earth, however, test engineers usually have to make do under less-than-ideal circumstances. It's not uncommon for test engineers to be asked to verify the functionality of a critical legacy system which has no documented requirements whatsoever. While there are many reasons this can happen, the result is the same: You assume the role of an archeologist sifting through the layers of clues to reconstruct the specifications. Patricia Ensworth gives you instructions and tools so you'll be ready to roll up your sleeves and dig.
Patricia Ensworth, Moody's Investors Service

Pages

CMCrossroads is a TechWell community.

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