Skip to main content

Fundamentals of Test Cases



Designing Test Cases

A test case is a detailed procedure that fully tests a feature or an aspect of a feature. Whereas the test plan describes what to test, a test case describes how to perform a particular test. You need to develop a test case for each test listed in the test plan. Figure 2.10 illustrates the point at which test case design occurs in the lab development and testing process.

 

A test case includes:
•    The purpose of the test.
•    Special hardware requirements, such as a modem.
•    Special software requirements, such as a tool.
•    Specific setup or configuration requirements.
•    A description of how to perform the test.
•    The expected results or success criteria for the test.

Test cases should be written by a team member who understands the function or technology being tested, and each test case should be submitted for peer review.

Organizations take a variety of approaches to documenting test cases; these range from developing detailed, recipe-like steps to writing general descriptions. In detailed test cases, the steps describe exactly how to perform the test. In descriptive test cases, the tester decides at the time of the test how to perform the test and what data to use.
Most organizations prefer detailed test cases because determining pass or fail criteria is usually easier with this type of case. In addition, detailed test cases are reproducible and are easier to automate than descriptive test cases. This is particularly important if you plan to compare the results of tests over time, such as when you are optimizing configurations. Detailed test cases are more time-consuming to develop and maintain. On the other hand, test cases that are open to interpretation are not repeatable and can require debugging, consuming time that would be better spent on testing.

Test Case Design
Test Case ID:
It is unique number given to test case in order to be identified.

Test description:
The description if test case you are going to test.

Revision history:
Each test case has to have its revision history in order to know when and by whom it is created or modified.

Function to be tested:
The name of function to be tested.

Environment:
It tells in which environment you are testing.

Test Setup:
Anything you need to set up outside of your application for example printers, network and so on.

Test Execution:
It is detailed description of every step of execution.

Expected Results:
The description of what you expect the function to do.

Actual Results:
pass / failed
If pass - What actually happen when you run the test.
If failed - put in description of what you've observed.

The Purpose of a good test case?
There are several objectives of any effective test whether manually executed or automated. The rationale for test case usually falls into one of seven categories. Each category provides value to the organization in different ways, but they all essentially function to reduce risk and qualify the testing effort. So, a good test provides some measurable value to the organization with the explicit purpose of:

•    Verifying conformance to applicable standards and guidelines and customer requirements

•    Validating expectations and customer needs

•    Increasing control flow coverage

•    Increasing logic flow coverage

•    Increasing data flow coverage

•    Simulating 'real' end user scenarios

•    Exposing errors or defects

Comments

Post a Comment

Popular posts from this blog

Mobile Application Testing Checklist

1. DEVICE SPECIFIC CHECKS 1.1  Can the app be installed on the device? 1.2 Does the app behave as designed/desired if there is an incoming call? 1.3 Does the app behave as designed/desired if there is an incoming SMS? 1.4 Does the app behave as designed/desired if the charger is connected? 1.5 Does the app behave as designed/desired if the charger is disconnected? 1.6 Does the app behave as designed/desired if the device goes to sleeping mode 1.7 Does the app behave as designed/desired if the device resumes from sleeping mode 1.8  Does the app behave as designed/desired if the device resumes from lock screen? 1.9    Does the app behave as designed/desired if the device is tilted? 1.10  Does the app behave as designed/desired if the device is shaken? 1.11 Does the app behave as designed/desired if a local message is coming from another app (think   of: calendar reminders, to-do task etc.). 1.12 Does the app behave as designed/desired if a push message i...
Post a Comment
Read more

Test Scenarios for Excel Export Functionality

1. The file should get exported in the proper file extension. 2. The file name for the exported Excel file should be as per the standards e.g. if the file name is using the timestamp, it should get replaced properly with an actual timestamp at the time of exporting the file. 3. Check for date format if exported Excel file contains the date columns. 4. Check number formatting for numeric or currency values. Formatting should be the same as shown on the page. 5. The exported file should have columns with proper column names. 6. Default page sorting should be carried in the exported file as well. 7. Excel file data should be formatted properly with header and footer text, date, page numbers etc. values for all pages. 8. Check if the data displayed on a page and exported Excel file is the same. 9. Check export functionality when pagination is enabled. 10. Check if export button is showing proper icon according to the exported file type E.g . Excel file icon for xls files 11. ...
Post a Comment
Read more

Software Testing Tips

Here are some of the Best Testing Practices which I learned by Experience:  1) Learn to analyze your test results thoroughly. Do not ignore any test result. The final test result may be ‘pass’ or ‘fail’, but troubleshooting the root cause of ‘fail’ will give you the solution of the problem. Testers will be respected if they not only log the bugs but also provide solutions. 2) Learn to maximize the test coverage each time you test any application. 100% test coverage might not be possible but still, you can always try to reach near it. 3) In order to ensure maximum test coverage, break your application under test (AUT), into smaller functional modules. Write test cases on such individual unit modules. Also if possible break these modules into smaller parts. E.g : Lets assume that you have divided your website application in modules and ‘accepting user information’ is one of the modules. You can break this ‘User information’ screen into smaller parts for writing ...
Post a Comment
Read more