Many teams struggle with test creation due to miscommunication or a lack of requirements, testers not being present during design phases or discussions, a shortage of time, or incomplete information. But that doesn’t mean you should turn to guesswork. Your tests will suffer in quality and completeness. We must always strive to get the desired requirements.
If you're starting or improving a security program for your software, you probably have questions about the requirements that define security. Data need to be complete and trustworthy, and also accessible on demand, but only to the right people. The CIA triad defines three principles—confidentiality, integrity, and availability—that help you focus on the right security priorities.
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.
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...
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...
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...