Exploring Decision Tables for Software Testing

For this week’s blog post, I decided to choose a subject that would give me a little more experience with a technique for black box testing, or developing tests for software without direct access for the code for a particular application. This way, the tests are created with a bigger focus on the business logic instead of particular barriers that may arise within a programming language or the overall stack of the application. I found an article on softwaretestingclass.com that covers the usefulness of decision tables in regards to software testing. The article discusses how to use decision tables as well as why they are such an important tool for black box testing. The article also mentions other examples of testing techniques for black box testing.

The author, Venktesh Somapalli, provides an example of a financial application where there are two possible conditions for a user, repayment within a term, or moving on to the next term of a loan. Somapalli goes through the steps that a tester may consider constructing a decision table for this particular application. The table for the decision table technique is based on conditions either being true or false, so all outcomes are absolute. This means that there are there should only be one outcome for a set of conditions. However, the reverse of this is not true, there are can be more than one set of conditions that have a particular outcome. In the example in the article, if both of the conditions are true or false, an error message is the outcome. On the other hand, there is only one set of conditions that processes money, and one that processes the loan term.

My favorite part of this testing technique is that it is inherently non technical due to the nature of black box testing and the simplicity of the concept. This means that non technical people within a business can understand and even develop test cases using this technique. As Somapalli points out, this technique is also versatile because it can be applied to any set of business logic. Somapalli also notes that decision tables are iterative meaning that if any new conditions are added to the logic, the existing table can be reused and revised to consider the new logic without a complete reconstruction. I definitely agree with his arguments for the usefulness for this technique. I have used this technique in the past and before reading this article, I didn’t even consider the powerful nature of this versatile strategy. I will definitely continue to make use of this technique when developing test cases whenever possible throughout my career.

Link to the original article: https://www.softwaretestingclass.com/what-is-decision-table-in-software-testing-with-example/

Advertisements

DRY/WET

What is DRY code? I’ve heard the term before in some tutorials but never knew the meaning behind the phrase. I figured if I keep seeing it, it must be important. After searching around the web for a bit, I finally found a great article on what DRY/WET code is on softwareyoga. The article explains what DRY/WET means, the advantages of DRY code, and the precautions to take when considering this principle. DRY code means “Don’t Repeat Yourself” and WET means “Write Every Time”. Obviously, DRY is the one everyone should wish to achieve for most cases. The advantages that the article goes through are maintainability, readability, reuse, cost, and testing.

DRY helps make code more readable because logic is not repeated throughout multiple classes. Instead methods/functions are called and what is likely hundreds of lines of code is represented by a few function calls. Readers of the code base can find the logic, read it once, and understand how it functions. Then when they see it implemented, they do not need to double check that the logic is the same. If code is WET, the logic will be re-written entirely, forcing readers to ensure nothing is different in each implementation.

Reuse and Cost go well together as reuse lowers the cost of development. When reuse is the goal/option, cost is inherently lowered. These go along with maintainability as reuse means that the code is properly maintained. If code can be reused, this means that small changes to the logic are less likely to cause problems. There would also be less time spent refactoring code in the future if previous implementations are written with DRY in mind. This means that less time, and developers are needed to maintain a long-lasting codebase.

Testing is simple, if the source code is written DRY, writing the tests DRY only makes sense. This also makes tests easier to write, and easier to change in the future.

The cautions for DRY expressed in the article are rather self-explanatory. One of the pre-cautions is to not over-DRY your code. Basically, this means to only use DRY when it makes sense to use DRY. If the code doesn’t need to take advantages of what DRY offers, it likely doesn’t need to be written with DRY in mind.

DRY is a great principle to follow when writing code. It teaches good practice and can be applied to most of the design patterns that we are learning. Most of the design patterns build upon each other and do so to keep code DRY. Implementations are written without rewriting logic and instead only require simple method calls. I hope to keep my code DRY in the future. If I do so, I will find it much easier in the long run to both add to, and learn from my previous projects.

Here is the link to the original article: https://www.softwareyoga.com/is-your-code-dry-or-wet/