Testers use requirements as the basis of test cases, review them for testability, and often participate in general requirements reviews or inspections. However, many testers have little knowledge of requirements engineering. Erik van Veenendaal provides five critical success factors to get started.
People and organizations definitely should take security seriously. That said, some of the “experts” advising about password security are going too far. Frequent password changes give the appearance of more robust security without actually affecting anything. Payson Hall unpacks this requirement.
Tim Berners-Lee, inventor of the World Wide Web, said, "Access by everyone regardless of disability is an essential aspect." But websites using sophisticated visual effects make it difficult for the blind and disabled to have equal access. It's important to design and configure sites for everyone.
There are many misconceptions about accessibility that prevent people from making a conscious effort to incorporate it into their websites. But really, developing and testing accessible websites doesn't require more work, and it has many benefits. Let’s disprove the top four web accessibility myths.
Once a testable requirement or acceptance criteria have been “created,” there is a tendency to assume that the task can be considered completed. Because that may or may not be true, it is better to continue to pay attention to testability. Here are four ways to maintain testable requirements.
Online social identity is almost a necessity these days, and companies are reaping the benefits of using social media to connect with customers. Rajini Padmanaban highlights John Legere, TMobile CEO, and his success with using social media to connect first-hand with users.
Discovering performance issues in early builds allows more time to correct the design. By including critical performance-related features and elements earlier, we can take advantage of the incremental nature of the development process to avoid creating engineering in potential performance issues.
A tool architecture is simply a picture of all your development, testing, and deployment tools and how they fit together. Creating a "current state" diagram and then looking forward and creating a "future state" diagram helps you understand where tool integrations would be beneficial.
It is vital that everyone communicates properly if we are to build software applications that meet the needs of our organizations. However, creating clear and unambiguous requirements necessitates good definitions, which can sometimes be difficult. Conrad Fujimoto shares his starting technique.
Testable requirements, or acceptance criteria, are the communication of an expectation between its originator and potential stakeholders. Many testers struggle with this starting point. But once you succeed, you know the processes that can build and test a system implementing “good” requirements.