requirements

Articles

A line of identical rubber ducks The Unspoken Requirement: Testing for Consistency

It's easy to see that style consistency is important when discussing the user interface. But there are other areas where being consistent is just as important, even though they are not as visible. Consistency is one of the quality attributes of a product—any product—even if it is not stated clearly in the requirements documents, and testers have a responsibility to check for it.

Michael Stahl
man guessing Don’t Guess Your Tests—Strive for Complete Requirements

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.

Nishi Grover Garg
lock Using the Principles of the CIA Triad to Implement Software Security

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.

Sylvia Killinen
Agile Development Conference West logo ADC West 2015 Keynote: Lean UX: Turn User Experience Design Inside Out

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.

Beth Romanik
Test Documentation Just Enough Test Documentation

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.

Tara Nicholson
Analysts Craft How Analysts Can Show Craftsmanship in Their Work

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.

Terry Wiegmann
Management and Team Details “Let’s Just Get Started and We Can Figure Out the Details Later”

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.

Ryan McClish Kenton Bohn
Code Coverage Is Code Coverage a Silver Bullet?

While code coverage is a good number to look at in terms of reach achieved in a testing cycle, is it foolproof? Is this metric a silver bullet for understanding the team’s coverage and vouching for testing scope? In short, no. But it is a vital step on the way to solving your testing coverage issues.

Mukesh Sharma
Automation is Not God Automation Test Suites Are Not God!

In today’s age of tight deadlines and accelerating delivery cycles of software, test automation is surely favorable for the world of functional testing and critical to the success of big software development companies. But its various benefits have led to unrealistic expectations from managers and organizations. This article highlights the role and use of automation in an agile context and the irreplaceable importance of manual testing.

Nishi Grover Garg
Requirements for Testing 3 Types of Requirements for Testing

Requirements for software are usually grouped into a bewildering array of categories. Functional and nonfunctional requirements are on top, and a huge number of subcategories are underneath. Here, Clint Hoagland boils it down to three categories, differentiated by the way they should be tested.

Clint Hoagland

Pages

StickyMinds is a TechWell community.

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