|
|
|
|
 |
|
|
| |
|
|
STAREAST 2010 Pre-conference Tutorials
|
|
|
|
| Many organizations never achieve the significant benefits that are promised from automated test execution tools. What are the secrets to test automation success? There are no secrets, but the paths to success are not commonly understood. Dorothy Graham describes the most important automation issues that you must address, both management and technical, and helps you understand and choose the best approaches for your organization—no matter which automation tools you use. If you don’t begin with good objectives for your automation, you will set yourself up for failure later. If you don’t show return on Investment from automation, your automation efforts may be doomed, no matter how good they are technically. Join Dorothy to learn how to identify achievable and realistic objectives for automation, show ROI from automation, build a testware architecture for future scalability, pick up practical tips for technical issues, learn what works in practice, and devise an effective automation strategy. |
 |
| Learn more about Dorothy Graham |
|
|
|
|
|
|
| The key to successful testing is effective and timely planning. Rick Craig introduces proven test planning methods and techniques, including the Master Test Plan and level-specific test plans for acceptance, system, integration, and unit testing. Rick explains how to customize an IEEE-829-style test plan and test summary report to fit your organization’s needs. Learn how to manage test activities, estimate test efforts, and achieve buy-in. Discover a practical risk analysis technique to prioritize your testing and become more effective with limited resources. Rick offers test measurement and reporting recommendations for monitoring the testing process. Discover new methods and develop renewed energy for taking test management to the next level in your organization. |
 |
| Learn more about Rick Craig |
|
|
|
|
|
|
| Critical thinking is the kind of thinking that specifically looks for problems and mistakes. Regular people don't do a lot of it. However, if you want to be a great tester, you need to be a great critical thinker, too. Critically thinking testers save projects from dangerous assumptions and ultimately from disasters. The good news is that critical thinking is not just innate intelligence or a talent—it's a learnable and improvable skill you can master. James Bach shares the specific techniques and heuristics of critical thinking and presents realistic testing puzzles that help you practice and increase your thinking skills. Critical thinking begins with just three questions—Huh? Really? and So?—that kick start your brain to analyze specifications, risks, causes, effects, project plans, and anything else that puzzles you. Join this interactive, hands-on session and practice your critical thinking skills. Study and analyze product behaviors and experience new ways to identify, isolate, and characterize bugs. |
 |
| Learn more about James Bach |
|
|
|
|
|
|
| What does it take to properly plan, implement, and report the results of a performance test? What factors need to be considered? What is your performance test tool telling you? Do you really need a performance test? Is it worth the cost? These questions plague all performance testers. In addition, many performance tests do not appear to be worth the time it takes to run them, and the results never seem to resemble—yet alone predict—production system behavior. Performance tests are some of the most difficult tests to create and run, and most organizations don’t fully appreciate the time and effort required to properly perform them. Dale Perry discusses the key issues and realities of performance testing—what can and cannot be done with a performance test, what is required to do a performance test, and how to present what the test “really” tells you. |
 |
| Learn more about Dale Perry |
|
|
|
|
|
|
| Through the years, studies have shown that poor requirements are one of the most significant contributors to project failure—and that half of all defects have their origin in bad requirements. We know that the earlier a defect is found, the cheaper it is to fix. Our experience tells us that if specifications are ambiguous, there is nearly a 100% chance that there will be one or more defects in the corresponding code. Richard Bender explains how to review specifications quickly and quantitatively to identify what is unclear about them. Learn how your feedback can lead to early defect detection and future defect avoidance. Discover how applying these review techniques can reduce the ambiguity rate by 95% on subsequent specifications and how that translates into a significant reduction in the number of defects in the code even before testing begins. Join Richard to learn how this process also can be applied to design specifications, user manuals, training materials, and online help, as well as agreements and contracts ensuring clarity of communications. |
 |
| Learn more about Richard Bender |
|
|
|
|
|
|
| Traditional test plans are incompatible with agile software development because we don't know all the details about all the requirements up front. However, in an agile software release, you still must decide what types of testing activities will be required—and when you need to schedule them. Janet Gregory explains how to use the Agile Testing Quadrants, a model identifying the different purposes of testing, to help your team understand your testing needs as you plan the next release. Janet introduces you to alternative lightweight test planning tools that allow you to plan and communicate your big picture testing needs and risks. Learn how to decide who does what testing—and when. Determine what types of testing to consider when planning an agile release, the infrastructure and environments needed for testing, what goes into an agile “test plan,” how to plan for acquiring test data, and lightweight approaches for documenting your tests and recording test results. |
 |
| Learn more about Janet Gregory |
|
|
|
|
|
|
|
The nature of exploration, coupled with the ability of testers to rapidly apply their skills and experience, make exploratory testing a widely used test approach—especially when time is short. Unfortunately, exploratory testing is often dismissed by project managers who assume that it is not reproducible, measurable, or accountable. If you have these concerns, you may find a solution in a technique called Session-Based Test Management (SBTM), developed by Jon Bach and his brother James to specifically address these issues. In SBTM, testers are assigned areas of a product to explore, and testing is time-boxed in “sessions” that have mission statements called “charters” to create a meaningful and countable unit of work. Jon discusses—and you practice—the skills of exploration using the SBTM approach. Jon demonstrates a freely available, open source tool to help manage your exploration and prepares you to implement SBTM in your test organization.
 Laptop Required.
|
 |
| Learn more about Jon Bach |
|
|
|
|
|
|
| How do you estimate your test effort? And how reliable is that estimate? Ruud Teunissen presents a practical and useful test estimation technique related directly to the maturity of your test and development process. A reliable effort estimation approach requires five basic elements: (1) Strategy – Determine what to test (performance, functionality, etc.) and how thoroughly it must be tested. (2) Size – Yes, it does matter—not only the size of the system but also the scope of your tests. (3) Expected Quality – What factors have been established to define quality? (4) Infrastructure and Tools – Define how fast you can test. Without the proper organizational support and the necessary tools, you’ll need time you may not have. (5) Productivity – How experienced and efficient is your team? Join Ruud to improve your test estimations and achieve more realistic goal setting and test strategies. |
 |
| Learn more about Ruud Teunissen |
|
|
|
|
|
|
|
Designing test cases is a fundamental skill that all testers should master. Rob Sabourin shares graphical techniques he employs to design powerful test cases that will surface important bugs quickly. These skills can be used in exploratory, agile, or engineered contexts—anytime you are having problems designing a test. Rob illustrates how you can use Mindmaps to visualize test designs and better understand variables being tested, one-at-a-time and in complex combinations with other variables. Through a series of interactive exercises, he presents the Application-Input-Memory (AIM) heuristic. You’ll use FreeMind, a widely available free, open-source tool, to help implement great test cases and focus testing on what matters to quickly isolate critical bugs. If you are new to testing, these techniques will remove some of the mystery of good test case design. If you’re a veteran tester, these techniques will sharpen your skills and give you some new test design approaches.
Laptop Required. Participants are requested to bring a MS-Windows notebook computer in order to participate in classroom exercises.
|
 |
| Learn more about Rob Sabourin |
|
|
|
|
|
|
| Cause-Effect Graphing is the most rigorous of all software testing approaches. It identifies missing requirements and logical inconsistencies in the specifications and is the only software testing technique that addresses the problem of defect observability—multiple defects can cancel each other out in a test execution or that something going right on one part of the path hides something going wrong elsewhere. Richard Bender demonstrates how test cases generated from the graphs are not only highly optimized, but they also guarantee that if there is a defect anywhere in the logic that it will show up at an observable point. All other test design techniques focus only on reducing the test set to a manageable number without a claim of completeness. The graphing technique allows you to design 90% of the functional tests needed for the project (there are still design dependent and coding dependent issues to address). Join Richard to learn how this process moves most of test design effort early in the project, where it is most effective and efficient. |
|
| Learn more about Richard Bender |
|
|
|
|
|
|
| Traditional test plans are incompatible with agile software development because we don't know all the details about all the requirements up front. However, in an agile software release, you still must decide what types of testing activities will be required—and when you need to schedule them. Janet Gregory explains how to use the Agile Testing Quadrants, a model identifying the different purposes of testing, to help your team understand your testing needs as you plan the next release. Janet introduces you to alternative lightweight test planning tools that allow you to plan and communicate your big picture testing needs and risks. Learn how to decide who does what testing—and when. Determine what types of testing to consider when planning an agile release, the infrastructure and environments needed for testing, what goes into an agile “test plan,” how to plan for acquiring test data, and lightweight approaches for documenting your tests and recording test results. |
|
| Learn more about Janet Gregory |
|
|
|
|
|
|
|
Agile teams must deliver production-ready software every four-, two-, or one-week iteration—or possibly every day! This goal can't be achieved without automated tests. However, many teams just can't seem to get traction on test automation. The challenge of automating all regression tests strikes fear into the hearts of many testers. How do we succeed when we have to release so often? By combining a collaborative team approach with an appropriate mix of tools designed for agile teams, you can, over time, automate your regression tests and continue to automate new tests during each programming iteration. Lisa Crispin describes what tests should be automated, some common barriers to test automation, and ways to overcome those barriers. Learn how to create data for tests, evaluate automated test tools, implement test automation, and evaluate your automation efforts. An agile approach to test automation even helps if you’re a tester on a more traditional project without the support of programmers on your team.
|
 |
| Learn more about Lisa Crispin |
|
|
Top of Page
|
|
|
 |
|
|
|
|
