Blogs

Still writing Given-When-Then statements manually?

12/2/2016

Over the last few years, many organizations have realized that software development is not a production process; rather it is more of a Research and Development process, as Agile Manifesto indicated in 2001. Since then, many approaches and techniques were crafted that have been successfully used and still being used in these organizations.

Business Driven Development (BDD) is one of them, and probably the most popular today. It uses a Given-When-Then (i.e., Gherkin) statement that serves multiple purposes:

1. Elaborates the product feature with details and examples,
2. Aligns the Definition of Done (DOD) with business users,
3. Specifies the acceptance criteria of a user story, and
4. Accelerates Test Driven Development (TDD) using test automation.

However, the current practice in the industry is to write the Given-When-Then statements manually, as a team.

But what if we go up one more level of abstraction? In other words, can we capture the feature, or the behavior, of the software under development using a much simpler model and generate not only the Given-When-Then statements, but also the optimized manual test cases in Quality Center format, various types of requirement traceability matrices, test case priority matrix, traditional use cases and process flow diagrams?

We, at Testing Algorithms, came up with a solution for that based on our years of research. It is a methodology that helps in structured thinking and representation of the application behavior so that the optimization and visualization can be taken up by a mathematical algorithm. Based on our case studies, this model is able to create all artifacts, including better quality test cases, ten times faster.

Agile is about innovation. And we believe in helping each other to grow as a community. So we have decided to let everyone use our research-based approach for free. Our website is https://www.testingalgorithms.com.

If you want to try our requirement analysis and test case design solution, please register using https://www.testingalgorithms.com/registration.html.

For any questions, contact us at https://www.testingalgorithms.com/contact-us.html.

...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.

Can quality of Quality Assurance be assured?

3/26/2016

In a typical software development project, Quality Assurance (QA) process ensures that the quality of the code, written by developers, is compliant with the requirements defined by business users. The IT QA team, as part of their test design, makes sure that all requirements are covered by the test cases, and thus all possible defects can be identified and fixed before the application is exposed to the business users for User Acceptance Testing (UAT).

But who measures the quality of Quality Assurance? And, how?

Let me share what I experienced so far in my career. At the end of a project, QA is considered to be well-performed if no (or may be a very few cosmetic) defects are percolated to the upper environments (like UAT and/or production). But this is a very rare event. In real-life projects, with almost certainty, some moderately critical (if not very critical) defects are always uncovered by the User Acceptance testers (in UAT environment) or business users (in production environment). And, when they are uncovered, the IT QA team had already missed the bus!

But, wouldn't it be helpful if the quality of test cases could be measured before even executing them in lower environments? This way the IT QA team would have had a chance to make corrections and adjustments to their test cases, instead of waiting for the UAT team to discover their mistakes!

Some organizations thought about this problem and came up with an solution where IT QA team reviews the test cases with Business Analysts to make sure all test conditions are covered. But the big problem with this approach is, still the quality of test cases is not measurable. And, because it is not measurable, it is not optimized. So, the set of test cases often grow exponentially in order to ensure that all possible combination of requirements are covered.

Testing Algorithms proposes a solution by which the quality of test cases can be measured and optimized, even before the test execution begins. This solution ensures the coverage of maximum requirement combinations by minimum number of test cases. And, that too, with at least 90% less test design effort.