Blogs

...a verb, a subject noun and an object noun!

7/3/2016

A verb is a word in a sentence that expresses an action, an occurrence, or a state of being.

A noun is a word that is the name of something and is typically used in a sentence as subject or object of a verb.

A subject noun is a noun that performs the action of the verb in the sentence.

An object noun is a noun that receives the action of the verb.

A few years back I learned this technique from a great Business Analyst I worked very closely with. It was very early in my career as a tester at that time. She taught me that whenever we gather, analyze, interpret or elaborate business requirements of a software applications, we should always start with these three words (or phrases): a verb, a subject noun and an object noun, to identify all the business functions that the application is supposed to perform. Once we have the list of all the functions documented in this form, we should then elaborate on the individual functions to come up with the details of the requirements and/or test cases.

Since then, I has been tremendously helpful for me in writing good quality test cases!

Let's take the example of the deposit function in an ATM machine.

Here, the verb is 'deposit'.

Now, who deposits and what is deposited?

Clearly, an account holder deposits.

But which account holders? Checking Account? Credit Cards? Mortgage? Domestic? International?

Here comes the need for elaboration. We should document very explicitly what types of account holders can use this function.

Similarly, what is being deposited? The answer is simple. Money.

But, in which form? Cash? Check? This again needs elaboration.

This process can be extended to identify all business functions of the ATM machine.

Note that, this technique is not specific to any methodology and can be used in Agile, Waterfall, Iterative or anything similar.

Here are a few examples:

Account holder withdraws money
Account holder views balance
Guest opens account
Administrator prints report, etc.

Over the years, this technique has been of great help to me as a tester to identify all positive and negative test conditions.

Should there be quality assurance for functional requirements?

5/27/2016

Based on a recent survey, 68% of software development projects are considered 'failed' by the respective project sponsors. Moreover, as per the root cause analysis, 53% of these failures are attributed to poor functional requirements.

In the context of quality, the difference between quality assurance and quality control is that one is defect prevention and the other is defect remediation. However, no structured process is followed in the current industry to assure the quality of functional requirements before it is used by the developers.

Some organizations follow strong approval processes for the functional requirement document. Some others perform ambiguity review of the requirements as well. But, how objective, complete and thus reliable these processes are, is the question.

Testing Algorithms, LLC. have come up with a research based approach to perform quality assurance of the functional requirements first. This process uses various business modelling concepts to identify requirement gaps during the requirement gathering phase itself. Moreover, once the requirements are captured, they are processed through a proprietary algorithm to automatically convert to test cases with expected results and 100% requirement traceability. These test cases can be integrated with standard test management and test automation tools.

Is Requirement Traceability Matrix overrated?

3/17/2016

A few years back I was involved in managing testing activities for a bank's ATM application. The application was being developed using latest technologies to replace their old system. A couple of Business Analysts spent hundreds of hours understanding and documenting business requirements and then they passed that knowledge on to the development team (for application design) and testing team (for test design).

One of the requirements, I remember, was that the maximum cash amount that could be withdrawn in a single transaction was $2000. Therefore, our intelligent testers applied the theory of boundary value conditions in this case and created 3 test cases for withdrawal involving the following amounts: $1999, $2000 and $2001. They also created the Requirement Traceability Matrix and linked this particular requirement with those 3 test cases.

Very reasonable, right?

After it was deployed in production, it was found that this functionality was not working for some Premium Debit Cards. A critical defect had been logged and a Root Cause Analysis initiated. It was suspected that this particular functionality has never been tested. However, when the Requirement Traceability Matrix was checked to confirm the hypothesis, it indicated otherwise.

What was the problem then?

Well, the problem was that the Requirement Traceability Matrix was incorrect, and thus, misleading. In this example, even if the 3 test cases pretended to cover the requirement, it actually didn't, as it didn't take into consideration all possible permutations and combinations of various attributes of the card. This requirement should have been tested with multiple types of Credit and Debit cards. But in reality, unfortunately, it was tested with only one type of card.
Testing Algorithms recommends that test coverage should be measured against all possible permutations and combinations of the various parameters involved in the process, not just against some requirement ids.