|
|
STAREAST 2003: Implementing a Test Automation Framework This paper discusses how to properly implement a test automation framework. You will learn keys to automation success, how to design test library architecture, and how to develop project implementation models.
|
Linda Hayes, WorkSoft
|
|
|
A Positive View of Negative Testing Negative testing is a core skill of experienced testers, and requires an opportunist, exploratory approach to get the best value from the time spent. It can find significant failures and produce invaluable strategic information about the risk model underlying testing, and allow overall confidence in the quality of the system. Negative testing is open-ended and hard to plan granularly. It needs to be managed proactively rather than over planned. Although negative testing is a powerful and effective approach, it is also a hard-to-manage task that has the potential to produce unwelcome information. In this paper, James Lyndsay explains the value of using this testing method.
|
James Lyndsay, Workroom Productions
|
|
|
Building Executable Software Test Specifications This paper discusses how executable software test specifications can help you reach project goals, and offer solutions to three common software problems. You will also learn how to articulate software development goals so they can be shared by product and test developers.
|
Michael Corning, Microsoft Corporation
|
|
|
Testing Microsoft.NET Applications This paper will teach you how to build testing processes from lessons learned and best practices. Solutions are recommended to help enhance your .NET programming experience.
|
Al Rago, Olenick & Associates
|
|
|
Seven Habits of Highly Insecure Software Many security bugs escape traditional testing techniques and the authors wanted to find out why. They studied thousands of real security bugs. They asked themselves what the cause of the bugs were and how they could have found them during testing. This paper explains what they found and how your team can benefit from it.
|
Herbert Thompson, Security Innovation LLC
|
|
|
Testing Success or Failure - It's Up to You This paper discusses how you can move as many dangers out of the testing minefield as possible. You'll also learn how to limit the impact of the dangers you cannot move so you will be able to maximize the time you spend testing. Following these guidelines will also help you increase the effectiveness of your testing.
|
Donna O'Neill, IV&V Australia
|
|
|
Interoperability Testing with Java Web Services This paper discusses why it is important to test for interoperability.
|
Vinay Pai, Sun Microsystems
|
|
|
Blueprint for QA and Testing a Typical Enterprise Application in 2004 This paper provides a QA blueprint for testing enterprise applications in 2004. Many diagrams and examples are also included.
|
Frank Cohen, PushToTest
|
|
|
STAREAST 2003: Surviving the Top Ten Challenges of Software Test Automation In this paper, Mr. Rice discusses what it takes to survive the top ten challenges of software test automation. Detailed explanations of solutions to these common problems facing teams are also included.
|
Randy Rice, Rice Consulting Services Inc
|
|
|
Testing in the XP Paradigm: A Case Study The application in this case study is a new Web application developed for a Fiduciary Trust company. The company had been assured by their eXtreme developers that testers were unnecessary in this Web project. Since the risk of project failure would be measured in millions of dollars in lost business, someone thought it a good idea to risk a few hundred on a second opinion. This turned out to be a good risk for them and a really good opportunity to measure the
cost of not testing. This paper gives the account of what happened when this application went on line, and presents
a review of the test log, and the bugs reported. Because of the nature of the project and the type of failures that occurred, this project provided a unique opportunity to calculate the cost of not testing and the value of testing in terms of customer support dollars that would have been spent without testing and the that were saved because of testing.
|
Marnie Hutcheson, Ideva
|
