Reading Time: 2 minutes
In this post I am talking about important tester activity. That activity can be done where there is no single line of code, by just giving critical opinion on product requirements. On concrete example, I will do RIMGEA analysis to better sell described issue.
In order to get client data from current product, I used api of that product. api was sql query based which means that returned rows of data had a number of columns (attributes). Api was well documented.
While I was learning that api, I noticed something strange in documentation, one of returned columns (attribute) was named something like this:
By using query, I hit that design issue. For different ranges in api request, response had a DYNAMIC NUMBER of columns, that contained result data. So if response had two amounts, it contained COLUMNS Amount_1, Amount_2.
Why is this an issue? Because this is in direct conflict with relational database design:
Each database is a collection of tables; these are also called relations, hence the name “relational database”. Each table is a physical representation of an entity or object that is in a tabular format consisting of columns and rows. Columns are the fields of a record or the attributes of an entity. The rows contain the values or data instances; these are also called records or tuples [wikipedia].
From RIMGEA, we will describe Maximize and Externalize. When api call returns only two values, this is not the issue. But when api call request generates 1000 values, you will hit database security constraint, number of columns is exceeded for particular entity.
In order to Externalize it, we need to inform stakeholders that api will not be able to support number of values that are greater than database security setting. We also need to explain that user will often generate api calls that will return that number of values.
Tester of that product could spot that issue by reading the api documentation. And if documentation was not specific how values should be returned, this could be spotted in early stage of api method lifecycle.
If you are tester and spot some design issue, do not be afraid to speak up. Especially when you have RIMGEA as you backup.