| Previous | Home | Next |
White Box Testing Technique
White box testing examines the basic program structure and it derives the test data from the program logic, ensuring that all statements and conditions have been executed at least once.
White box tests verify that the software design is valid and also whether it was built according to the specified design.
Different methods used are:
- Statement coverage– executes all statements at least once. (each and every line)
- Decision coverage– executes each decision direction at least once.
- Condition coverage– executes each and every condition in the program with all possible outcomes at least once.
Black-box test technique treats the system as a "black-box", so it doesn't explicitly use knowledge of the internal structure. Black-box test design is usually described as focusing on testing functional requirements. Synonyms for black box include: Behavioral, Functional, Opaque-box, and Closed-box.
Black box testing is conducted on integrated, functional components whose design integrity has been verified through completion of traceable white box tests. Black box testing traces the requirements focusing on system externals. It validates that the software meets the requirements irrespective of the paths of execution taken to meet each requirements.
- Equivalence Partitioning
- /java Boundary Analysis
- Error Guessing
Equivalence Partitioning: Equivalence partitioning is the process of methodically reducing the huge(infinite)set of possible test cases into a much smaller, but still equally effective set. An Equivalence class is a subset of data that is representative of a larger class. Equivalence partitioning is a technique for testing equivalence classes rather than undertaking exhaustive testing of each value of the larger class, when looking for equivalence partitions, think about ways to group similar inputs, similar outputs, and similar operations of the software. These groups are the equivalence partitions.
For Example
A program that edits credit limits within a given range ($20,000-$50,000) would have three equivalence classes:
Less than $20,000(invalid) Between $20,000 and $50,000 (valid) Greater than $50,000(invalid)
Boundary value analysis: If one can safely and confidently walk along the edge of a cliff without falling off, he can almost certainly walk in the middle of a field. If software can operate on the edge of its capabilities, it will almost certainly operate well under normal conditions.
This technique consist of developing test cases and data that focus on the input and output boundaries of a given function. In same credit limit example, boundary analysis would test:
For Example
Low boundary plus or minus one ($19,999 and $20,001) On the boundary ($20,000 and $50,000) Upper boundary plus or minus one ($49,999 and $50,001)
Error Guessing:
This is based on the theory that test cases can be developed based upon the intuition and experience of the Test-Engineer.
Example
In the example of date, where one of the inputs is the date, a test may try February 29, 2000 or 9.9.99
Incremental testing is a disciplined method of testing the interfaces between unit-tested programs as well as between system components. It involves adding unit-tested programs to a given module or component one by one, and testing each result and combination.
There are two types of incremental testing:
Top-down: This begins testing from top of the module hierarchy and work down to the bottom using interim stubs to simulate lower interfacing modules or programs. Modules are added in descending hierarchical order.
Bottom-up: This begins testing from the bottom of the hierarchy and works up to the top. Modules are added in ascending hierarchical order. Bottom-up testing requires the development of driver modules, which provide the test input, call the module or program being tested, and display test output.
There are procedures and constraints associated with each of these methods, although bottom-up testing is often thought to be easier to use. Drivers are often easier to create than stubs, and can serve multiple purposes. Output is also often easier to examine in bottom-up testing, as the output always comes from the module directly above the module under test.
This test technique, which is often used during early integration testing, demonstrates key functional capabilities by testing a string of units that accomplish a specific function in the application. Thread testing and incremental testing are usually utilized together. For example, units can undergo incremental until enough units are integrated and a single business function can be performed, threading.
Requirement>>Design>> Development>Internal Testing>Release>User Acceptance>Maintenance>closure
Analysis process: This process aims at gathering and detailing of Customer’s software requirements. Mainly the Techno Functional Team takes inputs from customer & prepares a Requirement specification document, which is approved by the customer.
Design process: This process details out the design of the software. In this phase all the customer’s requirements are translated in to Design Architecture.
Coding process: This process is executed to translate the design in to software code.
Testing process: This process is essential to detect the defects before release of software to the customer.
Release process: This phase is essential to plan the Installation and release Plan. The phase is important as it ensures that the code delivered meets the customer’s criteria in all respect – the technical and non- technical.
User Acceptance: This phase focuses on functionality testing to check whether the system meets user acceptance criteria or not.
Maintenance: This phase focuses on post delivery support provided at the client site. This includes handling change requests & documentation support.
Closure: This process is essential to understand the learning’s gained at the end of the project. This phase is important as it ensures that the project resources are released and the metrics are analyzed.
| Previous | Home | Next |