requirements

Conference Presentations

Executable Specs w/ FitNesse Selenium

"Executable Specifications with FitNesse and Selenium."

Dawn Cannan, DocSite LLC
Meet "Ellen": Improving Software Quality through Personas

Users are the ultimate judge of the software we deliver because it is critical to their success and the success of their business. However, as a tester, do you really understand their tasks, skills, motivation, and work style? Are you delivering software that matches their needs and capabilities-or yours? Personas are a way to define user roles-imaginary characters-that represent common sets of characteristics of different users. David shares how his team at Microsoft defined and used one persona named “Ellen” to help them design, develop, and test the first version of a new product. David shares before Ellen and after Ellen examples of the product, showing how the product changed when Ellen joined the team. See examples of the robust test cases and acceptance scenarios they defined from unique insights that Ellen provided.

David Elizondo, Microsoft Corporation
The Many Hats of a Tester

As testers, we must wear many hats to do our job effectively. Quite often, it is the pith helmet of an explorer, hacking through the vines and darkness of the unknown; or the baseball cap of the crime scene investigator, determining how the failure occurred. To make things even more interesting, the hats we need often differ from project to project and organization to organization. Adam Goucher begins with a general discussion of some hats testers typically wear and when they are appropriate or inappropriate. He then leads an “Art Show” exercise-a brainstorming process resulting in lots of “art” on the walls-illustrating the hats we all may wear in our daily testing activities. Through the Art Show process, you'll take away new insights into what hats you and other testers need, tips for wearing the beautiful ones with success, and how to avoid putting on the ugly ones.

Adam Goucher, Zerofootprint
Stop Guessing About How Customers Use Your Software

What features of your software do customers use the most? What parts of the software do they find frustrating or completely useless? Wouldn't you like to target these critical areas in your testing? Most organizations get feedback-much later than anyone would like-from customer complaints, product reviews, and online discussion forums. Microsoft employs proactive approaches to gather detailed customer usage data from both beta tests and released products, achieving greater understanding of the experience of its millions of users. Product teams analyze this data to guide improvement efforts, including test planning, throughout the product cycle. Alan Page shares the inner workings of Microsoft's methods for gathering customer data, including how to know what features are used, when they are used, where crashes are occurring, and when customers are feeling pain.

Alan Page, Microsoft
Architecture and Design: What Managers Need to Know

In many current software development approaches, architecture and design are downplayed. Rather than actually architecting products, good designs are assumed to "emerge." Yet, managers must be confident that their products are well designed. In their efforts to produce products quickly, teams may overlook vital architecture and design issues, such as performance, security, usability, and accessibility. When managers try to help, they can be deterred by jargon and tools that are difficult for non-programmers to understand. Jonathan Kohl illustrates a way for managers to understand and influence product architecture and design. You don't need detailed technical skills to provide valuable insight into a project. Learn how to understand an application and its impact in three contexts: the code (where the application is developed), the system (where the application operates), and the social context (where the application is used).

Jonathan Kohl, Kohl Concepts Inc.
Ensuring Quality Requirements

Quality assurance is more than just testing software through processing a series of controlled inputs and outputs. It must also include an assessment of all the deliverables associated with the project. Developers and testers often view software documentation as merely a source of information, not as artifacts that require evaluation. All software documentation should undergo a rigorous quality assessment just as the actual software is subject to comprehensive testing. Mark Haynes describes quality models and attributes that can be used to evaluate requirements documents. He shows how imprecision (that will haunt you later) can be detected and removed through a set of formal criteria and informal heuristics. To experience using these techniques, Mark shares examples of poorly written requirements for you to evaluate and improve. Additional quality attributes, even subjective ones, can be used to conduct a quality dialogue.

Donald Haynes, Synova
Introduction to Multi-Stage Continuous Integration

A full, continuous integration build and test is a key component of most agile processes. Unfortunately, as systems grow in size through consecutive iterations, these builds can easily take thirty minutes or more. Before you finish the build, other people's check-ins will invalidate your continuous integration (CI) results. Multi-stage CI solves this problem by limiting project-wide churn and allowing CI to scale to large projects. With Multi-Stage CI, each team does a team-based CI first and then cross-integrates the team's changes into the mainline code base. Damon Poole introduces the Multi-Stage CI process, discusses its benefits, presents examples of how to implement and automate it in both local and distributed environments.

Damon Poole, AccuRev
Do the Right Thing: Adapting Requirements Practices for Agile Projects

Some agile teams rely on user stories alone to articulate requirements, struggle with requirements rework on large agile projects, and spend too much time thrashing on requirements during iterations. Requirements expert and agile coach, Ellen Gottesdiener shares a wide spectrum of requirements practices ranging from traditional to agile to help you break out of the cookie-cutter mentality that some take toward requirements elicitation. Practitioners from a traditional environment learn how classic requirements practices are adapted on agile projects. Agile practitioners learn how they may lighten, tighten, or incorporate a subset of traditional requirements practices to mitigate risks associated with missing, erroneous, or conflicting requirements. Gain an appreciation of ways to adapt requirements practices to fit various project situations so you can do the right things for your project.

Ellen Gottesdiener, EBG Consulting, Inc.
Driving User Stories from Business Value

Implementations of agile and Scrum typically employ user stories as the primary method for discovering requirements. User stories provide the mechanism for the fast, flexible flow of ideas into completed increments of software. What's missing is a practical approach to discovering user stories from top-down, business valued, and prioritized capabilities. Guy Beaver shares proven approaches to allow a project-driven organization to transition to business features that can be predictably estimated and planned for release. The stories unfolded from business features have clear line-of-sight to business goals and allow for the timely discovery and management of technical considerations.

Guy Beaver, Net Objectives
Agile for Business Analysts

A prevailing myth in the software industry is that business analysis requires a bloated requirements elicitation and documentation process. Although the Business Analysis Body of Knowledge (BABOK) is considered to be process agnostic, many business analysts create heavy requirements when they follow this document's guidelines. Bob Hartman busts this myth by explaining how to use generally accepted practices from the BABOK in an agile way. Drawing directly from the BABOK, Bob bridges the gap that many business analysts have regarding lightweight process, especially as it relates to larger projects and organizations. Gain the ability to use BABOK practices in an agile environment and develop an understanding of how to use them in more agile ways in traditional software development. Learn to eliminate waste in any bloated process and become comfortable regardless of the development methodology you use.

Bob Hartman, Agile For All

Pages

StickyMinds is a TechWell community.

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