Designing Test Cases
Printed From: One Stop Testing
Category: Software Testing @ OneStopTesting
Forum Name: Test Cases @ OneStopTesting
Forum Discription: You must be well versed in writting Good Test Cases as they only will decide whether you can catch most of bugs or not.
URL: http://forum.onestoptesting.com/forum_posts.asp?TID=158
Printed Date: 05Dec2024 at 1:47am
Topic: Designing Test Cases
Posted By: Shreya
Subject: Designing Test Cases
Date 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 A test case includes:
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
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. |
Replies:
Posted By: suresh5003
Date 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"> file:///C:%5CDOCUME%7E1%5Cdfxhfcg%5CLOCALS%7E1%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_filelist.xml - file:///C:%5CDOCUME%7E1%5Cdfxhfcg%5CLOCALS%7E1%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_themedata.thmx - file:///C:%5CDOCUME%7E1%5Cdfxhfcg%5CLOCALS%7E1%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml - <>
- In software Testing Test Design is the important for software testing itself, to reduce the testcases as minimum as possible and find more defects |
Posted By: JustinH
Date 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." |
Posted By: cool7575
Date 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 http://softwareqatestings.com/ - Software Testing |