Software Testing Types: Black box testing Internal system design is not considered in this type of testing.

. Tests are based on requirements and functionality. White box testing This testing is based on knowledge of the internal logic of an applications code. Also known as Glass box Testing. Internal software and code working should be known for this type of testing. Tests are based on coverage of code statements, branches, paths, conditions. Unit testing Testing of individual software components or modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. may require developing test driver modules or test harnesses. Incremental integration testing Bottom up approach for testing i.e continuous testing of an application as new functionality is added; Application functionality and modules should be independent enough to test separately done by programmers or by testers. Integration testing Testing of integrated modules to verify combined functionality after integration. Modules are typically code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems. Functional testing This type of testing ignores the internal parts and focus on the output is as per requirement or not. Black-box type testing geared to functional requirements of an application. System testing Entire system is tested as per the requirements. Black-box type testing that is based on overall requirements specifications, covers all combined parts of a system. End-to-end testing Similar to system testing, involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate. Sanity testing - Testing to determine if a new software version is performing well enough to accept it for a major testing effort. If application is crashing for initial use then system is not stable enough for further testing and build or application is assigned to fix. Regression testing Testing the application as a whole for the modification in any module or functionality. Difficult to cover all the system in regression testing so typically automation tools are used for these testing types. Acceptance testing -Normally this type of testing is done to verify if system meets the customer specified requirements. User or customer do this testing to determine whether to accept application. Load testing Its a performance testing to check system behavior under load. Testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the systems response time degrades or fails.

Stress testing System is stressed beyond its specifications to check how and when it fails. Performed under heavy load like putting large number beyond storage capacity, complex database queries, continuous input to system or database load. Performance testing Term often used interchangeably with stress and load testing. To check whether system meets performance requirements. Used different performance and load tools to do this. Usability testing User-friendliness check. Application flow is tested, Can new user understand the application easily, Proper help documented whenever user stuck at any point. Basically system navigation is checked in this testing. Install/uninstall testing - Tested for full, partial, or upgrade install/uninstall processes on different operating systems under different hardware, software environment. Recovery testing Testing how well a system recovers from crashes, hardware failures, or other catastrophic problems. Security testing Can system be penetrated by any hacking way. Testing how well the system protects against unauthorized internal or external access. Checked if system, database is safe from external attacks. Compatibility testing Testing how well software performs in a particular hardware/software/operating system/network environment and different combination s of above. Comparison testing Comparison of product strengths and weaknesses with previous versions or other similar products. Alpha testing In house virtual user environment can be created for this type of testing. Testing is done at the end of development. Still minor design changes may be made as a result of such testing. Beta testing Testing typically done by end-users or others. Final testing before releasing application for commercial purpose.
Smoke Tests : Smoke Tests should be automated and take less than 2-3 hours (20 minutes is typical). These tests cases verify the major functionality a high level. The objective is to determine if further testing is possible. All components should be touched, and every major feature should be tested briefly by the Smoke Test. If any Level 2 test case fails, the build is returned to developers un-tested Non functional Testing : User interface : User Interface Testing (or) structural testing It verifies whether all the objects of user interface design specifications are met. It examines the spelling of button test, window title test and label test. Checks for the consistency or duplication of accelerator key letters and examines the positions and alignments of window objects Securitytesting If your site requires firewalls, encryption, user authentication, financial transactions, or access to databases with sensitive data, you may need to test these and also test your sites overall protection against unauthorized internal or external access

ExploratoryTesting Often taken to mean a creative, internal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it BenefitsRealizationtests With the increased focus on the value of Business returns obtained from investments in information technology, this type of test or analysis is becoming more critical. The benefits realization test is a test or analysis conducted after an application is moved into production in order to determine whether the application is likely to deliver the original projected benefits. The analysis is usually conducted by the business user or client group who requested the project and results are reported back to executive management MutationTesting Mutation testing is a method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes (bugs) and retesting with the original test data/cases to determine if the bugs are detected. Proper implementation requires large computational resources Sanity testing: Typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or destroying databases, the software may not be in a sane enough condition to warrant further testing in its current state

Sanitytesting
Typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort, For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or destroying databases, the software may not be in a sane enough condition to warrant further testing in its current state

BuildAcceptanceTests
Build Acceptance Tests should take less than 2-3 hours to complete (15 minutes is typical). These test cases simply ensure that the application can be built and installed successfully. Other related test cases ensure that Testing received the proper Development Release Document plus other build related information (drop point, etc.). The objective is to determine if further testing is possible. If any Level 1 test case fails, the build is returned to developers un-tested

BugRegressionTesting Every bug that was Open during the previous build, but marked as Fixed, Needs ReTesting for the current build under test, will need to be regressed, or re-tested. Once the smoke test is completed, all resolved bugs need to be regressed. It should take between 5 minutes to 1 hour to regress most bugs DatabaseTesting Database testing done manually in real time, it check the data flow between front end back ends. Observing that operations, which are operated on front-end is effected on back-end or not. The approach is as follows:

While adding a record there front-end check back-end that addition of record is effected or not. So same for delete, update, Some other database testing checking for mandatory fields, checking for constraints and rules applied on the table , some time check the procedure using SQL Volume produces Configuration hardware Documentation It is performed to verify the accuracy and completeness of user the anticipated results (Boundary value Query analyzer Testing analysis) Testing configurations Testing documentation

Testing the applications with voluminous amount of data and see whether the application

The system should be tested to determine it works correctly with appropriate software and

1. This testing is done to verify whether the documented functionality matches the software functionality 2. The documentation is easy to follow, comprehensive and well edited testing If the application under test has context sensitive help, it must be verified as part of documentation AcceptanceTesting Acceptance testing, which black box is testing, will give the client the opportunity to verify the system functionality and usability prior to the system being moved to production. The acceptance test will be the responsibility of the client; however, it will be conducted with full support from the project team. The Test Team will work with the client to develop the acceptance AlphaTesting Testing of an application when development is nearing completion, Minor design changes may still be made as a result of such testing. Alpha Testing is typically performed by end-users or others, BetaTesting Testing when development and testing are essentially completed and final bugs, problems need to be found before the final release. Beta Testing is typically done by end-users or others, not by programmers or testers RegressionTesting The objective of regression testing is to ensure software remains intact. A baseline set of data and scripts will be maintained and executed to verify changes introduced during the release have not undone any previous code. Expected results from the baseline are compared to results of the software being regression tested. All discrepancies will be highlighted and accounted for, before testing proceeds to the next level not by programmers or testers criteria

SystemTesting Upon completion of integration testing, the Test Team will begin system testing. During system testing, which is a black box test, the complete system is configured in a controlled environment to validate its accuracy and completeness in performing the functions as designed. The system test will simulate production in that it will occur in the production-like

test environment and test all of the functions of the system that will be required in production. The Test Team will complete the system test. Prior to the system test, the unit and integration test results will be reviewed by SQA to ensure all problems have been resolved. It is important for higher level testing efforts to understand unresolved problems from the lower testing levels. System testing is deemed complete when actual results and expected results are either in line or differences are explainable/acceptable based on client input Testing Parallel/Audit system to verify the new

Testing where the user reconciles the output of the new system to the output of the current

Accessibility Testing
The testing which determines the ease of usage of any system or software by end users with disabilities is known as accessibility testing.

Ad-hoc Testing
Ad-hoc testing is not carried out formally, there is no formal documentation, no test preparation, no test design techniques used and end results are also not expected.

Agile Testing
Testing done for the projects which is using agile development methodologies like Xtreme Programming(XP) and following test first design paradigm is known as agile testing. In agile testing test driven development is followed in which the development is considered as a customer of testing.

Mutation Testing or Back to Back Testing

In back to back testing two or more varients of the software component or system are executed with the same set of inputs and the outcome of both components is compared and checked for any discrepancies.

Big Bang Testing

It is a type of Integration Testing, in this testing the software components or hardware components or both are combined all at once to form a major component or a whole system. It does not combine components in stages as in top down or bottom up approach.

Compliance Testing

Compliance Testing tests the software for compliance with various policies like organizational policies or Industry standard policies.

Concurrency Testing
As the name suggests concurrency testing tests the concurrent operation on the software. It tests how the software will handle two or more activities at the same time interval.

Data Driven Testing

In data driven testing the test input and expected results are stored in a table or spreadsheet and a single script is executes all the test inputs in the spreadsheet.

Data Integrity Testing or Database Integrity Testing

Database integrity testing tests the processes and methods used to access database to make sure that the processes and methods work as expected and data is not corrupted, deleted, updated during the access to the database.

Documentation Testing
Documentation testing is done to test the quality of various software documentation like user guides, install guides, help etc.

Exhaustive Testing
Testing all the possible combinations of input values and preconditions is know as exhaustive testing.

Isolation Testing
In isolation testing the individual components are tested in isolation without the surrounding components and if required the surrounding components are simulated by STUB or DRIVER.

Types of Software Testing

White Box Testing White Box Testingfocuses on testing the internal working of a software component or a function, not paying much heed to the quality of output it generates. Internal characteristics of a

component are the programming and the structure associated with it. It can be executed at all three levels of testing Unit, Integration, System and System Integration. This type of testing enhances the working of the component but fails to throw light on the functional requirements missed by the programmer. It includes testing paths, branches, control flow and the data flow taking place within a component of between multiple components. Black Box Testing Black Box Testing refers to the testing of business functions, representing them as a set of input, operation and output attributes. The operation part is ignored and the focus is strongly on the generation of the quality of output in response to a particular input. Black box testing data are developed and verified as input-output pairs. This kind of testing ensures accurate results of operations. Load Testing It is important to know how the behavior of the system changes to changing load. The system must deliver uncompromised performance even in while large number of users are using the system. The load limits are informed by the customer in advance. For smooth performance of the system better algorithms and connections between different components are required. This is often referred as scalability. Regression Testing This type of testing is usually done post program code modification to ensure the older bugs have not again crept in. Errors often occur as a result of accommodating a new functionality or providing a software patch for newer versions. User Acceptance Testing User Acceptance Testing is performed by the end users of the system to check whether the system has accommodated every requirement as asked and the whether it delivers the desired performance. Alpha Testing It is more or less similar to the acceptance testing scheme. It too is done by the customers or a separate testing team which was not involved in the development phase of the software. Beta Testing It is performed post the alpha testing. It is usually the last testing phase and is done by confined groups of people outside the development team. A system in the beta testing phase is often quoted as a beta release. Incremental Integration Testing This testing scheme consists of series of tests starting with single core functionality and continuously adding other functionalities one after the other. It helps to pluck out errors related to patches or the bugs which crept in during functionality additions.