Triaged Tester

March 20, 2009

Test cases for Black box

Filed under: Black Box Testing,Test case,Tips — Triaged Tester @ 9:34 am
Tags: , , ,

For Black box testing, the test cases can be generated by using all or a combination of the below techniques.

Graph Based : Software testing begins by creating a graph of important objects and their relationships and then devising a series of tests that will cover the graph so that each objects and their relationships and then devising a series of tests that will cover the graph so that each object and relationship is exercised and error is uncovered.

Error Guesssing – Error Guessing comes with experience with the technology and the project. Error Guessing is the art of guessing where errors can be hidden. There are no specific tools and techniques for this, but you can write test cases depending on the situation. 

Boundary Value Analysis (BVA) is a test data selection technique (Functional Testing technique) where the extreme values are chosen. Boundary values include maximum, minimum, just inside/outside boundaries, typical values, and error values. The hope is that, if a system works correctly for these special values then it will work correctly for all values in between. 

Equivalence partitioning is a testing method that divides the input domain of a program into classes of data from which test cases can be derived.

Compasrision Testing – There are situations where independent versions of software be developed for critical applications, even when only a single version will be used in the delivered computer based system. It is these independent versions which form the basis of a black box testing technique called Comparison testing or back-to-back testing.

The Orthogonal Array Testing Strategy (OATS) is a systematic, statistical way of testing pair-wise interactions by deriving a suitable small set of test cases (from a large number of possibilities).

Advertisements

March 5, 2009

% of Dev effort for test estimation

Filed under: Estimation,Guidelines,Stratergies,Test Management — Triaged Tester @ 1:21 pm
Tags: ,

Some organizations utilize a quick estimation method for testing based on the estimated programming effort. For example, if a project is estimated to require 1000 hours of programming effort, and the organization normally finds that a 40% ratio for testing is appropriate, then an estimate of 400 hours for testing would be used. This approach may or may not be useful depending on the project-to-project variations in risk, personnel, types of applications, levels of complexity, etc.

March 3, 2009

Iterative approach for test estimation

Filed under: Estimation,Guidelines,Stratergies,Test Management — Triaged Tester @ 1:18 pm
Tags: ,

In this approach for large test efforts, an initial rough testing estimate is made. Once testing begins, a more refined estimate is made after a small percentage (e.g., 1%) of the first estimate’s work is done. At this point testers have obtained additional test project knowledge and a better understanding of issues, general software quality, and risk. Test plans and schedules can be re-factored if necessary and a new estimate provided. Then a yet-more-refined estimate is made after a somewhat larger percentage (e.g., 2%) of the new work estimate is done. Repeat the cycle as necessary/appropriate

February 27, 2009

Metrics based approach for test estimation

Filed under: Estimation,Guidelines,Metrics,Test Management — Triaged Tester @ 1:15 pm
Tags: ,

A useful approach is to track past experience of an organization’s various projects and the associated test effort that worked well for projects. Once there is a set of data covering characteristics for a reasonable number of projects, then this ‘past experience’ information can be used for future test project planning. (Determining and collecting useful project metrics over time can be an extremely difficult task.) For each particular new project, the ‘expected’ required test time can be adjusted based on whatever metrics or other information is available, such as function point count, number of external system interfaces, unit testing done by developers, risk levels of the project, etc. In the end, this is essentially judgment based on documented experience’, and is not easy to do successfully

February 23, 2009

Test Estimate – Quick ‘n’ Dirty

Filed under: Estimation,Guidelines,Test Management — Triaged Tester @ 1:11 pm
Tags: ,

Here is what you can follow to arrive at an high level of estimation for test projects. It’s the quick and dirty way , but you would be surprised that it gives almost the correct results 🙂

testestimate

Next Page »

Create a free website or blog at WordPress.com.