|
|
STAREAST 2006: Testing Outside the Bachs 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"!
|
James Bach, Satisfice, Inc. and Jon Bach, Quardev Laboratories
|
|
|
Automated Setup and Tear Down of Complex, Multi-tier Test Configurations 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, Akimbi Systems
|
|
|
Code Coverage: Where Does it Fit? 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
|
Dale Brenneman, McCabe Software
|
|
|
A Balanced Scorecard Approach for Assessing Test Value and Success 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
|
Isabel Evans, Testing Solutions Group Ltd
|
|
|
CMMI Level 5: How Our Test Organization Got There 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.
|
Kristen Bevans, IBM - Global Testing Organization
|
|
|
Test Then Code with Agile Inspections 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.
|
Richard Durham, Citrix Systems Ltd
|
|
|
"How to Build a Better Test Script" with a Component-Based Approach 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.
|
Jeff Roberts, Convergys
|
|
|
Put on a Gamer's Hat with Data Flow Testing 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
|
Mitch Goldman, Mitch Goldman (Self)
|
|
|
STAREAST 2006: Lightning Talks: A Potpourri of 5-Minute Presentations 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
|
Robert Sabourin, AmiBug.com Inc
|
|
|
Agile Software Development: What's in it for Testers? 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
|
Alan Ridlehoover, Microsoft
|
