Want to automate your tests but don't have the budget for big-league tools? Elisabeth Hendrickson offers case studies where test automation was accomplished with simple tools for small budgets. She delivers practical advice for creating the automation you need from the tools you already have or can easily get your hands on. Fact is, everything you need to get started is probably right in your "kitchen drawer."
Elisabeth Hendrickson, Quality Tree Software, Inc.
Can test automation really advance your testing mission? The answer to that question is a resounding "That depends!" But to make it happen you have to provide value to development and find new ways of testing. Bret Pettichord offers lessons from the the trenches in building powerful test suites. He shares his experiences as well as those of other test automators to help you avoid the pitfalls others have already stumbled onto.
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.
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.
"This isn't what I need," states Customer Bob. "But it's what you said you wanted," replies Engineer Joe. "It's not right. I need something else." We've all encountered this classic users-don't-know-what-they-want scenario. The fact that software professionals continue to have this same experience over and over again suggests that we're overlooking the real reasons for the user/engineer disconnect. This presentation contrasts the different uses of the term "requirements" as it explores the possible solutions to improving understanding between business people and technical people.
The preparation of a realistic, practical project schedule is an essential management function for obtaining stakeholder commitment, setting expectations, and communicating within the team and organization what is achievable. Doing this preparation well is another challenge-one that must be conquered. Rex Black helps participants see the bigger project scheduling picture by focusing on issues such as constituent tasks, the underlying dependencies between them, and the risks attached to the completion of those tasks.
Wireless testing is closely related to Web testing, but they are not twins. While wired Web access has settled on a handful of platforms with a few dominant operating systems, the wireless world is still a riot of platforms with a small number of operating systems and a myriad of browsers. There's also no way to test a wireless tool directly the way you can a Web site, because the tools rely primarily on emulators. Geraldine Conley talks about these and other surprising experiences in the wireless testing arena. She also covers the testing processes most affected by wireless technology: document reviews, the change control board, and configuration management.
How do you know when a product is ready to ship? QA managers have been faced with this question for many years. Using the methodology discussed in this presentation, you take the guessing out of shipping a product and replace it with key metrics to help you rationally make the right decision. Learn how to estimate, predict, and manage your software project as it gets closer to its release date. Learn how to define which metrics to track--and how to measure them. Discover how to define the ratings scale for each metric and how to create a spider chart for product readiness. This presentation is a must for any individual or organization that is serious about maximizing the results of positive events and minimizing the consequences of adverse ones.
Configuration management has long been a staple activity for large, traditional software engineering projects but has been markedly absent from most Web development projects. This presentation gives a brief overview into configuration management from a tester's perspective. Learn of the costs, drawbacks, and benefits of configuration management. Discover quick and simple ways your testing staff can add configuration management to your Web development environment.
How do you know when you're finished testing? How do you know when the product is ready to ship? Sometimes the decision to stop testing and release a product seems as if someone's making deals in a smoke-filled room, or that there are rules of the game of which we are unaware. At times, these rules seem completely arbitrary. Instead of arbitrary decisions, it is possible to come to an agreement about when the product is ready to release, and even when it's time to stop testing. In this presentation, learn how to define release criteria, and then use those criteria to decide when to release the product.