FUNCTIONAL Test Cases

We have already shown the template for writing test cases.

The main intention of a TE is to write test cases effectively and also efficiently.

Here, the actual result is written after execution of the test cases and most of the time it would be the same as the expected result. It will be different if only the test step is failed. So, actual result field can be skipped, and we can elaborate about the bug in comments field.

Also, the input field can be removed and these details can be added in description field.

Its not that the above mentioned template is a standard one, the template can vary in each company and also with each application depends on TE and Test Lead. But, for testing 1 application, all TEs should follow a standard template which is formulated.

Test cases should be written in such a way that even if a new TE should/can understand and execute the same.

When entering URL hostname, hostname is mentioned as development team throws the s/w to testing team after say 4months – so we are not sure of the hostname.

Username and password are not mentioned as they keep changing. The user might need to change it every 15days depending upon the application.

When writing functional test cases – we 1st check for which field we write test cases and then elaborate accordingly. If say, amount transfer is the field we are writing FT, then elaborate this is not login feature.

Input is required in FT, if the application is data driven, then i/p column is required else it is time consuming.

Lessons for writing Functional Test Cases

• Before we start writing test case, come up with options and select the best option and then only start writing test case
• In Expected result, use „should be‟ or „must be‟
• Elaborate only those steps on which we have  Do not elaborate on all the steps.
• Highlight object names
• Do not hard code the test  Write a generic test case
• Organize steps properly so that it reduces lot of execution 

INTEGRATION Test Cases

Something which is covered in FT case should not be written in IT case and something written in IT case should not be written in ST case.

Always start any test case with navigation steps to help new user understand it.

Strategy to write Integration test cases,

• Understand the product
• Identify the possible scenarios
• Prioritize
• Write the test cases according to priority

When TE is writing test cases, the factors he needs to consider are,

• If the test cases are in detail
• Coverage ,all test case values or scenarios are depicted
• Thinkin execution point of view
• Template used to write test cases must be unique

Best test case is when less number of steps are involved, coverage is more, when these test cases are thrown to anyone, they need to understand.

SYSTEM Test Cases

Let us write system test cases for the end-to-end business flow. 

Header of Test Case :

We always fill the body of the test case first before filling up the header of the test case.

• Testcase name :

CBO_AT_more than balance

Project name

Module name

Scenario to be tested

• Requirement number :
• 32.3 Amount Transfer
• Module name :

Amount Transfer

•  Pre-condition:

Test Engineer should know the balance of user A and user B

Pre-condition is a set of actions or settings that you should have done before executing step number 1.

For ex, If in an application, we are writing test cases for add users, edit users and delete users – the precondition would be – see if user A is added before editing it and deleting it.

• Test data :

The data we should have before executing step number 1. Ex – username, password, account number of users.

The test lead may be give the test data like username or password to test the application. Or the TE may himself generate the username and password.

Severity:

It can be major, minor or critical.

To analyze the severity of the test case, it depends on the header.

Choose the severity according to module. If in the module, there are many features. In that, even if 1 feature is critical, we claim that test case to be critical. It depends on the feature for which we are writing the test case.

In Gmail,

Compose mail -> Critical Sent items -> Minor

Feedback -> Major

In a banking application, Amount transfer -> Critical Feedback -> Minor

We write severity because we can prioritize our execution based on the severity of the feature.

• Testcase type :

It can be functional test cases or integration test cases or system test case or positive or negative or positive and negative test cases.

• Brief description :

Following test case ensures that Amount Transfer feature is not allowing more than balance.

Test engineer has written test case for a particular feature. If he comes and reads the test cases for a moment, he will not know for what feature has written it. So, this gives a brief description of for what feature test cases are written. Step number is important. If say, step number 10 is failing – we can document defect report and hence prioritize working and also decide if it’s a critical bug.