Software Testing Methodology Interview Preparation Guide

1. White Box
Also called ‘Structural Testing / Glass Box Testing’ is used for testing the code keeping the system specs in mind. Inner working is considered and thus Developers Test..
* Mutation Testing
Number of mutants of the same program created with minor changes and none of their result should coincide with that of the result of the original program given same test case.


* Basic Path Testing
Testing is done based on Flow graph notation, uses Cyclometric complexity & Graph matrices.


* Control Structure Testing
The Flow of control execution path is considered for testing. It does also checks :-
Conditional Testing : Branch Testing, Domain Testing.
Data Flow Testing.
Loop testing :Simple, Nested, Conditional, Unstructured Loops.

2. Gray Box

3. Black Box
Also called ‘Functional Testing’ as it concentrates on testing of the functionality rather than the internal details of code.
Test cases are designed based on the task descriptions
* Comparison Testing
Test cases results are compared with the results of the test Oracle.


* Graph Based Testing
Cause and effect graphs are generated and cyclometric complexity considered in using the test cases.


* Boundary Value Testing
Boundary values of the Equivalence classes are considered and tested as they generally fail in Equivalence class testing.


* Equivalence class Testing
Test inputs are classified into Equivalence classes such that one input check validates all the input values in that class.


Gray Box Testing : Similar to Black box but the test cases, risk assessments, and test methods involved in gray box testing are developed based on the knowledge of the internal data and flow structures

Automated testing is as simple as removing the "human factor" and letting the computer do the thinking. This can be done with integrated debug tests, to much more intricate processes. The idea of the these tests is to find bugs that are often very challenging or time intensive for human testers to find. This sort of testing can save many man hours and can be more "efficient" in some cases. But it will cost more to ask a developer to write more lines of code into the game (or an external tool) then it does to pay a tester and there is always the chance there is a bug in the bug testing program. Reusability is another problem; you may not be able to transfer a testing program from one title (or platform) to another. And of course, there is always the "human factor" of testing that can never truly be replaced.

Other successful alternatives or variation: Nothing is infallible. Realistically, a moderate split of human and automated testing can rule out a wider range of possible bugs, rather than relying solely on one or the other. Giving the testere limited access to any automated tools can often help speed up the test cycle.

The functional acceptance simple test(FAST) is run on each development release to check that key features of the program are appropriately accessible and functioning properly on the at least one test configuration (preferable the minimum or common configuration).This test suite consists of simple test cases that check the lowest level of functionality for each command- to ensure that task-oriented functional tests(TOFTs) cna be performed on the program. The objective is to decompose the functionality of a program down to the command level and then apply test cases to check that each command works as intended. No attention is paid to the combination of these basic commands, the context of the feature that is formed by these combined commands, or the end result of the overall feature. For example, FAST for a File/Save As menu command checks that the Save As dialog box displays. However, it does not validate that the overall file-saving feature works nor does it validate the integrity of save files.

Usage " To determine if the system can function when subject to large volumes.
" It includes testing of
input transactions
Internal tables
Disk Space
Out put
Communication
Computer capacity
Interaction with people.
Objectives " To simulate production environment
" Normal or above normal volumes of transactions can be processed through the transaction within expected time frame.
" Application system would be able to process larger volume of data.
" System capacity should have sufficient resources to meet expected turnaround time.
How to Use " It should simulate as closely as possible to production environment.
" Online system should be stress tested with users entering test data with normal or above normal pace.
" Batch system should be tested with huge volumes/ numbers of batches
" The test conditions should have error conditions.
" Transactions used in stress testing are obtained from following 3 sources :
Test data generators
Test transactions created by test group
Transactions which were previously used in production.
" In stress testing the system should run as it would in the production environment.
When to use " When there is uncertainty that system will work with huge volumes of data and without generating any faults.
" Attempt is made to break system with huge amount of data.
" Most commonly used technique to test for online transaction systems as other
techniques are not effective.
Examples " Sufficient disk space allocated
" Communication lines are adequate
Disadvantage " Amount of time taken to prepare for testing
" Amount of resources utilized during test execution.

1. Unit Testing.
* Unit Testing is primarily carried out by the developers themselves.
* Deals functional correctness and the completeness of individual program units.
* White box testing methods are employed


2. Integration Testing.
* Integration Testing: Deals with testing when several program units are integrated.
* Regression testing : Change of behavior due to modification or addition is called ‘Regression’. Used to bring changes from worst to least.
* Incremental Integration Testing : Checks out for bugs which encounter when a module has been integrated to the existing.
* Smoke Testing : It is the battery of test which checks the basic functionality of program. If fails then the program is not sent for further testing.


3. System Testing.
* System Testing - Deals with testing the whole program system for its intended purpose.
* Recovery testing : System is forced to fail and is checked out how well the system recovers the failure.
* Security Testing : Checks the capability of system to defend itself from hostile attack on programs and data.
* Load & Stress Testing : The system is tested for max load and extreme stress points are figured out.
* Performance Testing : Used to determine the processing speed.
* Installation Testing : Installation & uninstallation is checked out in the target platform.


4. Acceptance Testing.
* UAT ensures that the project satisfies the customer requirements.
* Alpha Testing : It is the test done by the client at the developer’s site.
* Beta Testing : This is the test done by the end-users at the client’s site.
* Long Term Testing : Checks out for faults occurrence in a long term usage of the product.
* Compatibility Testing : Determines how well the product is substantial to product transition.

The release acceptance test (RAT), also referred to as a build acceptance or smoke test, is run on each development release to check that each build is stable enough for further testing. Typically, this test suite consists of entrance and exit test cases plus test cases that check mainstream functions of the program with mainstream data. Copies of the RAT can be distributed to developers so that they can run the tests before submitting builds to the testing group. If a build does not pass a RAT test, it is reasonable to do the following:

* Suspend testing on the new build and resume testing on the prior build until another build is received.
* Report the failing criteria to the development team.
* Request a new build.

The configuration on which the Web system will be deployed will often be much different from develop-and-test configurations. Testing efforts must consider this in the preparation and writing of test cases for installation time acceptance tests. This type of test usually includes the full installation of the applications to the targeted environments or configurations.

Ping tests use the Internet Control Message Protocol(ICMP) to send a ping request to a server. If the ping returns, the server is assumed to be alive and well. The downside is that usually a Web server will continue to return ping requests even when the Web-enable application has crashed.

Usage " It involves testing of all the functions performed by the people while preparing the data and using these data from automated system.
Objectives " Verify - manual support documents and procedures are correct.
" Determine -
Manual support responsibility is correct
Manual support people are adequately trained.
Manual support and automated segment are properly interfaced.
How to Use " It involves:
Evaluation of adequacy of process
Execution of process
" Process evaluated in all segments of SDLC.
" Execution of the can be done in conjunction with normal system testing.
" Instead of preparing, execution and entering actual test transactions the clerical and supervisory personnel can use the results of processing from application system.
" It involves several iterations of process.
" To test people it requires testing the interface between the people and application system.
When to use " Verification that manual systems function properly should be conducted throughout the SDLC.
" Should not be done at later stages of SDLC.
" Best done at installation stage so that the clerical people do not get used to the actual system just before system goes to production.
Examples " Provide input personnel with the type of information they would normally receive from their customers and then have them transcribe that information and enter it in the computer.
" Users can be provided a series of test conditions and then asked to respond to those conditions. Conducted in this manner, manual support testing is like an examination in which the users are asked to obtain the answer from the procedures and manuals available to them.

Background " Application systems are frequently interconnected to other application system.
" The interconnection may be data coming from another application system, leaving for another application system or both.
" Frequently multiple systems (applications) sometimes called cycles or functions are involved.
Usage " To ensure interconnection between application functions correctly.
Objectives " Determining -
Proper parameters and data are correctly passed between the applications
Documentation for involved system is correct and accurate.
" Ensure Proper timing and coordination of functions exists between the application system.
How to Use " Operations of multiple systems are tested.
" Multiple systems are run from one another to check that they are acceptable and processed properly.
When to use " When there is change in parameters in application system
" The parameters, which are erroneous then risk associated to such parameters, would decide the extent of testing and type of testing.
" Intersystem parameters would be checked / verified after the change or new application is placed in the production.
Examples " Develop test transaction set in one application and passing to another system to verify the processing.
" Entering test transactions in live production environment and then using integrated test facility to check the processing from one system to another.
" Verifying new changes of the parameters in the system, which are being tested, are corrected in the document.
Disadvantage " Time consuming
" Cost may be expensive if system is run several times iteratively.