When developing products, features, and enhancements, you have to have your customers’ best interests at heart. “We’re not just creating software,” speaker Jeff Patton said. “We’re changing the world.” You need to better understand the people you’re building things for, and the only way to do that is to spend more time with them.
Many options are available for test teams to help them document how a system should work. A test strategy, test plan, test charter, test cases, test scenarios, and automation scripts are examples. This article has a matrix comparing the types of test documents you might choose and can help you pick which is right for you based on project characteristics.
A craftsman could be defined by having enough experience to anticipate and prevent clients' problems before they even know they are going to have them. How might craftsmanship be manifested in analysis work? Terry Wiegmann captured some practices analysts can employ to demonstrate craftsmanship to their customers.
Regardless of your organization’s approach, if everyone is not aligned on what defines project success, you are headed for trouble. Well-defined success criteria are the guardrails that keep the project on track to meet business expectations. Ryan McClish and Kenton Bohn tell you why you should get all the details figured out now rather than later.
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.
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.
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.
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.
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.
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.
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.
When talking about requirements, people use identical terms and think they have a common understanding. Yet, one says user stories are requirements; another claims user stories must be combined with requirements; and yet another has a different approach. These “experts” seem unaware of...
The practice of software development requires a clear understanding of business needs. Misunderstanding requirements causes waste, slipped schedules, and mistrust. Developers implement their perceived interpretation of requirements; testers test against their perceptions. Disagreement can...
People talk about requirements, use identical terms, and think they have a common understanding. Yet, one says user stories are requirements; another claims user stories must be combined with requirements; and another has a still different approach. These “experts” seem unaware of the...
One key to specifying effective functional requirements is minimizing misinterpretation and ambiguity. By employing a consistent syntax in your requirements, you can improve readability and help ensure that everyone on the team understands exactly what to develop. John Terzakis provides...