With today’s changing systems environments, testing must be conducted throughout the entire development lifecycle to ensure the results match the objectives. Learn how proper testing can improve efficiency, reduce costs, lower risk and ultimately deliver a successful product to market.

W10	Wednesday, September 29, 2004, 11:30 AM

Fewer resources — more work — shorter deadlines — critical business applications . . . what impact do these factors have on your application delivery? Do you question the ''Go/No Go'' recommendations you've provided to management? The common aspect in each of these factors is risk! How much do I have? How much is acceptable? What must be tested in the timeframe available? David Kapelanski describes in detail how to implement a risk-based testing strategy throughout the development lifecycle of your applications. By implementing this methodology within your existing development process, you will be able to assess your ability to execute within acceptable risk constraints and make more informed and convincing ''Go/No Go'' recommendations.

• Assigning quantitative risk factors to business requirements
• Impact of a risk-based analysis to your testing process
• A method for including risk assessment in the release decision process

W11	Wednesday, September 29, 2004, 1:45 PM

Over the past few years Herbert Thompson and his cohorts have scoured bug databases for the most malevolent and destructive security bugs ever to infest a released binary. Through that search they found that common characteristics and habits emerged — creating temporary files with secure data, trusting that system calls will succeed, foolishly relying on insecure third party components, and many others. In this session, he offers a startling and even scary accounting of the top seven habits of insecure software. Take away a red-teaming strategy that has broken some of the world's most secure software under testing contracts with Microsoft, IBM, the US DoD, and many others. Use this approach to make your software more secure, and you can sleep better at night.

• The differences between security defects and other common errors
• An intimate understanding of security faults as seen by hackers
• A strategy for security testing applications before deployment

W12	Wednesday, September 29, 2004, 3:00 PM

Like other aspects of development, information about testing and QA practices is often buried in technical jargon and hidden from senior management’s true understanding. Although corporations have many choices to protect their customers from poor quality software, these choices are so complex that many decision-makers do not understand them well enough. This lack of understanding is dangerous both to the companies and to the test organizations working for them. Whether you are among the decision-makers or someone who needs to influence them, Brian Warren offers, in business terms, a flexible model of how testing and QA can fit into the development organization as seen by IEEE, ASQ, CMMI®, RUP, and others. He provides recommendations for integrating testing and QA functions into your organization and how these functions now are being impacted by the 2002 Sarbanes-Oxley Act.

• A model, in business terms, for describing a range of testing and QA services
• Impact of business context on the viability of different testing and QA approaches
• Corporate governance reforms applied to testing and QA organizations

T13	Thursday, September 30, 2004, 10:15 AM

Developers and testers sometimes get into a frustrating dance in which the developers provide code for test, the testers run tests and document findings, developers fix the problems and re-release for testing, and the testers rerun and document new, different problems, and so on. For good reasons teams often begin “formal” testing on new software while it is still being coded. In this case the testers are working full tilt: running tests, investigating and isolating faults, writing up defects, rerunning the tests, and verifying fixes; but a lot of time is wasted by everyone on problems the developers already know about. As a manager, developer, or tester, you can break out of this vicious cycle and get to a better place. Douglas Hoffman shares his experiences seeing, participating in, and getting out of the test and test again syndrome.

• How to know when the test and test again syndrome is happening to you
• Ways to break out of the cycle and improve productivity
• Good feedback and communications methods during early testing

T14	Thursday, September 30, 2004, 11:30 AM

The period 2002-2004 was one of enormous progress in figuring out how testing fits in on agile projects. Test-driven design is more about designing and writing the code than about finding bugs. New testing tools such as xUnit and FIT came out and received a lot of use by early adopters. The hopeful notion that customers would write acceptance tests to find bugs was expanded, challenged, and deepened. With all that progress, it's hard to be dissatisfied with these methods in agile projects. But past ways of thinking are holding us back. To make further progress, we have to split our notion of testing into two parts: the task of after-the-fact product critique, and a role that has nothing at all to do with bugs and, really, little to do with the word ''testing.'' Brian Marick, a founding member of the Agile Alliance, explains what that role presents and some ideas on how to fill it.

• The evolving role of testing in agile development projects
• Finding bugs is not enough to deliver the value customers need in agile projects
• A new view for agile development processes

T15	Thursday, September 30, 2004, 1:30 PM

Fast development cycles, distributed architectures, code reuse, and developer productivity suites make it imperative that we improve our software test methods and efficiency. What process assessments are available? How do you conduct an assessment? How do you guard against incorrect information? How do you know what to improve first? And how can you make successful improvements without negatively impacting your current work? Learn the answer to these questions and more from Intel’s experiences using the Test Process Improvement (TPI) model as a basis for two assessments with resulting scores, improvement suggestions, and adopted actions. You will hear about the high points and low points of using this process and see a comparison of the TPI model with the CMMI® Level 3 key process area.

• The TPI and other models for test process assessments
• A first-hand account of two test process assessment experiences at Intel
• Assessing the assessment process — high and low points

T16	Thursday, September 30, 2004, 3:00 PM

You must successfully test your browser-based applications before hackers do the job for you! Whether you have to worry about critical business applications or government compliance issues like HIPPA (Health Insurance Portability and Accountability Act of 1996) or GLBA (Financial Services Modernization Act of 1999), security failures can cost your organization big dollars, unnecessary embarrassment, or both. Hackers have gone beyond simple exploits of open IP ports and standard applications such as Telnet, FTP, and Sendmail, turning their attention to commercial and custom Web applications. To thwart the hackers, test engineers must focus their efforts on common and uncommon security vulnerabilities within the application, including SQL injections, session hijacking, cross-site scripting, and more. Dennis Hurst presents practical, proven automated and manual testing techniques to help you find and repair security flaws before your applications are breached.

• Security flaws in browser-based Web applications
• Common web application hacking methods
• Automatic and manual security testing methods

Software Quality Engineering Home       Conference Home       To Exhibit       Get a Brochure       Register for Better Software Conference & EXPO 2004

feedback  © 2004