Conference Presentations

STAREAST 2000: A Risk-Based Test Strategy

Testing information systems should be based on the business risks to the organization using these information systems. In practice, test managers often take an intuitive approach to test coverage for risks. In this double-track presentation, discover how a "stepwise" definition of test strategy can be used for any test level as well as the overall strategy-providing better insight and a sound basis for negotiating testing depth.

Ingrid Ottevanger, IQUIP Informatica
Using Risk Analysis in Testing

Anne Campbell provides insight into how a risk analysis grid was effectively implemented at IDX as a device to gauge QA team performance and as a communication tool to the development team. This valuable tool listed functionality and the risk associated with it, helping IDX focus their testing in higher risk areas. Discover how a risk analysis matrix can be used to plan your testing efforts and increase the quality of your software project.

Anne Campbell, Channel Health
Improve Your Estimating Process--Beginning with a Proof of Concept

Estimating is like the weather; everyone talks about it, but no one does anything about it. This presentation provides the techniques required to execute a Proof of Concept estimating model, allowing an organization to trial run the tools, techniques, and methods required to estimate projects more accurately and earlier in the lifecycle. Learn the key elements of this approach, and obtain templates to employ in your organization.

David Herron, The David Consulting Group, Inc.
Performance Evaluation and Measurement of Enterprise Applications

Today's large-scale enterprise applications are all Web-enabled and complex in nature. Many users experience performance problems from day one. Performance evaluation and measurement via extensive testing is the only practical way to raise and address all issues prior to a successful deployment. Learn how to tackle performance and capacity issues with the appropriate testing strategy and scalable infrastructure/architecture.

Rakesh Radhakrishnan, Sun Microsystems
Critical Components of Asset Management

Examine how Information Technology (IT) asset management methodologies can reduce your organization's IT budget between five and thirty-five percent. Kathy Shoop discusses the critical components to deploy, the challenges of implementing such a program, and the limitations of asset management tools such as spreadsheets and in-house development efforts. Discover the best practices for implementing an asset management initiative in your organization that will result in immediate cost savings.

Kathy Shoop, Janus Technologies, Inc.
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
Software Test Automation Spring 2002: Test Automation With Action Words: A Practical Experience

Action Word Testing. This concept illuminates testing as an action, a process, an art. Learn how Action Word Testing can be applied to deal with critical test issues such as lack of functional knowledge of a system under test; instability of the design during test development; and automation of 100% of the functional or technical tests. Hans Buwalda uses a financial exchange that's introduced a new electronic trading system to demonstrate Action Word Testing (approximately 15,000 tests). In this example, automation of the entire test was essential, but it was difficult to achieve.

Hans Buwalda, LogiGear
A Practical Approach to Early-Cycle QA Test Automation

Everyone knows that a large body of automated unit tests for classes, subsystems, and frameworks adds to overall code quality. However, the "burden" of unit test automation is frequently placed squarely on the shoulders of developers because of the perception that only a developer can write a unit test. Since QA personnel typically test from the user interface-and usually have to wait until later in the development cycle for the availability of that interface-they're often left to scramble at the end of the cycle to get their testing done. Michael Silverstein reveals a model for early-cycle collaboration between developers and testers where testers augment the developers' unit testing activities without adding additional process overhead.

Michael Silverstein, SilverMark, Inc.
Identifying Testing Priorities Through Risk Analysis

It's impossible to test everything-even in the most trivial of systems. Tight time schedules and shortages of trained testing personnel exacerbate this problem; so do changing priorities, feature creep, and loss of resources. In many companies, test professionals either begin their work on whichever components they encounter first, or the parts they're most familiar with. Unfortunately, these approaches may result in the delivery of a system where the most critical components remain untested. Or, at the very least, critical components are tested later in the lifecycle when there may not be time to fix the problems found. All of this adds to the risk of a project. One way to overcome every one of these challenges is to employ the use of risk analysis. Rick Craig demonstrates the basics of a usable process for assigning testing priorities based on relative risk.

Rick Craig, Software Quality Engineering
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

Pages

CMCrossroads is a TechWell community.

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