Active TopicsActive Topics  Display List of Forum MembersMemberlist  CalendarCalendar  Search The ForumSearch  HelpHelp
  RegisterRegister  LoginLogin


 One Stop Testing ForumSoftware Testing @ OneStopTestingTest Cases @ OneStopTesting

Message Icon Topic: Designing Test Cases

Post Reply Post New Topic
Author Message
Shreya
Newbie
Newbie


Joined: 22Feb2007
Online Status: Offline
Posts: 1
Quote Shreya Replybullet Topic: Designing Test Cases
    Posted: 22Feb2007 at 6:15pm

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.

Figure 2.10   Designing Test Cases

Designing Test Cases

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.

Table 2.1 provides an example of the first few steps of a detailed test case.

Table 2.1   Sample Detailed Test Case

StepProcedureSuccess CriteriaOutcome

1

Log off the server, and return to the netlogon screen.

None.


2

Click the domain list to open it.

The local server name does not appear in the list.


3

Click the domain list to open it.

The root domain appears in the list.


4

Log on to the server using an account with administrative credentials.

The account logs on to the server without errors.


When planning your tests, remember that it is not feasible to test everything. Instead of trying to test every combination, prioritize your testing so that you perform the most important tests — those that focus on areas that present the greatest risk or have the greatest probability of occurring — first. For example, you might choose to test the slowest client computer, the busiest server, or the least reliable network link. Then, if time allows, you can perform lower priority tests.




Post Resume: Click here to Upload your Resume & Apply for Jobs

IP IP Logged
suresh5003
Newbie
Newbie


Joined: 18May2009
Online Status: Offline
Posts: 1
Quote suresh5003 Replybullet Posted: 19May2009 at 12:39am
< ="Content-" content="text/; charset=utf-8">< name="ProgId" content="Word.">< name="Generator" content="Microsoft Word 12">< name="Originator" content="Microsoft Word 12"><>

In software Testing Test Design is the important for software testing itself, to reduce the testcases as minimum as possible and find more defects

  Recently I have seen a tool called
TestersDesk.com which is used specially for Test Design and Test Data Generation Tools, There are different types of tools which are used to reduce the testcases into little number.
I think Designing TestCases into a little number covering all possible combinations manually  its difficult for that we have to go to the  tool which reduces minimum Testcases and find more defects.
Suresh
IP IP Logged
JustinH
Newbie
Newbie
Avatar

Joined: 28Jul2009
Location: United States
Online Status: Offline
Posts: 13
Quote JustinH Replybullet Posted: 28Jul2009 at 10:24pm
Please also consider the Hexawise test case generating tool at http://www.hexawise.com/users/new.  We have a free version and a 30-second login process for full access.

Unlike most test design tools, Hexawise offers:

1) Not only pairwise (AKA 2-way) solutions, but we offer 3-way, 4-way, 5-way, and even 6-way solutions.  (In other words, you can choose the level of thoroughness you desire, and Hexawise will generate the test conditions you should execute).

2) Clear graphs showing the coverage that your test plan is generating (e.g., you will be able to tell that after test #26, for example, you have tested for a specific percentage of the total number of possible pairs of values that you have indicated you want to test for

3) Example plans that help get you started using a test design tool

4) Clear FAQ and Help sections to address any questions you might have (see http://www.hexawise.com/faq and http://www.hexawise.com/help

5) The ability to identify certain combinations of values as invalid.  (Once testers begin using test design tools, they recognize that this feature is extremely important; if Parameter values include "Annual Income" = US$5,000 and "Mortgage Type" = Jumbo, for example, but a user of a mortgage application with that income would be unable to even select the option to apply for a Jumbo mortgage, if your test design tool does not allow you to eliminate those invalid combinations automatically, you will either (a) wind up with lost coverage that you had hoped your tool would be able to deliver, (b) spend many hours trying to address this shortfall by manual adjustments to your test cases, or (c) both.

Lastly, we have an 11-slide presentation on our home page to quickly provide a little more background information about the tool and the problems it solves with screen shots.  It also contains an interesting case study of how Hexawise can help you reduce 72 billion possible test cases (that would be required -at least - to comprehensively test the "get directions" functionality of Google Maps) to only 35 test cases that achieve coverage of every single valid pair of parameter values involved.  (e.g., in those 35 test cases, every single browser type is tested together with every mode of transportation choice at least once, every single view option is tested together with every option for the zoom/in zoom/out function, etc.)

Please sign up for free access at:  http://www.hexawise.com/users/new

Thank you.

- Justin
___________________________
Founder and CEO of Hexawise
www.hexawise.com
"More coverage. Fewer tests."
IP IP Logged
cool7575
Newbie
Newbie


Joined: 13Sep2007
Online Status: Offline
Posts: 28
Quote cool7575 Replybullet Posted: 30Jul2009 at 3:19am
As i always say read the requirement first and understand it clearly. then try to identify the flows associated with requirements. Those are your test cases. Consider negative testing as well where application will fail.

The above document in the first post is pretty good.

thanks
Software Testing

IP IP Logged
Post Reply Post New Topic
Printable version Printable version

Forum Jump
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum



This page was generated in 0.719 seconds.
Vyom is an ISO 9001:2000 Certified Organization

© Vyom Technosoft Pvt. Ltd. All Rights Reserved.

Privacy Policy | Terms and Conditions
Job Interview Questions | Placement Papers | Free SMS | Freshers Jobs | MBA Forum | Learn SAP | Web Hosting