Manifesto of a Requirement Framework - Part 3

Continued from Manifesto of a Requirement Framework - Part 2:

Requirement traceability matrix has worked for a very long time as a standard for ensuring full test coverage. But I could sense that this was falling apart as well. In my life, I have never seen a project going into production without a one hundred percent test coverage as per the requirement traceability matrix. But still, almost all projects end up having production defects. This was a clear sign to me that the requirement traceability matrix, in its current form, does not work anymore. I remember an example that I encountered a few years back. It was a banking application and it was supposed to support seven types of credit and debit cards. There was a requirement that when a card number is entered, it should validate that the number has sixteen digits and will throw an error message if it is more than or less than sixteen digits. However, this requirement was tested with just one type of card by someone who joined the team a few days back and was unaware of the other six types of cards. However, the requirement traceability was one hundred percent because this requirement was tested, although not with all possible combinations of various other parameters.

To me, it made more sense to me to have a requirement traceability matrix that captures whether all permutations and combinations of various parameters of the business function are covered by the set of test cases.

There was one more thing I was thinking about for a long time. I was being involved in the test estimation process since the first day of my quality assurance career. The organization standard for test estimation was to follow something called work breakdown structure. In that process, we had to take a top-down approach to guess the number of test cases for each business function and multiply them by a productivity index to estimate how many person-hours would be required to create (and subsequently execute) test cases for one or more functions. And, in this calculation, the standard productivity index that was considered for creating test cases was between one and three test cases per person-hour, depending on the domain, technology and complexity of the application.

The huge effort to convert requirements to test cases was again something that I thought could be drastically improved somehow. But I did not know how.

To be continued...