Conference Presentations

Testers and Testing in the Agile Development

You have heard about agile software development techniques such as eXtreme Programming (XP), Scrum, and Agile Modeling (AM). The industry is buzzing with everything from "this is the greatest thing ever" to "it's just hacking with a fancy new name." Comments like "there is no place for testers because developers and users do the testing now" and "testers play an important role in the agile methods" are both common. Scott Ambler, an early proponent of the agile movement, explains the fundamentals, values, and principles of agile development. He describes a range of agile techniques and explores many myths and misconceptions surrounding agility. Agile software development is real, it works, and it may be an important part of your future in testing. Better testing and improved quality are critical aspects of agile software development, but the roles of traditional testers and QA professionals on agile projects remain unclear.

Scott Ambler, Ronin International, Inc.
I've Looked at Bugs from Both Sides Now

Many QA and test professionals are working more closely than ever with their development counterparts, especially those using agile approaches. In doing so, we are learning that some of the attitudes and habits we developed as independent QA groups are no longer effective, especially those that perpetuate an "us vs. them" mentality. Whatever approach your developers are using, it is worth asking, "How should we behave differently if we know our developers really want the same things we want: on time delivery of a software product that everyone loves?" After crossing over into development and back into testing, Elisabeth Hendrickson explores how testing and QA professionals can work more effectively with developers.

Elisabeth Hendrickson, Quality Tree Software, Inc.
A Strategic Approach - "Beta the Business"

Beta testing is an industry standard practice to obtain user feedback prior to general availability of software. Have you ever considered that the Beta release can be used to validate the software's value to customers and application users? Extending the Beta concept will result in higher customer satisfaction (and higher revenue for commercial products). Also, you can employ Beta testing to evaluate not only the software product, but the distribution (and sales) process, training, customer support, and usage within your customers' environments. Far beyond just finding defects in the product, you can focus Beta testing on how well the software is meeting your customers' needs. What does that mean to the Development team and the organization as a whole? What are the risks and challenges that we face? What are the rewards?

Pete Conway, EMC Corporation
Continuous Integration Using an Open Source Platform Architecture

Continuous integration is the process of performing a fully automated build, run often, usually daily, during software development. How do you develop a robust platform architecture to automatically integrate your software into builds? How can open source tools fill the gaps in your platform architecture? After examining the benefits of continuous integration, Paul Duvall discusses techniques, such as architectural validation, configuration management, automated unit testing, and report generation within the process. From a working reference implementation in Java, learn the attributes of an effective platform architecture for continuous integration. Additionally, Paul will introduce you to open source tools, such as Ant, Maven, CruiseControl, Eclipse, xUnit, and others that can help you implement a continuous integration architecture in your environment.

Paul Duvall, Cigital, Inc.
eXtreme Architecture and Design for Test

eXtreme programming emphasizes test-first coding-you write the tests before writing the implementation code. You can apply the same approach in design when developing a complex system, including an architecture to support testing. To be successful, systems developed with agile methods must support a high level of testability and test automation. For large distributed systems, more sophisticated testing is needed to help determine which components may be contributing to failures. For such complex systems, you should architect the system for testing rather than add testing functionality as an afterthought. Ken Pugh presents a framework that employs polymorphic-style internal and external interface patterns to ease the work of testing and debugging. He also covers adding test-only functionality, test-only outputs, and test-only logging to interfaces.

Ken Pugh, Pugh-Killeen Associates
Build the "Right Software" to Delight Your Customer

Many companies have implemented quality programs such as CMM®, TQM, Six Sigma, etc., to improve requirements and software development. However, these initiatives often focus on building the software right-meeting quality expectations and specifications-but do not necessarily focus on building the right software-the right functionality at the right time and at the right cost from the customer's perspective. Unmesh Gundewar explains how EMC employed the Goal, Question, Metric (GQM) methodology to identify key measurements that ensure the "right software" is being developed. Learn how EMC applies the Six Sigma approach to drive these measurements into the organization and the resulting software. Move beyond the processes designed to get functional requirements and specifications right as Unmesh shares experiences, the challenges faced, and lessons learned from building the right software.

Unmesh Gundewar, EMC Corporation
People + Process = ROI!

Return on investment (ROI) is a widely used approach for measuring the value of new or improved technology and business processes. Rather than limiting the discussion on ROI calculations to cost cutting measures, the most significant opportunities often come from addressing the overall business objectives. You need to step outside the focus of the IT department and relate improvements to opportunities for increased business revenue and customer value. The resulting impact on revenues makes the ROI argument for process improvement a compelling one. Discover the myths and realties of software process improvement and how to build a business case for improvement initiatives. By aligning business goals with areas of leverage and improvement plans, you will find both business and IT management more receptive to software process improvement programs and initiatives.

  • The real ROI from software process improvement
Geoffrey Hewson, Software Productivity Center, Inc.
Using Defect Data to Make Real Quality Improvements

A large development organization was challenged to decrease production defects by at least 70 percent. Without extra money or time to install major process changes, what should be done? For a baseline, there was a production defect database that had been running at a steady state for over a year, but no way to size the many different projects and no appetite for either function points or measuring lines of code. In this interesting case study, Betsy Radley reports how they used approximations and sometimes crude assumptions to develop measurements from the defect data. These measurements identified applications that had the fewest product defects. Find out how they used that information to look for processes and tools used in these "good" applications and then applied them to the "bad" applications.

Betsy Radley, Nationwide Insurance Company
Navigating the Minefield - Estimating without Complete Requirements

Your team is assigned to a new project, and you've had the kickoff meeting. Now, your boss' boss sends an email to you asking for a "guesstimate" of how long and how many people-days the project will take. What do you do? Even though developers and project managers can see the futility of doing premature, fixed cost estimates prior to requirements development, the industry still demands early estimates, often before a project is even named. Based on her experiences with similar projects, Carol Dekkers offers tips and tricks that she and others have used successfully to answer these difficult questions. Find out how to provide traceability when the original estimates turn out to be as inaccurate as the unknown requirements they represent.

  • Early resource and time estimates without good requirements
  • Organizing and documenting early requirements statements
Carol Dekkers, Quality Plus Technologies Inc
The Task StackProject Planning and Tracking Approach

Task Stack Planning (TASAP) is a novel approach to systematic and quantitative project management. With this process you break down work into small "packages" that form the basis for comprehensive planning, tracking, and reporting activities. Team members participate in bottom-up planning activities, allowing unplanned work to be seamlessly integrated into the operational planning process. The operational plan is updated weekly with all results fed back into the overall plan. The TASAP approach is compatible with CMMI® operational planning requirements and is scalable to support large projects with low incremental overhead. Discover how to implement this integrated project planning process that supports distributed team settings.

  • A project planning process for accurate schedule, cost, and quality predictions
  • The linkage of operational and long-term planning
Gerold Keefer, AVOCA LLC

Pages

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.