|
|
 |
Featured Sessions and Speakers
| WEDNESDAY, MAY 15, 9:15 AM | Identifying Testing Priorities Through Risk Analysis
Rick Craig, Software Quality Engineering
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. He helps you ensure the capability of your test team to do a reasonably comprehensive test, no matter what the circumstance. |
 | | Rick Craig is an experienced test manager, consultant, and lecturer. He’s helped hundreds of companies improve their testing in countries throughout Europe, Asia, Australia, and the Americas and has been a featured speaker at testing conferences since 1983. He’s also the former American editor of Software Quality Management magazine and the co-author of the Systematic Software Testing Handbook. He’s currently a colonel in the United States Marine Corps Reserve. |
| | WEDNESDAY, MAY 15 , 10:30 AM | Testing Large Mission-Critical Software Changes
Alan Ogletree, United Space Alliance, Space Shuttle Software Testing
For those in a maintenance organization tasked with a large coding or testing project, the tendency might be to continue to use an existing (proven) small-change process and simply apply it on a larger scale. While reasonable in concept, this type of application is difficult to do in practice. Alan Ogletree discusses strategies for managing the transition from testing routine, small-capability upgrades to testing a major software change. Based on his experience with the on-board space shuttle software, he gives you things to consider when planning a large software change. You’ll cover the areas of requirements, code, expertise, planning, attitude, and process. |
 | | Alan Ogletree is a lead software tester at the United Space Alliance (USA), LLC, in Houston. USA is the prime contractor for NASA’s Space Shuttle program and has overall responsibility for the shuttle’s central computing system, the Primary Avionics Software System (PASS). Alan has spent the past 18 years working on the PASS, initially with IBM then with Loral and Lockheed Martin, before joining the USA team in 1998. Alan holds a bachelor’s degree in computer science from Louisiana State University. |
| | WEDNESDAY, MAY 15, 4:30 PM | Retrospectives: They’re Not Just for Developers Anymore
Esther Derby, Esther Derby Associates, Inc.
Traditional methods for improving testing include training, hiring, adding new processes, building infrastructure, and buying new tools. But what about increasing the capability of the team? Author Aldous Huxley said, “Experience is not what happens to a man; it is what a man does with what happens to him.” The same is true for software teams: It’s what we do with our experience that matters. Too often, we don’t do much — if anything — to squeeze learning out of our experience. Retrospectives are a way to take the “what happened” during a software project and use it to build understanding. Testing borrows a page from adult learning theory and project reviews to increase team capability through Testing Retrospectives, and determines how to do more of what worked and less of what didn’t. |
 | | Esther Derby has more than 20 years of experience in software development, including roles as an application developer, systems manager, and project manager. Currently, she’s a consultant, writer, and facilitator who works with individuals and teams to plan projects and increase team capability. She’s also a frequent speaker and technical editor for STQE magazine. |
| | THURSDAY, MAY 16, 9:00 AM | Automated Web Testing Strategies
Linda Hayes, WorkSoft, Inc.
As Web applications move from static content to dynamic transactions, the risk of failure increases while cycle time collapses. Although automation is the ideal solution for this combination, those who’ve ventured into automated Web testing have discovered a whole new world of unexpected challenges. For instance, dynamic page layouts and content frustrate test automation requirements for predictability and repeatability, while the lack of meaningful — let alone consistent — object names further complicates consistent execution. Ultimately, this leads to excessive maintenance and lower productivity. This presentation shows you how to identify the potential issues that come with automated Web testing, then offers ways for you to incorporate site and test development strategies to overcome them. |
 | | Linda Hayes is CEO of WorkSoft, Inc., a software company specializing in test automation. She has more than 19 years of experience in software quality and testing and holds degrees in accounting, tax, and law. Linda is a frequent speaker and award-winning author of books and articles, including a monthly column in Datamation. |
| | THURSDAY, MAY 16, 3:45 PM | Enterprisewide Testware Architecture
Mark Fewster, Grove Consultants
Testware: the stuff of which tests are made. The term comprises a bewildering range of artifacts including data files, scripts, expected results, specifications, and environment information. It also implies how these artifacts are arranged, where they’re stored and used, and how they’re grouped and referenced. Since testware architecture has not traditionally been considered an important issue, individual projects and teams, even individual testers, have evolved their own approaches to the arrangement of their testware, resulting in much wasted effort. Of course, different applications and environments may demand unique testware architectures, but do they have to be so different? Isn’t there a single, unified, flexible, and expandable approach that fits most, if not all, situations within an enterprise? Perhaps not, but the goal of uniform testware architecture across projects is certainly worth striving for. This presentation explains the key elements of good testware architecture and sheds light on ways of achieving a consistent approach across diverse projects. |
 | | Mark Fewster has more than 20 years in the software industry. He’s held positions from programmer to development manager and now works as an independent consultant with Grove Consultants specializing in software testing. Mark serves on the committee of the British Computer Society’s Specialist Interest Group in Software Testing and has been a member of the Information Systems Examination Board (ISEB) developing a qualification scheme for testing professionals. He co-authored the book Software Test Automation with Dorothy Graham. |
| | FRIDAY, MAY 17, 9:00 AM | The Context-Driven Approach to Software Testing
Cem Kaner, J.D., Ph.D., Florida Institute of Technology
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, one of the founders of the context-driven school of software testing, explains the principles of context-driven testing and provides examples of the types of questions used to establish the context in a given situation. |
 | | Cem Kaner is professor of computer sciences at the Florida Institute of Technology, and an attorney whose work focuses on the law of software quality. Cem is the senior author of three books:Lessons Learned in Software Testing: A Context-Driven Approach, Testing Computer Software, and Bad Software (What To Do When Software Fails). |
|
