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.
What do you consider the role of product owner in an agile development project to be? Bob presents a compelling perspective that a product owner has four distinct critical roles that can prove impactful to a team's success.
An organization shouldn’t spend all its time building its delivery muscle without simultaneously building its discovery muscle. In fact, successful software teams deliver great products because they invest in discovery. Learn how to expand your innovation and strengthen your discovery muscle.
Testers and developers can be friends. In fact, on teams working at a breakneck pace to deliver software, they must be friendly enough to rely on each other. However, there are a few sure-fire ways to ruin that relationship before it begins—and potentially make testing both irrelevant and unwelcome. Marlena Compton lists seven such ways here, along with suggestions for avoiding disaster.
Charles Goodhart stated: "Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes." In other words, "When a measure becomes a target, it ceases to be a good measure."
Analysts determine what needs to be created. Programmers create it. Testers find the holes in the work of both. That's one way to do it, but all three can collaborate to do these things better, and more easily, too.
We all want to satisfy our users, but tailoring software to customers is easier said than done. Personas—a method to synthesize your primary users into abstract entities—facilitates understanding of goals and experiences.
A cast-in-concrete delivery date looms on your project’s horizon. You have precious little time remaining, and the development team keeps delivering incomplete builds of unstable code. Is this a "death march" project, or can the testing team actually do something useful, or perhaps even save the day?
How many times have you heard the phrase "works as designed" used to describe software that is flawed and in some cases not fit for use? While "works as designed" has become an acceptable response for some, for real professionals, it's not.
Exploratory testing projects can have documentation requirements, just like any other project. Jonathan describes various ways we can create documentation on our exploratory testing projects, including guidance documents, test-coverage reports, and video software to help create lightweight, powerful documentation.