What is Difference Between Test Plan, Test Strategy, Test Case, Test Script, Test Scenario and Test Condition?

How to Write Complex Business Logic Test Scenarios Using Decision Table Technique

There are many test case design techniques. In this article, we will learn how to use Decision Table technique effectively to write test cases for an application with complex business logic.

Decision table testing is an easy and confident approach to identify test scenarios for complex business logic.

Here is an illustration with example:

We all know that business rules and validations take up major portion of the requirements given by the customers. While observing how these requirements are represented and communicated to the entire project team by Business Analyst’s or customers, we come to know that most of such business rules and logic are presented in a logical process flow diagram.

A logical process flow diagram for a complex requirement comprises of many branches, nodes and decision boxes. Hopefully we testers are expected to cover all those branches and touch every nook and corner of such a complex logical tree. I have also faced such complex business flows and tried many test case/test scenario preparation techniques for making the process easier.

Finally, I found decision table testing technique to be highly useful in this aspect. Here is how decision table technique can make the test scenario preparation for complex business logic easier.

E.g. writing test cases for a login screen using the Decision Table technique:

Let’s take a Decision Table example of below business requirement for a login screen.

Fig: 1.0 Sample business flow diagram

The first step we do is to name all the branches and leaves with numbers or alphabets as below.

1, 2, 3 are the leaves and a, b, c are the branches.

Then, we have to create a decision table as below: (Click to enlarge image)

Fig 1.1 Decision table for business flow fig 1.0

Points to remember:

• All the validations specified in the decision boxes should be made as columns in table.
• All the results (leaves) mentioned in flow diagram should be covered in the decision table.
• All combinations of inputs needed to obtain a certain result shall be mentioned in the combinations column and can be included while writing the test cases.
• After completing the decision table one has to just verify whether all the branches and leaves in the logical tree are covered.

Advantages of Using Decision Table Technique:

#1) Any complex business flow represented as a diagram can be easily covered in this technique.
#2) It provides quick confidence on the test cases. One need not have to review his own test cases multiple times to gain confidence.
#3) Easy to understand. Anyone can make test cases from this decision table template.
#4) Rework on the test cases and test scenario can be totally avoided as it gives complete coverage at the first shot.

Limitations:
#1) Certain test case preparation techniques like Boundary value analysis, equivalence partitioning cannot be directly accommodated in this template. But, one can note it down in the combinations column and use them while writing test cases.

Before explaining why other test case writing techniques cannot assure as much accuracy as Decision tables, I would like to quickly remind other black box and white box test case writing techniques.

Other Test Case Design Techniques:

1) Boundary value analysis: is software testing technique in which test cases are designed to include representatives of boundary values in and out of a given range.

2) Equivalence partitioning: also, called Equivalence Class Partitioning is a software testing technique that divides the given condition into partitions and one input data from each partition can be chosen for testing.

3) State transition testing: is a black box testing technique, which can be used to design test cases for a system that acquires finite number of states and can transit from one state to another upon specific events.

4) Error Guessing: is a technique where experience of a tester is used to find the errors or part of application with highest possibility of finding errors. This is skill-based technique without any rules.

5) Use case testing: In this technique, use cases/scenarios are used to write the test cases. Interaction of users and system is described in a use case.

Some more test design techniques:
6) Statement coverage
7) Condition Coverage
8) Exploratory testing

Why other test case design techniques for business logic cannot prove to be useful as Decision Tables?

1) Boundary value analysis and Equivalence class partitioning are meant for numeric ranges and length. Both of these techniques alone cannot ensure 100% test coverage for business rules.

2) Error guessing is more about experience. Though experience is required, it cannot prove to be everything.

3) With state transition testing technique, one can ensure that all parts of the logical tree are covered but it does not suggest document or artifact as decision table technique ensures coverage with a decision table (fig 1.1).

Conclusion:  For writing test cases for business logic, it is advisable to follow below steps to prepare test cases so as to ensure maximum test coverage:

Step #1) Use decision table test case design technique to attain 100% logical coverage.
Step #2) Boundary value analysis and Equivalence partitioning for covering various ranges of inputs.
Step #3) Combinations and permutations for field level validations (though not all permutations are required).
Step #4) Error guessing (apart from the errors that can be identified from the above three steps) with experience as a final touch

With the right combination of all these techniques, I hope you will be able to discover almost all test scenarios for any application under test.

About the author: Hari Narayan is a software testing professional with more than 3 years of work experience on writing test scenarios for complex business logic. He is currently working with Plintron Global Technologies.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Writing Test Cases from SRS Document (Download Live Project Sample Test Cases) – Software Testing QA Training Day 4

Just to rehash what we have been doing so far – we are working our way through the Software Testing Training mini-course on a live project OrangeHRM.

In this free online QA training series so far, we are done with:

1. SRS review,
2. Test scenario/Test scope identification and
3. Documented the Test plan.

Now, we have reached the part that is the real-deal, the test cases.

As indicated in the article before this: Test cases are documented by the QA team while the Code phase of the SDLC is going on. In other words, while the Dev team builds the software system, the testing team gets ready with the test cases that would help us test the system once it is ready, i.e. at the end of the code phase.

So, in today’s article, we will work on understanding what test cases are, how to create them and write few sample test cases for our live project.

Let us get to it right away.

Basics of Writing Test Cases:

#1. If test scenarios were all about, “What we are going to test” on the AUT – the test cases are all about “How we are going to test a requirement”.

For example, if the test scenario is “Validate the Admin login functionality” – This would yield in 3 test cases (or conditions) – Login (successful), Login-unsuccessful when incorrect username is entered, Login-unsuccessful when incorrect password is entered. Each test case would in turn have steps to address how we can check a particular test condition is satisfied or not.

#2. The input to create a test case document is FRD, Test scenarios created in the earlier step and any other reference documents if present.

#3. The test cases documentation is an important deliverable by the QA team and is shared to BA, PM and other teams, when done for their feedback.

#4. Work is divided among the team members and each member is going to be responsible for creating test cases for a certain module or a part of a certain module.

#5. Just like with the test scenarios, before we begin Test case documentation, a common template has to be agreed upon. Practically anything can be used to create test cases. The 2 most often used choices are MS Excel and MS word.

#6. The MS word template looks something like this:



#7. The Excel template could look like the following:



#8. From the above two templates it can be observed that the fields (or the components) that make up for a test case are the same, the only difference is the way in which they are organized.

So, as long as there is a field for each of the type of information to be included in a test, the format of the template does not matter. However, my personal favorite happens to be the excel sheet, because it is easy to expand, collapse, sort, etc. But again, choose any format that works best for you.

Fields in Test Cases:

Let us take a moment, to observe the fields that are part of a test case.

Test case Id and Test case description – these are the generic ones.

The other fields can be explained as follows:

a) Precondition - state of the AUT (the state in which the AUT needs to be for us to get started)
b) Input - data entry steps. For these steps it is important to note what kind of input info is required – Test data
c) Validation point/trigger/action – what is causing the validation to happen? (Click of a button or toggle or the link access. Make sure there is at least one validation point to a test case- otherwise it is all going to be data entry with nothing to look for. Also to ensure that we have enough modularity, try not to combine too many validation points into one test case. 1 per test case is optimum.)
d) Output - expected result
e) Post condition - This is additional information that is provided for the benefit of the tester, just to make the test case more insightful and informative. This includes an explanation about what happens or what can be expected of the AUT once all the test case steps are done.

See Also => Sample test case template.

Live Project Sample Test Cases:

Now that we have enough background information to get started on the test case creation process, let us get going and create few test cases for our Live Project.

Based on the process mentioned above we have created some sample test cases for the OrangeHRM account module. These should give you exact test case format and idea on how to approach for writing test cases.

Note – there are few images referred in sample test cases xls document. If you are viewing this on older MS Office version, you may face compatibility issues. So we have listed those images below as per their names in the xls files:
– View Pic 1
– View Pic 2
– View Pic 3

There, all done and all good.

Test Cases Writing/Optimization Methods

Now, imagine a situation where a certain page has a few 10’s of fields on it or has a complex business logic that is implemented in there. To make sure that we optimize the test case creation process in situations like that, we testers have certain Test case optimization methods.

Below is a list and please check out the links provided for more information on these methods.

• Boundary value analysis
• Equivalence partitioning
• Error guessing - This is a very simple method and relies on a tester’s intuition. An example is: Say there is a date field on a page. The requirements are going to specify that a valid date is to be accepted by this field. Now, a tester can try “Feb 30” as a date- because as far as the numbers are concerned, it is a valid input, but February is a month that never has 30 days in it- so an invalid input.
• State transition diagrams
• Decision tables

Using the above techniques and following the general test case creation process, we create a set of test cases that would effective test the application on hand.

A few important points to note:

• The test cases we create are not only the point of reference for the QA phase but also to the UAT.
• Internally test cases are peer reviewed within the team.
• When a certain situation is not addressed by a test case – the rule of thumb is, it is not going to get tested. So, this is a good place to check whether the test suite we created achieves the 100% test coverage goal or not. To do so, a traceability matrix can be created. Check out all there is to know about traceability matrix here.
• Tools – Test management tools like QC, qTest help us with the test case creation activity. For an example on how test cases can be dealt with using Quality Center, check out this Quality Center tutorial.
• Automation tools can be used to create test cases- in which case, they are referred to as, Test scripts.

Tip: Please perform a spell and grammar check on each and every document we create. We are the quality representatives for IT projects – and it doesn’t reflect positively on us if our deliverables themselves are of inferior quality.

That brings us to the finish of another interesting segment.

Conclusion:

The end of test creation process/test design phase (STLC) and the end of the Code phase (SDLC) will generally mark the end of test preparation phase and the beginning of the Test execution phase.

Next tutorial in this Software Testing Course – In the coming article, we will talk about what test execution is, what it includes and what are the expectations from the QA team during this phase.

=> QA Training Day 5: Test Execution

We hope all of you are working along with this series. For the sake of simplicity, only a few test cases have been created. However, best results can be seen when you work on testing extensively, which means writing more and more test cases. So, please don’t limit your work and do as much as you can.