manual testing - Manual Testing @ OneStopTesting - Manual Testing @ OneStopTesting - Types Of Software Testing @ OneStopTesting

The most common definition of a test case is a set of conditions or variables under which a tester will determine if a requirement or use case upon an application is partially or fully satisfied.

It may take many test cases to determine that a requirement is fully satisfied. In order to fully test that all the requirements of an application are met, there must be at least one test case for each requirement unless a requirement has sub-requirements.

In that situation, each sub-requirement must have at least one test case. This is frequently done using a traceability matrix

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.

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 a detailed test case 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.

Author	Message
sagarbandari Newbie Joined: 29Aug2008 Location: India Online Status: Offline Posts: 18	Topic: manual testing Posted: 13Nov2008 at 2:15am
	what r the different types of testcases and for writing testcases wht r the methods r used, any one explain with some example Post Resume: Click here to Upload your Resume & Apply for Jobs

	IP Logged

chaitanyak6 Newbie Joined: 11Dec2008 Location: India Online Status: Offline Posts: 1	Posted: 12Dec2008 at 12:50am
	The most common definition of a test case is a set of conditions or variables under which a tester will determine if a requirement or use case upon an application is partially or fully satisfied. It may take many test cases to determine that a requirement is fully satisfied. In order to fully test that all the requirements of an application are met, there must be at least one test case for each requirement unless a requirement has sub-requirements. In that situation, each sub-requirement must have at least one test case. This is frequently done using a traceability matrix 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. 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 a detailed test case 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.
	Regards, Chaitanya.K HPIT – CSN TCOE
	IP Logged


One Stop Testing Forum : Types Of Software Testing @ OneStopTesting : Manual Testing @ OneStopTesting

Topic: manual testing