preethi.gollamandala

 Profile Answers by preethi.gollamandala 

• Jan 15th, 2009

 

Testing Techniques:

1)Boundary value Analysis
2)Euqalence class partician
3)back end validation/data base Testing
4)Positive and Negative testing

preethi.gollamandala

 Profile Answers by preethi.gollamandala 

• Jul 29th, 2009

 

Following are the different techinques to follow while conducting testing
1)Error guessing
2)Equivalnce class partician
3)Boundary value analysis
4)-ve testing
5)Complete test coverage grip on the product

kurtz182

 Profile Answers by kurtz182 Questions by kurtz182

• Dec 12th, 2009

 

Equivalence Class Partitioning:  This method is used to reduce the number of tests necessary to adequately test something.  For example, a text box accepts integers from 0 to 1000.  I could run 1001 tests to verify the behavior of each integer.  Yet, since all integers are equivalent, I can select a few of them with confidence that the others will behave the same way.

Cause-Effect Graph Analysis: This method is used to produce a more rigorous set of test cases with greater coverage.  Among other things, it has the ability to detect defects that cancel one another out, and the ability to detect hidden defects when other things are working properly.  This process begins with the requirements document.  Each requirement is converted to a logical statement and its graphic representation is represented in a graph using guidelines specific to Cause-Effect analysis. From there, each graphic representation is entered into a decision "truth" table where individual test cases are identified. Finally, each test case is mapped to a set of unique causes in the truth table and are converted back into a clear and concise narrative that is easily understood and testable.   

Error Guessing:  For a software tester, error guessing is the process of making an educated guess in order to determine where problems are likely to be discovered in an application.  For example, error guesses can be based on a tester's knowledge of an application's vulnerabilities from past experiences or a tester's observation and concern that a particular functionality was not clearly and/or thoroughly covered by a functional specification.