|
|
|
STAREAST 2006 Concurrent Sessions
Go To: Wednesday | Thursday | Friday
View by Track
| Thursday, May 18, 2006 9:45 AM | | | T1 is a Double-Track Session! | Testing Dialogues—Management Issues
Esther Derby, Esther Derby Associates Inc
Johanna Rothman, Rothman Consulting Group, Inc.
As a test manager, are you struggling at work with a BIG test management issue or a personnel issue? If so, this session is for you. “Testing Dialogues—Management Issues” is a unique platform for you to share with and learn from test managers who have come to STAREAST from around the world. Facilitated by Esther Derby and Johanna Rothman, this double-track session takes on management issues—career paths for test managers, hiring, firing, executive buy-in, organization structures, and process improvement. You name it! Share your expertise and experiences, learn from others’ challenges and successes, and generate new topics in real time. Discussions are structured in a framework so that participants will receive a summary of their work product after the conference. |
| | Branch Out Using Classification Trees for Test Case Design
Julie Gardiner, QST Consultants Ltd.
Classification trees are a structured, visual approach to identify and categorize equivalence partitions for test objects to document test requirements so that anyone can understand them and quickly build test cases. Join Julie Gardiner to look at the fundamentals of classification trees and how they can be applied in both traditional and agile test and development environments. Using examples, Julie shows you how to use the classification tree technique, how it complements other testing techniques, and its value at every stage of testing. She demonstrates a classification tree editor that is one of the free and commercial tools now available to aid in building, maintaining, and displaying classification trees.
• How to develop classification trees for test objects
• The benefits and rewards of using classification trees
• When and when not to use classification trees |
| | Tester Skills for Moving Your Automation to the Next Level
Dion Johnson, DiJohn Innovative Consulting, Inc.
Job interviews for test automation engineers are often limited to, "How proficient are you with the tool vendor XYZ’s scripting language?" This approach does little to help the hiring manager choose those individuals who are or will become highly skilled automation professionals. As a test engineer, you will need to acquire specialized knowledge and tool independent capabilities to become a test automation expert. Join Dion Johnson as he identifies the core set of tool-independent competencies required of a successful automated software test engineer: automation framework design, programming and debugging skills, object model concepts, and automation methods based on the required quality attributes. Learn how you, as a hiring manager, can identify these skills, or find out how you personally can improve your skills to become a true test automation expert.
• Skills to screen test automation candidates or market yourself as an automated test engineer
• Crucial automated testing concepts and knowledge domains
• Required automated test frameworks and skills |
| | Agile Software Development: What's in it for Testers?
Alan Ridlehoover, Microsoft
Agile software development methods change the ways teams work together to build software systems. Testers often are wary of what these changes will mean to them. However, experience shows that testers stand to benefit significantly from agile practices. In fact, testers who are willing to embrace agility with the rest of their project team can expect greater influence, productivity, confidence, and career growth potential. Looking at the technical, management, and social aspects of agile development, Alan Ridlehoover describes how agile methods differ from traditional software development practices. He describes what changes and what stays the same for the testing and test management roles within a project. Discover how testers can benefit when their organizations adopt agile processes and the common pitfalls many testers encounter in making the transition.
• How agile development and traditional methods differ
• The changed role of the tester in the agile environment
• Where to learn more about agile practices and the role of testing |
| | Lightning Talks: A Potpourri of 5-Minute Presentations
Robert Sabourin, AmiBug.com Inc
Lightning Talks are nine five-minute talks in a fifty-minute time period. Lightning Talks represent a much smaller investment of time than track speaking and offer the chance to try conference speaking without the heavy commitment. Lightning Talks are an opportunity to present your single biggest bang-for-the-buck idea quickly. Use this as an opportunity to give a first time talk or to present a new topic for the first time. Maybe you just want to ask a question, invite people to help you with your project, boast about something you did, or tell a short cautionary story. These things are all interesting and worth talking about, but there might not be enough to say about them to fill up a full track presentation. For more information on how to submit your Lightning Talk, visit www.sqe.com/lightningtalks.asp. Hurry! The deadline for submissions is April 3, 2006. |
| | | Thursday, May 18, 2006 11:15 AM | | Put on a Gamer’s Hat with Data Flow Testing
Mitch Goldman, Mitch Goldman (Self)
Designing tests from the point-of-view of the data is like playing a first-person-shooter game. It’s fun—and it can give you a deeper understanding of the application under test. Data moves through an application like a player traverses a game. It flows through a maze (to and from the database), encounters enemies (validations), picks up inventory items (attributes), and solves puzzles (business rules) to win (accepted) or lose (rejected). Designing tests from the data’s point of view is a useful heuristic to help pinpoint the origin of the bug and to reveal bugs that may otherwise go undetected. Mitch Goldman employs the game analogy to illustrate ways to break down an application into its data-flows, design the tests, and execute them. So, put your gamer hat on and start designing tests from the data’s point of view. Have a “death match” with your bugs!
• How to break down an application into its data-flows
• Design and execute the data-flow tests to find new bugs
• Tools for designing and executing data-flow tests |
| | “How to Build a Better Test Script” with a Component-Based Approach
Jeff Roberts, Convergys
Do you dream of having a centralized, modular set of test script steps or “components” that you can link together many times in multiple test scripts to create end-to-end fully automated tests? If so, join Jeff Roberts as he lays out, step-by-step, the real-life method his company has used for the past four years to do just that. With a database of script components, they write functional test scripts more quickly and, as the software changes, update them more efficiently. In a presentation detailing how this process was used in a real-world setting, Jeff explains the approach adopted by his large testing organization with multiple products and teams operating in multiple locations. Learn to break down your scripts into standardized components categorized as procedures, how-to information, data, and SQL commands. Take back the basics of a complete methodology for building and maintaining better test scripts.
• The methodology for component-based test scripts
• An example of the components and a test script composed using this approach
• Implementing the component-based test scripting in your company |
| | Test, Then Code, with Agile Inspections
Richard Durham, Citrix Systems Ltd
It is well known that the earlier in the development lifecycle a fault is found, the less costly it is to resolve. Whether you use traditional or agile development practices, you have an opportunity to implement Agile Inspections for finding faults before the code is even written. An Agile Inspection is a lightweight process that brings the skills and outlook of professional testers into the design of software. A good precursor to formal test planning, an Agile Inspection is a way to inform developers—in a way that makes sense to them—of how you are going to test. It offers the best chance to increase the testability of software at the lowest cost. Find out from Richard Durham the prerequisites for adopting Agile Inspections, what to look for in an inspection, how to communicate findings, and approaches to encourage buy-in from management and developers.
• How an Agile Inspection differs from a regular inspection or review
• The cost and the benefits of Agile Inspections
• Techniques to use when conducting an Agile Inspection |
| | CMMI® Level 5: How Our Test Organization Got There
Kristen Bevans, IBM - Global Testing Organization
Achieving CMMI® Level 5 Capability as an independent test organization takes a tremendous effort. However, achieving CMMI® Level 5 or a lower level compliance is not out of your reach. Join Kristen Bevans as she describes how the IBM Global Test Organization team successfully completed a formal SEI CMMI® Level 5 SCAMPI Class A appraisal as an independent test organization. The appraisal used the Continuous Representation of the SEI CMMI-SE/SW/IPPD/SS V1.1 Model achieving CMMI® Level 5 in the project planning, project monitoring and control, risk management, and verification process areas. Discover how to develop your CMMI® core team, establish the scope, plan the effort, prepare for an appraisal, and conduct the appraisal with SCAMPI methods. Kristen shares her thoughts on what they would do differently—and what they would do the same—if they had it to do over again.
CMMI® is a registered trademark of Carnegie Mellon University.
• An overview and benefits of the CMMI® model
• The core team’s external associations, training, and experience
• Appraisal planning and preparation with SCAMPI methods |
| | | Thursday, May 18, 2006 1:30 PM | | A Balanced Scorecard Approach for Assessing Test Value and Success
Isabel Evans, Testing Solutions Group Ltd
Internal test metrics—test progress, defect density, and TPI/TMM measures on process improvement—do not reveal the complete picture of test value and success. By comparing common test metrics with those found in the Balanced Business Scorecard—financial, customer, internal, and learning/innovation metrics— we see the need to also report financial and customer measures. Some of these measures are quantitative (such as profits), and others are more qualitative (for example, customer satisfaction). Learn to measure the financial impact of testing through productivity metrics and measures of how testing affects the total cost of quality. Include in your reporting qualitative assessments such as the customers’ perception of the usefulness of testing, the visibility of testing on projects, acceptability measures, and estimation accuracy.
• Set measures for all viewpoints of testing’s value and success
• Collect data needed to support these metrics
• Make reports to colleagues and customers add value for decision making |
| | Code Coverage: Where Does It Fit?
Dale Brenneman, McCabe Software
Many organizations use code coverage almost religiously in their testing. Just as many or more organizations do not use code coverage or have tried it and stopped. If you want to begin using code coverage for the first time or improve its value and usage within your team, come hear what Dale Brenneman has to share. Using real-life examples, Dale explains the value of code coverage analysis as part of a comprehensive test plan and the potential side effects when you do not use code coverage. Find out about the many levels of code coverage and ways to enhance the value of code coverage analysis with other analysis techniques. Take away a step-by-step approach for integrating code coverage analysis into your organization's test process and fitting it into your functional test automation program.
• The levels of module code coverage: entry, line, statement, branch, Boolean, cyclomatic path, all paths
• The levels of application coverage: sums of module, module entry, integration calls, integration paths, all paths
• A sample of the results and reports from code coverage analysis |
| | Automated Setup and Tear Down of Complex, Multi-tier Test Configurations
James Phillips, Akimbi Systems
Many software test and development teams struggle to test systems with complex set-up steps and multiple configurations. With these interdependent software systems, testers must iterate through very large, multi-dimensional test matrixes (for example, permuting front-, middle-, and back-tier platforms) to complete the test requirements. Testers have the difficult and sometimes seemingly impossible task of duplicating failures and saving the system’s state for later analysis and debugging. With several emerging commercial software tools, software development organizations can successfully implement live-state software test configuration provisioning and capture systems. James Phillips shares case studies of organizations that maintain comprehensive libraries of system environments used for repeated testing and organizations that give every developer and test engineer the equivalent of a fully equipped data center with dedicated provisioning staff.
• Pool and share server, networking, storage, and other resources between development and test teams
• Automatically set up and tear down complex, multi-machine software configurations
• Suspend and capture “live” multi-machine environments for both development and test |
| | | T13 is a Double-Track Session! | Testing Outside the Bachs
James Bach, Satisfice Inc
Jon Bach, Quardev Laboratories
Simply put, exploratory testing means designing your tests as you perform them. When it’s done well, it’s a fantastically productive and rewarding approach to testing. However, to do it well requires training, practice, and discipline. Lecture presentations about exploratory testing are a poor substitute for seeing it and doing it. So . . . plan to bring your laptop to this session and test along with James Bach and Jon Bach as they demonstrate exploratory testing in a live testing workshop. Participate or just observe as exploratory testing is performed in real time with play-by-play and color commentary. Learn how to bring structure to this apparently unstructured testing method. See if you can find bugs that they do not find as you test “outside the Bachs”!
If you plan to bring your laptop and join in this live testing workshop, make sure it is charged up. Email james@satisfice.com for directions on downloading the software onto your computer. |
| | Security Testing: Are You a Deer in the Headlights?
Ryan English, SPI Dynamics Inc
With frequent reports in the news of successful hacker attacks on Web sites, application security is no longer an afterthought. More than ever, organizations realize that security has to be a priority while applications are being developed—not after. Developers and QA professionals are learning that Web application security vulnerabilities must be treated like any other software defect. Organizations can save time and money by identifying and correcting these security defects early in the development process. Ryan English helps you overcome the “deer in the headlights” look when you are asked to begin testing applications for security issues. See real world examples of company Web sites that have been hacked because of vulnerable applications and see how the attacks could have been avoided.
• Security defect categories and responsibility areas
• How QA professionals can test for security defects using manual testing, open source tools, and integrated automated testing
• Case studies of hacked Web sites |
| | | Thursday, May 18, 2006 3:00 PM | | Acceptance Testing: What It Is and How To Do It Better—in Context
Michael Bolton, DevelopSense
When test engineers use the term "acceptance testing," they might be saying and thinking profoundly different things. Acceptance testing can mean one of at least a dozen approaches to the testing of a product and serve one or more of at least thirty different customer roles in a project. Tests and testing approaches that are appropriate in one context can be unacceptable—even disastrous—in another. When someone asks you to do user acceptance testing, what should you do? When should you do it? How do you determine success? Michael Bolton outlines the ways in which testers and test managers use context-driven thinking to better serve the mission of acceptance testing and develop skills to handle dramatically different testing situations. Apply your context in this interactive session to discover ways to improve your acceptance testing, and learn to use context-driven thinking in other areas, too.
• The many customers for acceptance testing and what they value
• Framing the mission for successful acceptance testing
• An introduction to context-driven thinking in software testing |
| | Q-Patterns for Reusable Test Cases
Vipul Kocher, PureTesting
You can think of Q-Patterns as a structured set of questions (tests) about the different aspects of a software application under test. They are questions about the system that are categorized, grouped, sorted, and saved for reuse. These Q-Pattern questions can be written ahead of time and stored in a repository of test case templates, developed for requirements and design reviews or built in real-time as a way to both guide and document exploratory testing sessions. See examples of Q-Patterns that Vipul Kocher has developed for error messages, combo boxes, login screens, and list handling. Learn how to associate related Q-Patterns and aggregate them into hierarchical and Web models. Take back the beginnings of Q-Patterns for your test team and organization.
• Sharable and reusable test case designs
• Templates to organize requirements and design reviews
• A tool for capturing exploratory testing experiences |
| | Don't Whine—Build Your Own Test Tools
Clay Bailey, IBM
The highly customized hardware-software system making up the new flight operations system for the world’s largest airline did not lend itself to off-the-shelf tools for test automation. With a convergence of on-demand, highly available technologies and the requirement to make the new system compatible with hundreds of legacy applications, the test team was forced to build their own test software. Written in Java, these tools have helped increase test coverage and improved the efficiency of the test team. One tool compares the thirty-one year old legacy system with its new equivalent for undocumented differences. Clay Bailey will demonstrate these tools, including one that implements predictive randomization methods and another that decodes and manipulates hexadecimal bit string representations.
• Custom test tools for a unique systems environment
• Innovative ways to develop and use Java for writing test tools
• A novel way to manage ongoing change in regression test suites |
| | Model-Based Security Testing
Kyle Larsen, Microsoft Corporation
Preventing the release of exploitable software defects is critical for all applications. Traditional software testing approaches are insufficient, and generic tools are incapable of properly targeting your code. We need to detect these defects before going live, and we need a methodology for detection that is cost-efficient and practical. A model-based testing strategy can be applied directly to the security testing problem. Starting with very simple models, you can generate millions of relevant tests that can be executed in a matter of hours. Learn how to build and refine models to focus quickly on the defects that matter. Kyle Larsen shows you how to create a test oracle that can detect application-specific security defects: buffer overflows, uninitialized memory references, denial of service attacks, assertion failures, and memory leaks. Take back information on the advanced file “fuzzing” techniques Microsoft has used successfully.
• How to build a model and adjust it to find security defects
• Ways to apply the model-based techniques to any product
• Microsoft’s results using this methodology on shipping code |
| |
|
|
