|
|
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.
|
|
|
Get Your Testing Message Across We all know how important test progress (or lack of) is to the success of the project. But why is it that sometimes no one takes notice? Valuable test reports provide information that is needed, not just easy to gather. Test progress reports aid management in decision-making and risk assessment and help testing teams set priorities. In this presentation, Isabel Evans asks, "Do our reports add value for their audience or are we just supplying 'chart junk' that will not be read? Are we providing teams and managers with information they need or giving them what we have? Do our reports and charts emphasize or hide our message? Are our reports clear and to the point?" She discusses what types of information different audiences need and when; how to display information using charts, diagrams, and text to be effective; and how to predict future progress from past reports.
|
Isabel Evans, Testing Solutions Group Ltd.
|
|
|
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
|
|
|
Cosmic Truths about Software Requirements The history of many software projects shows that requirements mistakes are the most expensive ones to correct late in development. So, why do we make big requirements errors over and over, even in mission-critical software projects? Karl Wiegers, author of a best-selling book on software requirements and a consultant on many such projects, shares his top ten requirements principles to help your organization produce accurate, consistent, and unambiguous requirements. Although there are few absolute truths in software development, Karl has found several that almost universally apply to software projects. These principles emphasize the critical contribution that good requirements make to a project's success, and the critical contribution that customer involvement makes to good requirements.
|
Karl Wiegers, Process Impact
|
|
|
A Defined Process for Requirements Peer Reviews Most software projects include reviews-whether or not they are officially part of the development process. Unfortunately, these reviews are often inefficient, and even unproductive. Implementing a defined peer review process for requirements is an excellent means to both improve your requirements and kick-start overall process improvement because participants can immediately see timesaving and increased quality in work products. Find out how to measure benefits and potential savings from these reviews and how they can identify major gaps in other project processes. Take away a Peer Review Toolkit that allows your team members to start their first effective requirements review right away.
- A simple, efficient peer review process with a 30-minute training program
- Instant results and metrics, including potential savings
- A Peer Review Toolkit to get started.
|
Rob Wyatt, Wachovia
|
|
|
Refining Requirements with Test Cases Requirements are supposed to be the basis of most test cases, but can you use test cases to define what the system needs to do--to improve or to actually become the requirements? To some degree, your development process dictates the opportunities you have for test cases to define or refine requirements. However, everyone can benefit from test case writing techniques to identify missing requirements, surface ambiguous statements, and expose implied requirements early in the process. Find out how Tanya Martin-McClellan produces test cases that accurately reflect the requirements, as they are understood at the time, and conducts team reviews to find the gaps and misunderstandings. Although more time is spent writing and rewriting test cases, less time is spent later discussing requirements.
- Find the vaguely defined parts of the requirement definition
- A template of implied requirements you can customize
|
Tanya Martin-McClellan, Texas Mutual Insurance Company
|
|
|
Expressing Requrirements as Users Stories - an Agile Approach Expressing requirements as user stories is one of the most broadly applicable techniques introduced by eXtreme Programming and adopted by other agile development processes. User stories are an effective approach for capturing requirements from an agile project, not just those using XP. In this session learn what user stories are, how they differ from other requirements approaches, and why you should consider using them. You also will learn the six attributes all good stories must exhibit and see how to get started with user stories. Whether you are a developer, requirements analyst, tester, manager, or even a customer interested in applying agile techniques to your projects, this session is for you.
- The differences between user stories and other requirements documentation
- Attributes of "good" user stories
- Examples of User Stories from agile development projects
|
Mike Cohn, Mountain Goat Software
|
|
|
When Saying Yes Doesn't Help: Software Development as Codependent Behavior Vague requirements, undocumented design, poor code, and impossible schedules-these are the typical complaints of many developers. Whose fault is it? Of course, it is "their" fault-senior management, customers, users, etc. But, could we be part of the problem? Codependent behavior is defined as "a way of getting needs met that doesn't get needs met. We do all the wrong things for all the right reasons." When we agree to develop systems without understanding user needs, we teach others that participation in the project is not important. When we agree to absurd schedules, we teach others that our legitimate needs do not matter. In this compelling session, learn what codependency is, recognize codependent behavior in yourself and others, evaluate the negative effects of codependent behavior, and ways to respond more appropriately to unreasonable demands.
|
Lee Copeland, Software Quality Engineering
|
|
|
RequireMINTS - Fresh Approach to Analyzing Requirements Studies show that most application defects are introduced before a single line of code is developed-with many (if not most) of these defects attributed to poor requirements. Studies also show that it is less costly to identify and correct these defects prior to code development. Despite this data, many of us have requirements analysis approaches that have become stale and are ineffective. Many analysts acknowledge that their processes need some improvement but feel helpless to do much about the problem. Dion Johnson offers a package of small yet effective "RequireMINTs" that will freshen up those stale requirements processes in a highly practical way. You will take away a road map for collecting metrics that make a case for requirements improvements, identifying necessary improvements, and implementing these improvements.
- Reverse the reverse-engineering trend with better requirements
|
Dion Johnson, DiJiMax Consulting, Inc.
|
|
|
Risk Based Testing for Measured "Go/No Go" Decisions 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
|
Dave Kapelanski, Compuware Corporation
|
