It is possible to find a new, innovative use for a tool, but it’s much more likely that you’ll do better using the tool in the way its creators intended. And whenever you reach for a tool, check that it’s actually going to help solve the challenge you’re facing. This article explains why first and foremost, conversation is more important than a shiny new tool.
With all of the choices available to software developers, it's easy to become overwhelmed not only by a problem but also by its many possible solutions. One approach that can help you and your team stay on track is to divide and conquer.
Is testing about checking against system requirements, or is it about exploring the software? In this article, Elisabeth Hendrickson explains a valuable truth often clouded by this debate—good testing takes advantage of both of these approaches.
In recent years within the object oriented and agile community, several approaches to software design and development have materialized and are in use by professional software developers. Test-Driven Development (TDD), Domain-Driven Design (DDD), Behavior-Driven Design (BDD) and Feature-Driven Design (FDD) are some of the more well known approaches. While these philosophies all imbibe the classic agile principles of an incremental and iterative mindset to software development, they subtly differ from each other.
Defining, understanding, and agreeing on the scope of work to be done is often an area of discomfort for product managers, business analysts, developers, and quality assurance experts alike. The origin of many items living in our defect tracking systems can be traced to the difficulties encountered while performing these initial requirements activities. Ken Pugh introduces behavior-driven development (BDD), also known as acceptance test-driven development (ATDD), and explains how it works in creating detailed requirements. He outlines the different roles that team members play in the process. BDD/ATDD has proven to dramatically increase productivity and reduce delays in development by decreasing re-work due to requirement misunderstandings.