$475 

$550 

$400 

$625 

$750 

$525 

$950 

$1100 

$800 

Playing Nice in the Sandbox

Janet Gregory

In the beginning of the agile discussions, developers and customers reigned over the world. Over the years, testers have raised their heads and said, “We want to be involved. We think we have a place in this agile world!” Well, testers have found a place in many agile teams, but not in the same way as the testers of old. Instead of being the “quality police,” they have become a conduit for providing feedback to the team. Collaboration is the key to a healthy working relationship. Teams that are moving from a traditional phased approach where developers and testers are separated and have a throw it over the wall mentality may struggle with the concept. Janet will share tips for collaboration between developers and testers, how they can learn from each other, and how together, they contribute to make a successful team.

Janet Gregory is a Calgary-based consultant specializing building quality systems and her passion is promoting agile quality processes. She has helped to introduce development agile practices into companies as tester or coach, and has successfully transitioned traditional test teams into the agile world. Her focus is working the business users and testers to understand their role in agile projects.

She is currently writing a book on agile testing with Lisa Crispin due out early 2009. Janet has presented at the Agile and StarWest conference several times and is active in the Agile Testing community.

Selling Your Ideas to Management

Steve Smith

Do you wish you could break through and communicate your ideas more effectively with management? Employees do their best to sell their ideas to managers. Nevertheless, a typical outcome of these conversations is hearing the word “No”" or “Let me think about it.” Employees seldom ask and management seldom offers feedback about the elements of a conversation that worked and those that did not.

Discover three top characteristics of proposals that do work. Hear how others have used these characteristics to transform a conversation with management into a discussion. Management is busy. You may have only one shot at selling your idea. Learn how to effectively target your proposal so that it’s heard and acted on.

Steven M. Smith is a management consultant who helps managers make effective decisions about satisfying customers, managing change, and strengthening teamwork. With more than three decades of experience as a thought leader in technical organizations, he shares his know-how through his writing, consulting, and workshops. He is a founder and host of the annual Amplifying Your Effectiveness (AYE) Conference, at which he leads experiential workshops.

It’s Not Just an Update: Using Status Reporting to Expand Collaboration

Mike Kelly

As a tester, you have undoubtedly encountered the question, “How’s your testing coming along?” If you are anything like I use to be, that question sometimes brings out some interesting mumbles, shrugs, and excuses for meetings “I’m late for.”

A couple years ago, I developed a heuristic to help me deal with questions of status, and now I answer status questions with confidence. In this talk, we will cover the key elements of increasing team collaboration using status reports. We will also look at some collaborative techniques for practicing status reporting, to better develop the skill over time.

Mike Kelly is currently a Software Development Manager for Liberty Mutual, a Fortune 100 company. Mike also writes and speaks about topics in software testing. He is currently the President for the Association for Software Testing and is a co-founder of the Indianapolis Workshops on Software Testing, a series of ongoing meetings on topics in software testing, and a co-host of the Workshop on Open Certification for Software Testers. You can find most of his articles and blog on his website www.MichaelDKelly.com.

Expanding Trust and Collaboration with Earned Value Tracking

Tamara Sulaiman & Hubert Smits

AgileEVM was successfully migrated from the traditional project management environment to the agile space (Sulaiman, Barton & Blackburn - Agile2006) and is finding its way into the practices of those who lead larger projects, and those who have to report into an organization that is used to (and doesn’t want to let go of) Earned Value Management practices. AgileEVM provides a cost perspective that provides product owners (customers) with cost data that supports decision-making.

The presenters will explore the AgileEVM tool with the audience, guiding the audience through patterns when observing the AgileEVM metrics, and discussing what the results mean to their project.

Tamara Sulaiman is Managing Consultant at AppliedScrum where she is focused on coaching teams and organizations transitioning to Agile software development. Tamara brings over 20 years of experience in management across a spectrum of industries including: information technology, construction, international development, and education to her consulting expertise. She is a Certified Scrum Trainer (CST) and Project Management Professional (PMP). Since 2003, Tamara has assisted teams in transitioning to agile methods both as a hands-on ScrumMaster and as an Agile Coach and Scrum trainer. As an educator and coach, she brings her wide ranging professional expertise to training and mentoring teams new to Agile and the Scrum framework. As a Managing Consultant, Trainer, Coach, ScrumMaster, and Project Manager, she focuses on coaching teams to effectively provide value to key stakeholders and customers through the frequent delivery of software.

Hubert Smits is a coach for Rally Software Development. Based in Boulder, Colorado he travels around to globe to introduce and guide software development teams on their trail towards agility. He works mainly with international organizations, guiding management teams in the creation of rollout plans for their agile initiatives, and coaching them in the inspect-and-adapt process during the implementation process. He trains delivery teams, project managers, product management teams and support teams, and facilitates their endeavors in planning projects, releases, and iterations and reviews the results with them in their demo/retrospective meetings, enabling change in the respective teams. Hubert’s home is Scrum - he is a Scrum Trainer and enjoys applying the framework to new challenges.

Tamara Sulaiman & Hubert Smits

In our work, we often encounter questions about the amount and quality of planning in Agile projects. “What about planning?” “Does being Agile mean we don’t plan?”

This workshop will not only answer those questions, it will also teach you how to plan in Agile projects. We will do this by focusing on the levels of agile planning recommended for large product development efforts using Scrum. Following the planning structure for large, scaled projects, we will hold hands-on exercises following the development of a single product through the levels of Product Visioning, Product Road-mapping, Release Planning, Sprint planning, the daily Scrum and the Scrum of Scrums.

The structure of the session follows the planning structure for large agile projects. Each level will involve explanation, discussion, and hands-on exercises. We begin with a brief overview of the Scrum framework and the levels of planning involved. Then the audience splits into groups of 5-10 people, which will stay together as a team during the remainder of the workshop. Each team will have participants play the roles of Product Owner, ScrumMaster and Delivery Team member at different parts of the session. The team’s first task is to develop a vision for a new product within given parameters. They will be given different techniques to do this (through an elevator statement, a product box, or a metaphor). The next steps are to develop a product roadmap, the sequence in which the product will be delivered, and then hold a story writing session where each group develops a backlog of product features.

The workshop continues with release planning using the integrated product backlog developed in the morning session. From there we will hold a joint sprint planning session, decomposing the most important stories into tasks and estimating those tasks. The last part of the workshop will be based on the Scrum stand-up meeting, and the aggregated version of it, the Scrum of Scrums.

Tamara Sulaiman is Managing Consultant at AppliedScrum where she is focused on coaching teams and organizations transitioning to Agile software development. Tamara brings over 20 years of experience in management across a spectrum of industries including: information technology, construction, international development, and education to her consulting expertise. She is a Certified Scrum Trainer (CST) and Project Management Professional (PMP). Since 2003, Tamara has assisted teams in transitioning to agile methods both as a hands-on ScrumMaster and as an Agile Coach and Scrum trainer. As an educator and coach, she brings her wide ranging professional expertise to training and mentoring teams new to Agile and the Scrum framework. As a Managing Consultant, Trainer, Coach, ScrumMaster, and Project Manager, she focuses on coaching teams to effectively provide value to key stakeholders and customers through the frequent delivery of software.

Hubert Smits is a coach for Rally Software Development. Based in Boulder, Colorado he travels around to globe to introduce and guide software development teams on their trail towards agility. He works mainly with international organizations, guiding management teams in the creation of rollout plans for their agile initiatives, and coaching them in the inspect-and-adapt process during the implementation process. He trains delivery teams, project managers, product management teams and support teams, and facilitates their endeavors in planning projects, releases, and iterations and reviews the results with them in their demo/retrospective meetings, enabling change in the respective teams. Hubert’s home is Scrum - he is a Scrum Trainer and enjoys applying the framework to new challenges.

Karen N. Johnson

Understanding the relational data model behind an application enables testers to design additional tests and gain a deeper understanding of the application they are testing. This class is an introduction to relational databases and SQL. The workshop is designed for software testers and test leads to gain an understanding of relational data models and data types. Students will learn the fundamentals of writing structured queries and learn how to navigate through a data schema. SQL knowledge helps both manual and automated testers. This class is not designed specifically for any relational database. This class will discuss several of the most common databases including MySQL, Oracle, Sybase, and Microsoft SQL Server. Workshop attendees will need to bring a lap top computer to class.

Karen N. Johnson is a software-testing consultant in Chicago, Illinois. Karen views software testing as an intellectual challenge and believes in the context-driven school of testing. She has extensive experience in software testing and test management. Karen frequently speaks at software testing conferences. She has presented at STPCon, CAST, PNSQC, StarEast, and StarWest. She’s also presented at several local quality group meetings such as IQAA, CQAA, and NOSQAA. She publishes articles on software testing and has been published in Better Software, InformIT and StickyMinds.com. Karen is an executive board member for the Association for Software Testing (AST), and the program co-chair for CAST 2008, the Conference for the Association for Software Testing. Karen is a hosted software-testing expert on Tech Target’s website, searchsoftwarequality.com.

Janet Gregory

Testers and developers, who have come from a traditional software development background, often have no collaborative skills necessary to work with each other. They can work within their functional team but no one has shown them how to work with the other teams. Common vocabulary is a powerful tool to give to teams to start the interaction necessary for great collaboration efforts.

Explore ways to collaborate using Brian Marick’s testing quadrant as a base for the vocabulary. The quadrant can serve as a mechanism to start discussions and encourage collaboration within the project team as well as with teams or customers that may external to the project. The four quadrants describe different reasons why we test. They are:

1. Technology facing tests that support programming.

2. Business facing tests that support programming.

3. Business facing tests that critique the product.

4. Technology facing tests that critique the product.

In this workshop, we will examine different ways to interact with each other to get the best information possible. For example, to support programming, we will study how testers can help define story tests using examples for story development. The interaction between customer, tester, and developer is critical to getting the right information.

The workshop will use hands-on experience, role playing, examples, group exercises, discussion, and personal experiences to help the participants learn interaction techniques to help your team develop a great test experience.

Janet Gregory is a Calgary-based consultant specializing building quality systems and her passion is promoting agile quality processes. She has helped to introduce development agile practices into companies as tester or coach, and has successfully transitioned traditional test teams into the agile world. Her focus is working the business users and testers to understand their role in agile projects.

She is currently writing a book on agile testing with Lisa Crispin due out early 2009. Janet has presented at the Agile and StarWest conference several times and is active in the Agile Testing community.

Steve Smith

If a project team is working on the wrong problem, the best solution in the world will not satisfy their customer. How can you help a project team zero on the right problem? You cannot do it by yourself. You will need help. You will need to gather the right people. In addition, you will need to help them work together effectively.

This workshop will introduce participants to a three-step method for facilitating stakeholders to zero in on the right problems. Learn how you can help groups distinguish between problems that must be solved and those that could be solved. Practice facilitating during the workshop so that when you return to your organization, you can put these methods to use.

Steven M. Smith is a management consultant who helps managers make effective decisions about satisfying customers, managing change, and strengthening teamwork. With more than three decades of experience as a thought leader in technical organizations, he shares his know-how through his writing, consulting, and workshops. He is a founder and host of the annual Amplifying Your Effectiveness (AYE) Conference, at which he leads experiential workshops.

The Art of Building Consensus

Sam Kaner

Making high-quality, high-stake decisions in groups is not easy. Making them in cross-functional groups is even tougher. The diversity in the room breeds misunderstanding, confusion, and frustration. All too often these meetings end with predictably mediocre results - people either accept lowest-common-denominator compromises, or they punt the tough issues to a senior person, so s/he can make the real decisions later. In both cases, one is left wondering, “Why call such meetings in the first place?”

This morning’s keynote is a fascinating tour de force description of what it takes to build consensus in real-world cross-functional environments.

Sam Kaner, one of the world’s leading experts in multi-party collaboration, will share models and methods that have been used successfully at HP, Symantec, Electronic Arts, VISA, and hundreds of other organizations. You will walk away with powerful new insights and a set of tools you can use right away.

Sam Kaner, Ph.D., has been an Organization Development practitioner for more than 25 years, and he has long been a specialist on consensus-building in groups. Sam has been named as “one of the world’s leading experts in collaboration” (Sandor Schuman, Ph.D., founding editor of Journal of Group Facilitation, and co-founder of International Association of Facilitators.) Sam’s classic bestseller, Facilitator’s Guide to Participatory Decision-Making (Jossey Bass), has gone through 16 printings and is now in its 2nd edition.

Sam has been a featured speaker at more than 40 professional conferences, and he has delivered keynote addresses on collaboration and group decision-making at the annual World Congress of Quality, the annual Asia Facilitators’ Conference, the annual world conference of the International Facilitators’ Association, The Association of Quality & Participation, and the annual Best in the West conference of the Organization Development Network. In 2005, AmericaWest Airlines named Sam as one of America’s Best Consultants. Since 1987 he has been Executive Director of Community At Work, a San Francisco-based consulting firm that specializes in designing and facilitating collaborative approaches to complex system change.

Quality Dynamics of Agile SW Development

Ron Jeffries & Chet Hendrickson

As Agile software proponents, we have spent much of our time explaining XP and Agile practices and why they make sense. Generally we talk about these things from a “supply side” viewpoint. We think about software development and how it works best, from the trenches.

Let’s focus on the “demand” side . Let’s look at the needs of those who pay for our software development. They need benefits, profit, information, and flexibility. It turns out that in order to provide what the business side needs, Agile and XP practices are not just helpful - they are almost essential.

Starting from a few simple and commonly held assumptions, we will explore the dynamic behavior of a software project, and will derive both management practices, and technical practices, as the inevitable consequences of setting out to do with what our business-side people need and want.

This keynote is a start at creating a unified theory of team-based software development, deriving the practices that are necessary in order to do software profitably and well. Our presentation will be based around a growing series of graphs and pictures illustrating what happens on a software project. Relationships between practices - what we do -and what happens - will be shown with both static and dynamic charts.

Ron Jeffries is author of Extreme Programming Adventures in C#, the senior author of Extreme Programming Installed, and was the on-site XP coach for the original Extreme Programming project. Ron has been involved with Extreme Programming for over five years, presenting numerous talks and publishing papers on the topic. He is the proprietor of www.XProgramming.com, a well-known source of XP information. Ron was one of the creators, and a featured instructor in Object Mentor’s popular XP Immersion course. He is a well-known independent consultant in XP and Agile methods.

Ron has advanced degrees in mathematics and computer science, and has been a systems developer for more years than most of you have been alive. His teams have built operating systems, compilers, relational database systems, and a large range of applications. Ron’s software products have produced revenue of over half a billion dollars, and he wonders why he didn’t get any of it.

Chet Hendrickson was at the ground zero of Extreme Programming, the Chrysler Comprehensive Compensation (C3) system. As a developer on the pre-XP C3, Chet saw how poor communication, inadequate testing, and an overly complex design can doom a development effort. He helped make the decision to throw away 14 months of work and begin again under the guidance of Kent Beck, Martin Fowler, and Ron Jeffries. Chet, along with Jim Haungs and Rich Garzaniti, in a talk at OOPSLA’97, was the first to report on the “Chrysler Methodology” as the term Extreme Programming had not yet been coined. Chet is an independent consultant, helping software teams improve the software development process by the application of XP’s core values of simplicity, communication, feedback, and courage. His clients have ranged from federally charted quasi-public financial institutions to the developers of real-time petroleum exploration equipment. He is an author of Extreme Programming Installed. The book, the second in the Extreme Programming series, consists of a connected collection of essays, presented in the order the practices would actually be implemented during a project. He and Ron Jeffries are the proprietors of agilesoftwaredevelopment.org.

Debra Lavell has 10 years experience in quality engineering, currently working as a Program Manager in the Platform Quality Methods Group, part of the Corporate Platform Office at Intel Corporation. Her role is to help drive good requirements engineering practices into Intel’s various product development teams. Prior to her work in quality, Debra spent 8 years managing an IT department responsible for 500+ node network for ADC Telecommunications. Debra has been involved in PNSQC since 1999, as an attendee, paper presenter, and various positions on the board. Debra is a member of Portland, Oregon’s Rose City Software Process Improvement Network (SPIN) steering committee where she coordinates the monthly speakers, and communicating meeting information. She holds a Bachelor’s of Arts degree in Management with an emphasis on Industrial Relations.

Email: president at pnsqc.org

Keith Stobie is a Test Architect at Microsoft where he plans, designs, and reviews software architecture and tests for Search and XML Messaging (Windows Communication Foundation). Over the past 25 years he has focused on software testing distributed systems including Tandem Fault Tolerant systems, Informix Parallel database, and transactional and collaborative software at BEA Systems. Keith provides training on inspections and quality process, and test training, strategy, methodology, design, tools, and automation. Keith has mentored and coached hundreds of professionals in the field. He writes and speaks to conferences around the world on software engineering, SQA, and testing.

Email: vp at pnsqc.org

Doug Reynolds is a Software Quality Engineer at Tektronix Inc., in Beaverton Oregon. Doug has worked for Tektronix for the past 13 years. He holds a Master of Computer Science and Engineering from Oregon Health & Science University (OHSU) and a Bachelors of Science in Electrical Engineering Technology from Oregon Institute of Technology. Doug has presented at PNSQC on four different occasions and has assisted with the Exhibits Committee, Selection Committee, and Review Committee. This past year Doug was the PNSQC Secretary and is currently serving as the PNSQC Treasurer.

Email: treasurer at pnsqc.org

David graduated from Cambridge (UK) with a degree in Mathematics. He spent the years between 1960 and 1995 working worldwide in the oil exploration profession using the computer for both seismic signal analysis and for mapping. In 1995 he moved to Portland where he was briefly involved in a medical ultrasound startup venture. In 1999 he took over as IT manager at the CDRC division of OHSU and presented a PNSQC paper on their Y2K project methodology. In 1999 he also graduated from OGI with a MS degree in computer science. When he retired in 2004 he became increasingly involved in PNSQC and has served as program chair for the past three conferences.

Email: secretary at pnsqc.org

Bill Gilmore is the Operations and Infrastructure chair for PNSQC. He has worked in software engineering for over 20 years in various development, management, process and consulting roles. He worked in two small companies, then worked at the Software Engineering Institute at Carnegie Mellon. He moved to Oregon in 1993 to head up the Software Process Improvement program at Tektronix. Most recently he worked at Intel for 10 years with several product teams and business groups on software product quality, product life cycles and several areas of software engineering. He led CMM and product life cycle assessments and organized and led follow-on improvement programs. Bill has a Ph.D. in Astronomy; has published papers in Software Engineering, Strategic Planning, and Astronomy; and has presented at several conferences.

Email: operations at pnsqc.org

Marilyne Pelerine works as IT QA Manager for Symetra Financial in Seattle, a company with over $20 billion in assets. She has worked in information technology for several financial services companies in various roles for the past 18 years. As part of Quality Management Services, and under her leadership, the QA team provides focus on quality through best practices resulting in cost-efficient technology solutions for Symetra’s business partners and excellent service to customers. Marilyne holds a Bachelor of Science degree in Management and Psychology from University of Massachusetts. This is her first year serving on the PNSQC Board of Directors.

Email: audit at pnsqc.org

A quality evangelist and current Conference and Program Chair, Ian is a veteran software developer, quality assurance engineer, and manager with experience in the manufacturing, financial services, construction, and security domains. Since 1979, Ian has improved productivity and software quality through rigorous development methods and processes and now through the diligent application of Agile methods. He attended the very first PNSQC in 1983. Ian has contributed to SAO QASIG, PDX Software Roundtable, ASQ’s CSQE, and the SEI’s SEPG conference. As an Agile Alliance member and Agile Manifesto signer, his current interests include a) collaborative quality and b) applying agile methods to nurture high performing teams that produce profitable, maintainable products. Go, Beavs!!

Email: program at pnsqc.org

Non-Members

Members

• a paper
• request to be a sponsor
• request to present a display

We start with the “What”; experience gives us the “How.” Applying our knowledge of process, developing a technique of implementing it and adapting that implementation to the constraints of the project and culture bring success. Project methodologies are not static and must adapt. Critical chain, agile and classic waterfall all have their place and a blend of them can be used on the same project.When determining what to do to improve project deployment, you often have to start by bringing things back to a common baseline-implementing all or part of a classical project management process. This has the effect of “draining the lake” so that the rocks are visible. From there you can look at implementing a different approach.It is desirable to implement a new philosophy from the start, but that requires the knowledge that something is wrong with the current methodology. More likely the attitude is that it is the project that is “bad.” Blaming the project lays the blame on one entity and not the organization’s methodology. Subtle, even covert, implementation of different processes on a project and then reporting on the success, sighting other areas where the technique will work, helps evolve the management style.

The process that’s required for developing software is determined by the attributes of the quality required. And those attributes are determined by what the users (who the users are, what their needs are, and the environments in which they will use the product) require for their usage to be beneficial, successful and/or enjoyable. Which means, if you don’t have an in-depth understanding of the users and how they will use the product, you can’t make claims about quality or what process to follow to provide it.

Software processes and methodologies are tools software professionals use to build products that satisfy their user base. It is important to choose the right tool for the job considering the complexity of the project, the experience level of the people using them, and a proven track record of working. Processes and methodologies give us an avenue to build successful products and are not as important as building a cohesive team focused on a common goal.

What do we mean by “mature” software development processes? Software-intensive organizations need the ability to control, manage, and optimize product development, to be sure; but maturity entails more than this. Maturity also implies that an organization’s development processes are well-adapted to its operational and strategic objectives, and that these objectives may be achieved with a minimum of internal conflict, confusion, stress, and frustration. The Technical perspective (e.g., metrics and measurement; process definition; V&V) is necessary, but not sufficient to achieving software quality. Success requires that the Organizational perspective (e.g., innovation; creativity; adaptation to market conditions) and the Personal perspective (e.g., jelled teams; working styles and communication skills; trust, advice, and friendship) must also be taken into account. Skillful blending and balancing of T+O+P considerations is the hallmark of a truly mature software organization.

My work on improving software quality focuses on the “real” developers–the people actually writing the code. As a result, I’m interested in tools, techniques, and methodologies that these people can use to improve the quality of the code they produce. Regardless of the development process being used, these people need to know what they’re supposed to produce and the constraints under which it must be created (requirements), need to have a vision for how they’ll implement it (design), need to produce something executable (coding), need to have a way to verify that they’ve implemented what they’re supposed to (testing), and need to satisfy a host of additional requirements that are often left unstated (e.g., source code comprehensibility, modifiability, and portability). They must also typically balance pieces of “best practice” advice that may not be fully compatible, e.g., encapsulation vs. testability, speed vs. loose coupling, graceful failure vs. minimal footprint. I’m especially interested in the issues facing library developers, who can never know all the ways in which their software is used and who must typically ensure backwards compatibility for almost every release. Finally, because I often work with C++ developers whose code bases are very large, were developed over a decade or more, are extremely performance-sensitive, and are mission-critical, I’m interested in the practicality of quality improvement recommendations for software systems of this nature.

I am honored again this year to host a panel of experts about a topic I think may be important in our community. With this year’s conference theme: “Quality: A Competitive Advantage,” the conference organizers let me choose a sidebar on a congruent topic, so I chose something very few of us stop to think about - value.There are many definitions of quality, for example, but my favorite is from Jerry Weinberg: “Quality is value to some person.” Value is not about price, it is about what you get for the cost. Something given free, may wind up “costing” you a lot of time and money. Conversely, something that is expensive may prove to pay for itself very quickly.It is a subjective concept that intrigued me enough to want to choose colleagues who I thought would bring value to the topic of Value, so consider this an invitation to spend some time exploring it with us at lunch on Wednesday!

I have been strongly influenced by Jerry Weinberg in my thinking about quality and value. He defines quality as “value to some person,” and value as “what someone will do or pay to have his or her requirements met.” He also points out that, like quality, “purpose” is not an intrinsic property of a product, but rather a relationship between the product and a person. Finally, that which we call a product is a system built out of smaller systems and part of some larger system.For some testers, these ideas are unsettling. “Surely quality, purpose, and value aren’t subjective!” is a common reaction. “How can we testers make decisions about quality if everyone’s idea of quality is different?” After years of thinking about it, I am convinced that quality, purpose, and value are subjective, and that testing therefore involves a good deal of uncertainty. We testers can live with that uncertainty, though, and even embrace it. First, our role is to provide information to managers and to the rest of the project community, not to make decisions about the product or the project; that is properly a management task. Second, I believe we do better testing when we consider the system, instead of the product; multiple users, instead of “the user”; possible purposes, instead of “the purpose”; and varieties of values, instead of “the value”. If we embrace subjectivity-or diversity-we can anticipate more risks, find more bugs, and provide more value to more people.

Brian believes that if software quality professionals want to not merely survive but thrive in an increasingly competitive world, they need to understand how value is determined by customers and by business stakeholders.

The concept of “value” as it applies to software or other products or commodities is a difficult one. While value can be measured in objective units, such as dollars and cents, in reality it is largely subjective. Unlike quality, for instance, which is measurable against specific standards or a set of objectives, the value of a product is typically defined in terms of what a customer is willing to exchange for it. In a perfect world, high quality always equals high value, but as we see every day, that is not always the case. While quality frequently drives value, especially over the longer term, customers are still the final arbiters. Customers are influenced by a marketing, packaging, reputation, pricing, accessibility -in addition to their own objective standards.The key to producing something of value as it pertains to software is deceptively simple — understand what your customers not only need, but what they want, and then design and build a quality product to those standards. It gets more deceptive and less simple when you recognize the danger of listening to your customers too closely, forgetting that they are paying you to build them a product for a reason - often because they lack the skills or the resources to build it themselves. All too often testers are confined to a strict quality assurance role - they verify quality all day, testing output against input, a product against a design. However, testers are first and foremost customer advocates. In the rare cases where they are given the voice to test the design itself, at that point, a tester evolves beyond “simply” verifying quality, and can begin truly testing a product’s value.

The value that I have been most concerned about for the past six years has been educational value. Most software testing techniques were developed during a time when a big program was 10,000 lines and written in COBOL, a language almost anyone can read. An enterprising tester could read the entire program, list all the relevant variables, identify most of the interesting combinations, and lovingly handcraft an appropriate set of tests. Today, we snap together massive programs–my cell phone has over 1,000,000 lines of code. Programmer productivity has skyrocketed while tester productivity has increased linearly. At its best, (slightly) automated regression testing increments tester productivity a little more. When programmer productivity rises sharply faster than tester productivity, our impact on projects declines. To the extent that testing is valuable (and I do think it is very valuable) the diminishing significance on projects that is a natural consequence of differential productivity becomes a serious problem.One of the reasons programming evolves so rapidly is the strong educational support for programmers at university. New ideas spread quickly, into new courses or modifications of the standard courses. Educational support for testers is not so strong. There are no degree programs in testing–most universities offer zero or one testing course. Even the handful that offers two or three courses can only teach so much in that small amount of time. As a result, most training in testing will probably continue to be industrial–learning on the job by yourself, by in-house classes, or from a commercial trainer.I went back to university because I felt, as a successful commercial trainer, that the short course format offered little potential for skill development or for the development of a real appreciation of new ideas. There just isn’t enough time in the short-course format, not enough time in class, not enough time for homework, and not enough calendar time for someone to think over a new idea, try it on her own projects, then come back to the course and comment on how it worked (or didn’t) in her situation.My question is this: “How can we adapt the university instructional models to industrial training, in order to promote skill development and propagation of new ideas and technologies?”If testers are going to continue to add serious value to projects, we need educational support that can help foster and spread deep change, rather than teaching and testing students (certification candidates) a superficial rehashing of the same stuff people were learning in the 1980’s.

How do you model a system for software application development? How do you measure, manage, and control such a system? How might you go about defining the goal and measuring productivity and quality in meaningful ways that matter to customers? How would you create a methodology in the spirit of the teachings of W. Edwards Deming?This presentation will promote the idea that application development can be modeled as a value chain and mapped with a state model allowing the tracking of work items queuing at each stage in the process lifecycle. Such foundation then enables the use of techniques such as the Theory of Constraints, Lean/Kaizen and Six Sigma to measure, manage and control a quality assurance program to drive continuous improvement.

David Anderson is the author of “Agile Management for Software Engineering” published by Prentice Hall in 2003. He is a recognized expert in agile software development and management methodologies, the application of management science and techniques such as The Theory of Constraints, Lean, and Six Sigma to software engineering problems. David works for Microsoft as the architect for the Microsoft Solutions Framework (MSF) methodology and designed the MSF for CMMI Process Improvement process template - the first mass market solution to bring together agile and CMMI. David is a regular conference speaker. He has published widely on the topics of software development management, productivity, quality assurance, and continuous improvement.

Jon Bach

Two decades after the term “exploratory testing” was invented, testers and managers still do not understand it completely. Worse, experts consider it an art, implying that there is no way to teach it or improve one’s skill at it. This presentation will try to shatter that myth and describe specific skills and tactics that testers can use to improve their unscripted testing ability while gaining credibility and confidence.

In his ten-year career in testing, Jon Bach has led projects for many corporations, including Microsoft, before starting with Quardev - an onshore test outsourcing company in Seattle. As Manager for Corporate Intellect, he manages testing projects ranging from a few days to several months using Rapid Testing techniques (like SBTM). He is the speaker chair for Seattle’s Quality Assurance SIG, as well as a regular guest speaker for Seattle-area testing forums and universities. In 2000, Jon and his brother James created “Session-Based Test Management” - a technique for managing (and measuring) exploratory testing, for which he is a recognized expert.

Jim Brosseau

Software development in a team environment needs to be consciously managed to be effective, and we all need to recognize our role in this effort.

Jim Brosseau has a career spanning more than 20 years in a variety of roles and responsibilities. He has held successively more responsible positions in military and defense contracting, commercial software development, and training and consulting. He has worked in the QA role, and has acted as team lead, project manager, and director. In addition, Jim has worked with more than 60 organizations in the past 7 years with a goal of reducing business inefficiencies. An integral part of this effort has been a focus on techniques for measurement of productivity gains and ROI for refined development and management practices.

Jim Brosseau

While commonly used external benchmarks can provide some insights, it is important to balance this with internal information to gain a complete objective picture.See P-112 for bio.

David Card

In an era of tight budgets and increased outsourcing, getting a good measure of an organization’s productivity is a persistent management concern. Unfortunately, experience shows that no single productivity measure applies to all situations. This article discusses the key considerations for defining an effective productivity measure.

David Card is a fellow of Q-Labs. Previous employers include the Software Productivity Consortium, Computer Sciences Corporation, Lockheed Martin, and Litton Bionetics. He spent one year as a Resident Affil