Achieving Software Quality: Prioritizing Intended Behavior |

September 18th, 2023 by inflectra

By Critical Logic, an Inflectra Partner

Software development is more than just writing code. It is a complex process that involves numerous components, including design, testing, and implementation. And while each aspect of software development is critical, there is one factor that is often undervalued: Intended Behavior. Intended Behavior refers generally to the requirements, specifications, standards, and functional designs and other constraints that are necessary to define a software system and meet business requirements. In this blog post, I will explore the importance of Intended Behavior and how focusing on this component can help improve software quality every time.

At the most basic level there are three crucial components of software development: Intended Behavior, Development, and Verification (see figure 1). These three components form a triangle, and the quality of the delivered software is directly dependent on effective communication of the ‘Intended Behavior’. Therefore, it is essential to start by defining and communicating Intended Behavior in a clear, complete, and unambiguous manner.

Figure 1

One of the most compelling arguments for investing in Intended Behavior is that it can significantly reduce the cost and schedule of the overall life cycle.

When Intended Behavior is not clearly communicated or defined, developers will take what is given and produce code that works but cannot be the full and complete Intended Behavior. This leads to defects, technical debt and rework cycles. Study after study shows that the root cause of these problems is most often poor or incomplete requirements. To avoid the cost of these issues, it is important to take the time to thoroughly define and communicate Intended Behavior. It is clear that organizations know how to develop quality software giving quality instructions. We know how to code.

Harnessing Precise Intended Behavior for Optimal Software Quality

Investing in Intended Behavior not only reduces the cost associated with Delivered Behavior but also significantly elevates overall quality and reduces technical debt. When Intended Behavior is clearly defined and communicated, developers can produce high-quality code that directly meets the intended requirements. This, in turn, reduces the amount of technical debt, and the cost of maintaining the code over time.

Focusing on Intended Behavior can also maximize return on investment (ROI). When Intended Behavior is well defined and communicated, developers can produce high-quality code more quickly, and with fewer errors. This, in turn, leads to earlier delivery of software and allows for more frequent releases, which can lead to greater profits.

Effective Communication: The Crucial Element in Software Development

Clear communication is crucial when it comes to defining Intended Behavior. Product owners, developers, and SQA managers must work together to ensure that everyone is on the same page and that the requirements are clearly defined. By taking the time to communicate and define requirements early in the development process, teams can avoid costly mistakes down the line. This is consistent with the concept of shifting left.

There are approaches and technologies that can be used to define and communicate Intended Behavior. In the simplest terms there are two key ideas that I think bare consideration: visualization and consensus.

Let’s talk about a very simple example (see figure 2). Bob and Evan meet on a Monday and come to a consensus to meet again next Friday. Four days later Bob calls to meet and Evan is unavailable. A week later Evan calls and Bob is unavailable. Even though they agreed, “next Friday” meant different days to each of them. Let’s look at this plan in a different way, with a picture. Both Bob and Evan show up at the same time.

Figure 2

Here is another example showing a Cause-Effect Model created from a User Story about a choice on shipping method depending on your location within the U.S. (see figure 3). This Model can generate 3 clear Test Scenarios that cover all 11 possible paths through this model. The rules are also very clear for development.

Figure 3

Clarity of intent is almost always improved with a visual. One of the most effective ways to visualize business rules or software behavior is by creating models or diagrams. There are lots of types of models and even simple drawings on a whiteboard, that can be used to communicate more clearly. Some examples are flow charts, decision tables, activity diagrams, data flow diagrams, state charts and cause-effect models. These models can be useful for communicating different information and often it may be best to use several different models for clarity. We find that Cause-Effect models are especially good at diagramming user stories by creating logic flows and identifying unambiguous test scenarios and making variations obvious. Any or all the visualizations create clarity of Intended Behavior which leads to more easily achieved consensus among stakeholders. These steps ultimately lead to better development and delivery. This leads us to consider how to verify that deliverables match the Intended Behavior.

The quality of each delivered release can only be measured against the Intended Behavior. I describe this as ‘Should Do’ testing. This is opposed to the more common approach of what I call ‘Does Do’ testing. Let me explain the difference.

Understanding ‘Does Do’ vs. ‘Should Do’ in Software Development

‘Does Do’ testing or verification is running the delivered software to see if it breaks or has some inconsistent results or responses. Typically, this is from a user perspective. This means that the software behavior is assumed to be complete and correct if it does not break. This is typical of User Testing, Exploratory Testing, Data Driven Testing, and most automated testing including AI based testing (so far). Test designers either are not paying much attention to documented Intended Behavior which is often out of date, incomplete or is just missing all together. Basically, the system works correctly if it doesn’t create errors or crash. Tracing back to requirements or any kind of coverage analysis is problematic. Trust the developers and test what it ‘Does Do’.

‘Should Do’ testing should approach testing by looking mostly at documented Intended Behavior. This can and should be done independently and in advance of development and release. Test planning and test libraries should be created by the same Intended Behavior information provided to development. This process leads to direct traceability and coverage measurement to provide solid analysis of readiness to go live with the business’s intended system.

Unfortunately, throughout my 25+ years in the industry, ‘Does Do’ testing has been and is still the most common approach. This is especially true in Agile development where the software is the documentation. More on that in a minute.

It makes sense that ‘Should Do’ testing gives better results, but it is not possible without well communicated Intended Behavior with clear stake holder consensus. The time to choose ‘Should Do’ is at the beginning of a new system or new feature project.

Everything I am proposing can and should be applied to Agile development or any development for that matter. For Agile, the scope of Intended Behavior will focus on User Stories that come into sprints or iterations. It makes sense that visualization (modeling) and consensus from product owners and developers at the beginning has all the benefits described. Result - better code and better verifications and less backlog.

Conclusion: Leverage Visualization and Consensus for Effective 'Should Do' Testing

The quality of software development is directly dependent on the quality of Intended Behavior communication. By investing more time in defining and communicating Intended Behavior, teams can improve overall quality, reduce costs associated with Delivered Behavior, reduce technical debt and backlogs, and maximize return on investment. Our focus on Intended Behavior enables businesses to save time and money, while delivering high-quality software that meets their needs. Whether you're a product owner, C-level executive, or QA manager, consider prioritizing Intended Behavior for improved software development. Experience the difference it can make in your efforts.

ABOUT CRITICAL LOGIC

Critical Logic is all about improving the Quality of Business Systems. The heart of what we do is modeling. Modeling requires clear, unambiguous statements of intended, correct behavior. Modeling also produces highly effective acceptance criteria. The result is more successful system deployments and reduced testing, maintenance, and rework.

We deploy our Integrated Quality Management methods and technology (IQM Studio) to provide modeling, test generation and automated test execution in almost any business environment. Our experienced consulting staff provides high quality Business Analysis, Functional Design, Software QA planning & management, and training. We integrate the imperative of quality to all key parts of Business Systems SDLC.

Learn more about Critical Logic.

STAY UPDATED

Subscribe to our newsletter and never miss out on the latest Inflectra updates, product improvements, news, and thrilling announcements!