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.
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.
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.
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.
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.
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.