What business logic is, why it is important to understand it as a quality assurance analyst, and how it is integrated into the software development life cycle (SDLC) of the product?
In a world that is highly digitalized, applications have become a part of our everyday life, and behind every software product that is being developed stands business logic, an essential part in making the user have a positive experience with the digital products.
Business logic, also known as “domain logic”, is a set of custom rules that manage the communication between the end-user interface (UI) and the database of a software program.
As part of the business logic, we have the business rules and the workflows, more explicitly the more formal, high-level rules of the product and the sequence of events or steps forming a workflow.
And while there is a lot of business going on, please note that business logic should be differentiated from business rules.
Business logic is the process of online payment for the user’s shopping cart: the sequence of steps that the user needs to follow in order to complete that transaction, and also the implementation and integration with a payment system.
On the other hand, the business rule would be the fact that every user must be able to successfully pay for the items in the shopping cart.
Business logic and business rules are interdependent and one cannot function without the other. Business rules determine the framework, whereas business logic creates a system of processes and procedures starting from that framework.
Great quality assurance (QA) starts with understanding the business goals: what is the purpose of the application, who is the audience and what benefits will it bring to the users.
Once the goals are clear, the first step of testing is analyzing project documentation, including the project requirements and specifications. Business logic is defined by these artifacts, and making sure the project documentation is accurate from the beginning will save developers’ time and clients’ money.
In order for a QA to properly test an application, there must be a clear understanding of the app workflows, both technically and from a business perspective. When trying to avoid problems related to logic, it is recommended to check the business processes and design requirements at the beginning of the software development life cycle (SDLC), and all the implementations that follow shouldn’t derail from the main path.
This way, we make sure we won’t have to make changes later in the cycle that would be more expensive and time-consuming.
If a QA analyst or expert doesn’t fully understand the business logic, they won’t be able to create test cases that cover the edge case scenarios and guarantee that the user won’t have a bad experience while using the app. As a QA one has to put themself in the user’s shoes and knows what to expect from the application, the chances of releasing issues to production drop drastically.
In addition, another good reason why business logic is important is that the QA can suggest improvements regarding the app workflows. When you test the app as a real user and go beyond that, with edge cases, API testing, and even automation testing, you can look further into the way a certain part of the app might be affected by a new feature, and raise a flag or suggest other options.
Being able to see all the connections in the app helps look into details as well as see the bigger picture in regards to the testing scenarios.
Let’s discuss a specific example in the app development industry
A fintech app involves a great amount of money and any implementation error could lead to loss, security breach, or user frustration — so it is a great responsibility for the QA analyst to cover in testing as many cases as possible, both specifications that are defined in the business rules, and edge-case scenarios.
But this would not be achievable if the QA does not understand the business logic:
It all needs to make sense for great quality assurance.
If we were to expand on the example in our business logic definition section, given the business rule that every user must be able to successfully pay online for the items in the shopping cart, a possible business logic would be:
For the above app workflow, a QA would not only rely on the successful payment confirmation but also verify that the transaction was made in the payment system.
In conclusion, one of the things that make a QA great at his job is the ability to understand and work with the business logic of an application. App design is key, and so are the app workflows — the fact that users enjoy using the product and have a positive experience.
In the end, the ultimate goal is to create a great product for your audience, so they can make the most out of it.