Articles

A piece of plain paper laid over a pile of other paper with typed words Overcoming Challenges to Good Test Documentation

Getting good test documentation is a consistent challenge. Agile proposes that you should go very light on documentation, and while test documentation does not need to be heavy, it does need to be clear and cover all that the product is intended to do so you can ensure testing is consistent and results are recorded. Here's how to overcome some major barriers to getting good test documentation.

Steven Penella's picture Steven Penella
Person solving a Rubik's cube Eliminate Fake Certainty and Solve the Real Problem

Too often, customers have a “fake certainty” about the problems they want to solve. They might not have defined the real problem, but they have frequently defined the solution anyway. The risk is that we might build the wrong thing. When the product owner works with the customers to define the problem, then works with the team to define the solution, everyone can win.

Johanna Rothman's picture Johanna Rothman John Le Drew
Requirements model Requirements Mapping Using Business Function Test Suites

On this team, testers were overcommitted, avoidable defects were surfacing, and documentation was hard to find. Worse, trust and morale were low. Upgrading tools was out of the question, so the testers decided to take matters into their own hands and create incremental change themselves. Here's how a team added a new type of traceability to its requirement test case world.

Balazs Schaffhauser's picture Balazs Schaffhauser
Technical writing Fitting Technical Writing into Agile Development

As teams strive to move to a mature agile process, technical writers must adapt as effectively as the development personnel. This new agile process demands that knowledge dealing with software or product releases is only sparingly documented up front, making the technical writer's job of gathering information much more dependent on talking with people over reading requirements.

Robert Spielman's picture Robert Spielman

Better Software Magazine Articles

Cross Platform Development 10 Lessons Learned in Cross-Platform Development

Building an app for a single platform is difficult, but designing, implementing, and testing an app targeting multiple operating system platforms can be next to impossible. The secret balances upfront design with customer feedback.

Dewey Hou's picture Dewey Hou
Requirements Reuse: Fantasy or Feasible?

Software development teams think nothing about reusing code, but what about requirements? The benefits include faster delivery, lower development costs, consistency across and within applications, fewer defects, and reduced rework.

Karl E. Wiegers Joy Beatty
Lessons Learned from Ancient Wisdom: A Software Review Story

Lessons learned long ago from reviews and inspection can be effective today, particularly in collaboration within agile teams. Learn how an organization used review techniques as part of its agile collaboration, including the advantages and potential problems of this ancient wisdom.

Dorothy Graham's picture Dorothy Graham Robert Sabourin
Simplicity and Precision: Test Planning in Agile Projects

Test planning is often thought unnecessary in an agile project. However, if our mindset is on "planning" rather than "plans," we see that test-planning activities happen throughout the project, taking advantage of levels of precision, i.e., what is absolutely necessary at each level.

Janet Gregory's picture Janet Gregory

Interviews

The Essential Product Owner—Championing Successful Products: An Interview with Ellen Gottesdiener
Video

In this interview, Ellen Gottesdiener talks about her presentation at Agile Development Conference and Better Software Conference West 2014, the importance of having context for requirements, good ways to set value considerations for requirements, and the common mistakes of product owners.

Application lifecycle management expert Stefano Rizzo Leverage Social Media for Requirements Gathering: An Interview with Stefano Rizzo
Podcast

Stefano Rizzo introduces the idea of using social media to encourage customers to get involved in the requirements gathering process. Learn how by introducing something that your customers are already contributing towards, you can capture the mood behind their true wants and needs.

Noel Wurst's picture Noel Wurst
Tim Lister Responsibly "Right" Requirements: An Interview with Tim Lister
Video

Tim Lister explains how getting the right requirements the first time from your stakeholders may not be easy, but it can be done, and it's worth the effort. Learn how with clear expectations, communication, and integral development, products can be delivered on time and to everyone's satisfaction.

Noel Wurst's picture Noel Wurst
Traceability's Priceless Role in Agile: An Interview with William Gens

William Gens sits down with Noel Wurst to describe "the art and science of traceability" ahead of his STAREAST session of the same name. Learn what makes traceability meaningful and such a valuable asset to projects, no matter how bad the requirements may seem to be.

Noel Wurst's picture Noel Wurst

Conference Presentations

STAREAST Example Mapping: The New Three Amigos
Slideshow

Example mapping is a collaboration technique used by teams to help refine requirements. Every team should have a set of “ready” criteria that includes some kind of workshop for development team members to establish a shared understanding. In a time-boxed example mapping session, rules will summarize examples or constraints about a user story, and the team will document questions about outcomes or dependencies for future refinement. The end result is requirements written as user behavior, with a shared understanding among all roles on the agile team. Join Thomas Haver to participate in a live example mapping session and learn how to implement the workshop within your own team.

Thomas Haver
STARWEST 2018 Managing BDD Automation Test Cases inside Test Management Systems
Slideshow

Behavior-driven development (BDD) has been around for a while and is here to stay. However, the added abstraction levels pose a technical problem for writing and managing tests. While BDD does a great job of marrying the nontechnical aspect of test writing to the technical flow of an application under test, keeping this information under source control becomes problematic. Frameworks such as JBehave, Cucumber, or Robot give subject matter experts that additional ability to write tests, but they are often restricted access from them; because people treat test cases as code, they get stored in source control repositories. Additionally, these given-when-then steps soon can grow to an extent where they are difficult to manage without an IDE, and nontechnical people lose interest. Using management tools, Max Saperstone shows how to manage these nontechnical steps and keep them in sync with the automaton in tools such as Git.

Max Saperstone
STARWEST 2018 Mission Critical Automation Testing
Slideshow

When critical subsystems fail, the resulting losses can be catastrophic. In the insurance industry, if premiums are miscalculated, defect costs can reach well over a million dollars. In this session, Mike Keith and Dom Nunley draw on their practical experience with insurance systems testing to provide an overview of combinatorial automation testing for high-risk backend system areas—i.e., features that absolutely must work correctly. They share a process for categorizing requirement risk levels to determine which requirements warrant combinatorial testing. Mike and Dom illustrate various combinatorial testing techniques such as N-FAT, N-Wise, and RANDOM, which can be used to automatically generate test cases. These methods are used to ensure coverage against risk while controlling the number of tests that run.

Mike Keith
Better Software West 2018, Agile Dev West 2018, DevOps West 2018 The Five Biggest Mistakes Your Team Is Making in Requirements Definition
Slideshow

Google pioneer Alberto Savoia offered this sage advice: Build the right "it" before you build It right. But few software companies take the time to define, much less build, the right "it." The problem starts with a poor requirements definition process. In this session, join Kathryn Campbell as she examines the five most common mistakes that software companies make during requirements definition—and how to avoid them. First Kathryn defines thinking too small as a huge problem and shows you how to broaden your perspectives. Next, she exposes being stuck in the past, with legacy systems maintaining too much control of our innovation. The third mistake is assuming too much about your customers. Kathryn shares guerrilla techniques for gathering rapid, inexpensive customer feedback at every stage of your requirements and design process.

Kathryn Campbell

AgileConnection is a TechWell community.

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