Is crashing the database a bug? Go beyond user stories to ensure Fitness for Purpose
One of our recent customers was building a custom software application with a single sprint team consisting of multiple in-house developers and one Lighthouse tester. At the end of an early sprint, our tester found a total of seven bugs: three of which the developers agreed with, and four of which they did not. The developers argued that these four bugs were not specified clearly enough in the user stories and shouldn’t be considered actual bugs.
The three bugs they agreed with were about conformance to specification (i.e., did the app work as specified in the requirements). Whereas the four bugs they didn’t agree with were about fitness for purpose (i.e., did the app work as it was intended). When developers focus solely on satisfying the user stories, rather than also considering the big picture (intended functionality), they develop both tunnel vision and poor-quality software. Thankfully, our tester knew this and prevented unnecessary, critical bugs from slipping through the cracks.
One example — When the Lighthouse tester entered certain values in a data entry field, it crashed the database. Let me say that again. It freakin’ crashed the database, and the developer argued that it wasn’t a bug. Although the user story did not specify that it shouldn’t crash the database, this should have been a given. (Side note – Good error handling and, ummm, not crashing the database should always be inferred requirements!) One can infer that there are certain fitness for purpose assumptions that developers can and should always make; however, in this case, our customer’s development team was clearly not making them.
Another great example of this is when the application requires a list to be displayed on the UI. Often, the user story doesn’t specify that the list needs to be sorted, but everybody knows that it needs to be. Depending on the list, it could be sorted alphabetically, chronologically, etc. but should never be generated and displayed unsorted. This is a fitness for purpose requirement that is always implied and doesn’t typically need specified in user stories unless the sorting algorithm is complicated.
When developers define success as “all requirements were met”, they make the fatal mistake of assuming that their list of requirements is complete. Nobody is perfect and we surely don’t expect that. Good developers know to ask probing questions to clarify the intent underlying complex requirements. Great development teams have productive and transparent retrospectives at the end of each sprint, where they discuss and celebrate what went well, and they have open dialog and share with each other where they can improve. In our humble opinion, this is one of the largest benefits of Agile development – the opportunity to learn and share this learning every two weeks!
It is crucial that development teams ask clarifying questions in order to build robust systems that meet general fitness for purpose expectations. Most importantly, it’s crucial that the teams develop a trusted culture where they are encouraged to fail quickly, learn, share these learnings, and improve. By making these improvements, not only will your team be more engaged, but they will prevent unnecessary rework, improve quality, and shorten time-to-market.
If your software development team falls short in meeting your fitness for purpose requirements, whether they are clearly specified or not, please share this blog with them and contact us to learn how we help teams deliver faster, improve quality, and build better culture.
Sarah Roberts is the Marketing Specialist at Lighthouse Technologies where she leads marketing strategies and conducts market research within the tech industry. A 2021 graduate of Miami University, Sarah brings a fresh, innovative perspective to industry trends and best practices. Her engaging and relatable blogs simplify complex topics, making them accessible and enjoyable for readers of all backgrounds.
Great points, and businesses would be smart to understand that this applies to far more than software testing and development. Nearly all services, be it consulting or food services, need to be delivered in the context in which they are expected, if possible, not the context they are intended. A Client failing to disclose that they wire funds when implementing ERP, or a line cook forgetting to ring the bell when an order is up, doesn’t mean that the consultant shouldn’t be aware, or the wait staff should serve food cold. Context of the end experience, not what is written on a piece of paper, should be the end goal of all successful companies.
One of my favorite books, “The Art of Software Testing,” by Glenford J. Myers (the third edition in hardcover is only $181 on Amazon!) points out that for any reasonably large and complex software system, there are an INFINITE number of things that a program shouldn’t do. Therefore, no one can specify all of the things that a system shouldn’t do. Great testers look for these things, and sometimes just find them through regular testing. All of the things that a program shouldn’t do probably fall under the heading of fitness for purpose. One reason for Agile development is so that we don’t waste our time telling people that you can’t crash the database! Just because we don’t write infinitely large requirements to specify all of the things that a program shouldn’t do, doesn’t mean that it’s okay to do them. Really, don’t crash the database.