|
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
|
|
The W Model Strengthening the Bond Between Development and Test In software development, thirty to forty percent of all software activities are testing related. That is why it is critical to launch test activities at the beginning of the project rather than after coding is completed. Based on the Vmodel, this paper describes a model that shows how the tasks for testing relate to the tasks in the development model. This testing model-the W-model further clarifies the priority of the tasks and the dependence between the development and testing activities. Though as simple as the V-model, the W-model makes the importance of testing and the ordering of the individual testing activities clear. It also clarifies that testing and debugging are not the same thing.
|
Andreas Spillner, Hochschule Bremen and Karin Vosseberg, Specialists
|
|
The Context-Driven Approach to Software Testing Several jokes about consultants revolve around the idea that they answer most questions by saying "It depends." The context-driven school of testing accepts the "It depends" reality but then asks, "Depends on what?" Rather than talking about best practices, this approach asks when and why a given practice would be beneficial; what risks and benefits are associated with it; what skills, documents, development processes, and other resources are required to enable the process; and so on. Rather than dismissing an unpopular testing technique or test documentation method as useless, you should ask these questions to determine possible uses. The appropriate context might be narrow, but you'll learn a lot more about the technique and its alternatives by becoming aware of the context variables rather than ignoring them.
|
Cem Kaner, Florida Institute of Technology
|