specifications

In general, developers test features by focusing on the positive outcomes — the so-called “happy paths”. Unfortunately, this optimism can blind us to the less obvious or less probable outcomes that can cripple an application. I found one way to counteract this tendency is to try and “go beyond the happy path” by exploring the outcome of unhappy paths through a feature. I came across this idea in the excellent book Fifty Quick Ideas to Improve Your Tests by Gojko Adzic, David Evans, and Tom Roden, and expanded upon the book Writing Great Specifications by Kamil Nicieja....

In most organizations, software development is split between two groups — product management and engineering. Product management is focused on building the right system. This requires product managers to meet with users, try and understand their needs, and develop solutions that meet those needs. To actually develop the solution, product managers must involve engineers who are focused on building the system right — writing the code, making it stable, and supporting it in production....

We all know that a page that loads in three seconds will provide a negative user experience. But does having every page load in less than one second make a meaningful difference? How can you tell? When is enough … enough? Non-functional requirements such as performance are often not precise enough to be specified as discrete numbers. Rather, they work on a sliding scale of acceptability. Would slightly better performance be significantly more valuable from a market perspective?...