A test case, in software engineering, is a set of conditions under which a tester will determine whether an application, software system or one of its features is working as it was originally established for it to do.

What Fields Need to be Included in a Test Case?

• Test Case ID: Unique Test Case Identification Number.
• Purpose: A short sentence about what is being tested.
• Prerequisite: Conditions that must be met before the test case can be run. For example, the user must be logged in.
• Test Data: List of variables and possible values used in the test case. Examples: loginID = {Valid loginID, invalid loginID, valid email, invalid email, empty} password = {valid, invalid, empty}
• Test Steps: Detailed steps for test case execution.
• Expected Results: How the application should perform after executing the above testing steps.
• Actual Results: How application actually behaved after executing the above testing steps.
• Result: Does the test “Pass” or “Fail”.
• Comments: This is where the tester can add additional helpful information like screenshots and descriptions to provide the developers with the information they will need to correct any defects found.

Sample Test Case 1:

 

 

 

 

 

 

 

 

Sample Test Case 2:

Title: Login Page – Authenticate Successfully on gmail.com
Description: A registered user should be able to successfully login at gmail.com.
Precondition: The user must already be registered with an email address and password.
Assumption: A supported browser is being used.
Test Steps:
a) Navigate to gmail.com
b) In the ’email’ field, enter the email of the registered user.
c) Click the ‘Next’ button.
d) Enter the password of the registered user
e) Click ‘Sign in’
Expected Result: A page displaying the gmail user’s inbox should load, showing any new message at the top of the page.

A good Test Case characteristics:

• Should be accurate and tests what it is intended to test.
• No unnecessary steps should be included in it.
• It should be reusable.
• It should be traceable to requirements.
• It should be compliant to regulations.
• It should be independent i.e. You should be able to execute it in any order without any dependency on other test cases.
• It should be simple and clear; any tester should be able to understand it by reading once.

Writing test cases is a task that requires both talent and experience. The purpose of writing test cases is to define the “how” and “what”. Well written test cases are highly valuable, improve the productivity of the entire team and aid the company to create and deliver high quality software. Effective Test cases help in finding the difficult bugs and make test coverage maximum. It is a skill that comes with experience and respective domain knowledge.

Guidelines to write effective Test Cases

1.Study Application end-to-end

• Know the application end-to-end and study all its related docs to gather information.
• Prepare notes, flow charts, think for all the possible scenarios.
• Try to understand the product from customer point of view and determine all possible user actions

2. Domain Knowledge

While writing test cases for any application or software we need to have a proper domain knowledge about the product so that we can study the pros and cons and cover its each area and take out all the scenarios that could be possible.

• How will we test applications without knowledge of specific domain? Are we going to test the BFSI applications (Banking, Financial Services and Insurance) just for UI or functionality or security or load or stress?
• We should know what are the user requirements in banking, working procedures, commerce background, exposure to brokerage etc
• We should test application accordingly then only we can say that your testing is enough.

 3. Test Case Naming Conventions

• Name the Test Cases to represent the module name or functional area to be verified.
• Try to make them make as much sense they can just by looking at the test case ID or test case name.

Example:
There is a project called “Online” which has a functional area named “Login”
a) TC_01_Online_Login_Success
b) TC_01_Online_Valid_Case The

4. Cover all Verification Points in Test Design Steps

• Properly define test case verification steps to cover all the verification points for feature under test
• Prepare RTM to have maximum requirement coverage and minimized risk at later on project stage

Example:
By comparing Test Case steps with the artifacts (Requirement documents, Use Cases, User Stories or Process Maps) given in the project, we can make sure that the Test Case optimally covers all the verification points.

5. Divide Special Functional Test Cases into Sets

• Break down Test Cases into sets and sub-sets to test some special scenarios like browser specific behaviors, cookie verification, usability testing, Web Service testing and checking error conditions etc.
• If while writing the scenarios into sets, a particular feature has a lot of input combinations, separate the test into sub-tests.
• Test cases to verify error conditions should be written separately from functional test cases and should have steps to verify the error messages.

Examples:
i) We can break negative testing for login functionality into sub tests for different values like:
a) Verify with invalid email-id
b) Verify with invalid password
c) Verify with blank email-id field and so on…

ii) Divide test cases under below mentioned categories to write more exhaustive test cases:
a) Functional
b) Performance
c) Security
d) Usability
e) Compatibility
f) Recoverability
g) Negative
h) UI

6. Assumptions, Preconditions and Post conditions

Make sure to add as much information as possible for any conditions to be met not only before but also after running the test case

Examples:

• Any user data dependency (e.g. the user should be logged in, which page should the user start the journey, etc.)
• Dependencies on test environment
• Any special setup to be done before Test Execution
• Dependencies on any other test cases – does the Test Case need to be run before/after some other Test Case
• Changes to be made to a test data for it to be used for a later Test Case for the same functionality

7. Make use of testing techniques

It’s impractical to check each conceivable condition in the software. Testing techniques help to select a couple test cases with the most extreme plausibility of finding a defect.

• Boundary Value Analysis (BVA): As the name recommends, the method characterizes the testing of limits for indicated scope of values.
• Equivalence Partition (EP): This method partitions the range into equivalent amounts of/groups that have a tendency to have the same behavior.
• State Transition Technique: This strategy is utilized when software conduct changes starting with one state then onto the next after specific activity or action.
• Error Guessing Technique: This is speculating/foreseeing the defects that may emerge while testing. This is not a formal strategy and takes focal points of an tester’s involvement with the application.

8. Test data Input

• Well Categorized for e.g.: XML,.msg, pdf etc
• Well know lower and upper limit for e.g. Size
• Sample test data provided by BA not only saves time but also aids in exception handling to developers
• Well defined Repository to be maintained for reusability

9. Legible & Easily Understandable

• Test Cases will not always be executed by the one who designs them. So, they should be Simple and easily understandable by everyone
• They should be precise
• Sufficient Requirement Coverage

10. Review and Brainstorming

• We should ensure that Test Cases written are correct and conform to standards and requirements
• Test Case Review can be done by peer testers (termed ‘Peer Review’), BA, developers, product owners or any relevant stakeholders to ensure no scenarios or requirement is missed out or misunderstood

11. Reusable

• Write test cases keeping in mind that they could be re-used in the future for some other project/teams.ion
• Also, if there are existing test cases written earlier around the same module, one should be updating it as per new requirements

Create template of most basic test cases, which can be re-used.
For example:
a) Compare UI with designs
b) App compatibility when a phone call/ message came
c) Mandatory and Non mandatory fields are distinctive
d) Page scrolling scenarios are enabled/ disabled
e) Working on Wi-Fi and mobile data (as per requirement)
f) Network Error messages, Server error messages etc.

12. Maintenance & Updates

• MUST consider updating the existing Test Cases instead of writing any new Test Cases hence avoiding redundancies to the existing set.
• This also makes sure to have updated Test Cases for any journey in the application.
• Addition to existing test sets along with newly discovered scenarios make its useful repository from regression point of view.
• It saves time for next execution/release cycle by use of existing test cases.