Like other areas in computing the world of quality assurance contains a considerable amount of technical jargon and buzz words. This article is an attempt to provide brief definitions of various types of testing that is done by our organization. It is meant to serve as a reference for ourselves as well as our customers.

1. Acceptance testing:
This type of testing is normally performed to validate the software and ensure that it meets a set of agreed acceptance criteria.

2. Accessibility testing:
This testing is conducted to verify that the software in question is accessible to the intended target audience. This kind of testing is especially useful when the target audience includes people that have disabilities.

3. Ad Hoc Testing:
This is a testing phase where the tester tries to break the system by randomly trying the system’s functionality. It can include negative testing as well.

4. Agile Testing:
We apply agile testing practices for projects using agile methodologies; we treat development as a customer of testing and emphasize a test first design paradigm.

5. Basis Path Testing:
This is a white box test case design technique that uses algorithmic flow of the program to design tests.

6. Beta Testing:
This is a test of the software that is conducted by its actual customers. At the end of this testing their feedback is logged and relevant actions are taken by all the stakeholders involved.

7. Binary Portability Testing:
Our QA department performs this testing on executable applications for portability across system platforms and environments, usually for conformation to an application binary interface specification.

8. Black Box Testing:
Testing based on analysis of the specification of a piece of software without reference to its internal workings. The goal is to test how well the component conforms to the published requirements for the component.

9. Bottom Up Testing:
This is an approach for conducting integration testing where the lowest level components are tested first, then used to facilitate the testing of higher level components. The process is repeated until the component at the top of the hierarchy is tested.

10. Boundary testing:
These are tests that focus on the boundary or limit conditions of the software being tested, some of these tests can also be considered as stress tests.

11. Branch testing:
This is a form of testing in which all branches in the program source code are tested at least once.

12. Breadth Testing:
This consists of a test suite that spans the entire functionality of the software but does not test each feature in detail.

13. Compatibility Testing:
This is testing to ascertain a software’s ability to run with other elements of a system with which it should operate e.g. Browsers, operating systems or hardware.

14. Component Testing:
Testing of individual software components (Unit testing).

15. Concurrency Testing:
This is multiuser testing geared towards determining the effects of accessing the same application code, module or database records. It identifies and measures the level of locking, deadlocking, and use of single threaded code and locking semaphores.

16. Conformance Testing:
The process of testing that an implementation conforms to the specification on which it is based. Usually applied to the tested conformance to formal standards.

17. Context Driven Testing:
The context-driven school of software testing is a flavor of agile testing that advocates continuous and creative evaluation of testing opportunities in light of the potential information revealed, and the value of that information to the organization right now.

18. Conversion Testing:
Testing of programs or procedures used to convert data from the existing system for use in replacement systems.

19. Data Driven Testing:
Testing in which the action of test case is parameterized by externally defined data values, maintained as a file or spreadsheet. It’s a common technique in automated testing.

20. Dependency Testing:
Examine an application’s requirements for pre-existing software, initial states and configuration in order to maintain proper functionality.

21. Depth Testing:
Testing that exercises a feature of a software in full detail.

22. Dynamic Testing:
Testing software by actually using it.

23. End to End Testing:
Testing a complete application environment in a situation that mimics real word use, such as interacting with a database, using network communications, or interaction with other hardware, applications or systems if appropriate.

24. Exhaustive Testing:
Testing which covers all combination of input values and preconditions for an element of the software under test.

25. Gorilla Testing:
Testing a particular module’s functionality intensively.

26. Gray Box Testing:
A combination of black box and white box testing methodologies; testing a piece of software against its specification but using some knowledge of its internal working.

27. Integration Testing:
Testing of combined parts of an application to determine if they function together correctly. Usually performed after unit and functional testing. This type of testing is especially relevant to client/server and distributed systems.

28. Installation Testing:
Testing that confirms that the application under test recovers from expected or unexpected without loss of data and functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions.

29. Localization Testing:
This term refers to making software especially designed for a specific locality.

30. Loop Testing:
A White box testing technique that exercises program loops.

31. Monkey Testing:
Testing a system or an application on the fly, i.e. just a few tests here and there to ensure that a system or an application does not crash out.

32. Negative Testing:
Testing aimed at showing that the software does not work, also known as ‘test to fail’.

33. Performance Testing:
Testing conducted to evaluate the compliance of a system or component with specified performance requirements. Often this is performed using automation testing tools to simulate large number of users and checking the result.

34. Ramp Testing:
Continuously raising input signals until the system breaks down.

35. Recovery Testing:
This confirms that the program recovers from expected or unexpected events without loss of data or functionality. Such events can include shortage of disk space, unexpected loss of communication etc.

36. Sanity Testing:
Brief testing of the major functional elements of a piece of software to determine if it’s operational.

37. Scalability Testing:
Performance testing focused on ensuring that the application under test gracefully handles increase in the work load.

38. Security Testing:
Testing which confirms that the program can restrict access to authorized personnel and that the authorized personnel can access the functions available to their security level.

39. Smoke Testing:
A quick and dirty test to check if the major functions of a piece of software work. Originated in hardware testing practice when turning on a new piece of hardware for the first time and considering it a success if it does not catch fire.

40. Soak Testing:
Running a system at high load for a prolonged time.

41. Static Testing:
Analysis of program carried out without executing the program.

42. Unit Testing:
Test of individual software components.

43. Validation Testing:
The process of evaluating the software at the end of the software development process to ensure compliance with the software requirements. The techniques of validation are testing, inspection and reviewing.

44. Verification Testing:
Testing done by walk through, inspections, meetings, requirement checklists, and traceability that whether it is going to meet the requirements or not.

45. Work Flow Testing:
Scripted end to end testing which duplicates specific work flows which are expected to be utilized by the end user.