Medical Billing Training Schools

Boundary Value Analysis & Equivalence Partitioning Testing

Posted by Unknown On Saturday, 13 July 2013 1 comments



Boundary Value Analysis
  • Black-box technique that focuses on the  boundaries of the input domain rather than its center
  • Whenever the engineers need to develop test cases for a range kind of input then they   will go for boundary value analysis.
Boundary Value Analysis guidelines:
·         If input condition specifies a range bounded by values a and b, test cases should include a and b,       values just above and just below a and b
·         If an input condition specifies and number of values, test cases should be exercise the minimum and maximum numbers, as well as values just above and just below the minimum and maximum values
·         Apply guidelines 1 and 2 to output conditions, test cases should be designed to produce the minimum and maxim output reports
·         If internal program data structures have boundaries (e.g. size limitations), be certain to test the boundaries
Equivalence Partitioning Testing
·         Black-box technique that divides the input domain into classes of data from which test cases can be derived
·         An ideal test case uncovers a class of errors that might require many arbitrary test cases to be executed before a general error is observed
·         Whenever the test engineer need to develop test cases for a feature which has more number of validation then one will go for equivalence class partition. Which describe first divide the class of inputs and then prepare the test cases
Equivalence class guidelines:
·         If input condition specifies a range, one valid and two invalid equivalence classes are defined
·         If an input condition requires a specific value, one valid and two invalid equivalence classes are defined
·         If an input condition specifies a member of a set, one valid and one invalid equivalence class is defined
·         If an input condition is Boolean, one valid and one invalid equivalence class is defined

Black box, White box and Grey Box testing

Posted by Unknown On 0 comments



Difference b/w Black Box, White Box and Grey Box Testing
Black Box Testing
The technique of testing without having any knowledge of the interior workings of the application is Black Box testing. Typically, when performing a black box test, a tester will interact with the system's user interface by providing inputs and examining outputs without knowing how and where the inputs are worked upon.
Advantages
Disadvantages
  • Well suited and efficient for large code segments.
  • Code Access not required.
  • Clearly separates user's perspective from the developer's perspective through visibly defined roles.
  • Large numbers of moderately skilled testers can test the application with no knowledge of implementation, programming language or operating systems.
  • Limited Coverage since only a selected number of test scenarios are actually performed.
  • Inefficient testing, due to the fact that the tester only has limited knowledge about an application.
  • Blind Coverage, since the tester cannot target specific code segments or error prone areas.
  • The test cases are difficult to design.
White Box Testing
White box testing is the detailed investigation of internal logic and structure of the code. White box testing is also called glass testing or open box testing. In order to perform white box testing on an application, the tester needs to possess knowledge of the internal working of the code.
Advantages
Disadvantages
  • As the tester has knowledge of the source code, it becomes very easy to find out which type of data can help in testing the application effectively.
  • It helps in optimizing the code.
  • Extra lines of code can be removed which can bring in hidden defects.
  • Due to the tester's knowledge about the code, maximum coverage is attained during test scenario writing.
  • Due to the fact that a skilled tester is needed to perform white box testing, the costs are increased.
  • Sometimes it is impossible to look into every nook and corner to find out hidden errors that may create problems as many paths will go untested.
  • It is difficult to maintain white box testing as the use of specialized tools like code analyzers and debugging tools are required.

Grey Box Testing
Grey Box testing is a technique to test the application with limited knowledge of the internal workings of an application. In software testing, the term the more you know the better carries a lot of weight when testing an application.
Mastering the domain of a system always gives the tester an edge over someone with limited domain knowledge. Unlike black box testing, where the tester only tests the application's user interface, in grey box testing, the tester has access to design documents and the database. Having this knowledge, the tester is able to better prepare test data and test scenarios when making the test plan.
Advantages
Disadvantages
  • Offers combined benefits of black box and white box testing wherever possible.
  • Grey box testers don't rely on the source code; instead they rely on interface definition and functional specifications.
  • Based on the limited information available, a grey box tester can design excellent test scenarios especially around communication protocols and data type handling.
  • The test is done from the point of view of the user and not the designer.
  • Since the access to source code is not available, the ability to go over the code and test coverage is limited.
  • The tests can be redundant if the software designer has already run a test case.
  • Testing every possible input stream is unrealistic because it would take an unreasonable amount of time; therefore, many program paths will go untested.

Difference b/w Alpha & Beta Testing

Posted by Unknown On 1 comments



Alpha & Beta Test
Alpha Test
Beta Test
What they do
Improve the quality of the product and ensure beta readiness.
Improve the quality of the prouduct, integrate customer input on the complete product, and ensure release readiness.
When they happen
Toward the end of a development process when the product is in a near fully-usable state.
Just prior to launch, sometimes ending within weeks or even days of final release.
How long they last
Usually very long and see many iterations. It’s not uncommon for alpha to last 3-5x the length of beta.
Usually only a few weeks (sometimes up to a couple of months) with few major iterations.
Who cares about it
Almost exclusively quality/engineering (bugs, bugs, bugs).
Usually involves product marketing, support, docs, quality and engineering (basically the entire product team).
Who participates (tests)
Normally performed by test engineers, employees, and sometimes “friends and family”. Focuses on testing that would emulate ~80% of the customers.
Tested in the “real world” with “real customers” and the feedback can cover every element of the product.
What testers should expect
Plenty of bugs, crashes, missing docs and features.
Some bugs, fewer crashes, most docs, feature complete.
How they’re addressed
Most known critical issues are fixed, some features may change or be added as a result of early feedback.
Much of the feedback collected is considered for and/or implemented in future versions of the product. Only important/critical changes are made.
What they achieve
About methodology, efficiency and regiment. A good alpha test sets well-defined benchmarks and measures a product against those benchmarks.
About chaos, reality, and imagination. Beta tests explore the limits of a product by allowing customers to explore every element of the product in their native environments.
When it’s over
You have a decent idea of how a product performs and whether it meets the design criteria (and if it’s “beta-ready”)
You have a good idea of what your customer thinks about the product and what s/he is likely to experience when they purchase it.
What happens next
Beta Test!
Release Party!