Types of Testing

Black box testing - not based on any knowledge of internal design or code. Tests are based on requirements and functionality.


White box testing - based on knowledge of the internal logic of an application's code. Tests are based on coverage of code statements, branches, paths, conditions.


Unit testing - Unit is the smallest compilable component. A unit typically is the work of one programmer.This unit is tested in isolation with the help of stubs or drivers.Typically done by the programmer and not by testers
Incremental integration testing - continuous testing of an application as new functionality is added; requires that various aspects of an application's functionality be independent enough to work separately before all parts of the program are completed, or that test drivers be developed as needed; done by programmers or by testers.Integration testing - testing of combined parts of an application to determine if they function together correctly. The 'parts' can be 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 - black-box testing aimed to validate to functional requirements of an application; this type of testing should be done by testers.
System testing - 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 but involves testing of the application in a environment that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate. Even the transactions performed mimics the end users usage of the application.
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.
Smoke testing - The general definition (related to Hardware) of Smoke Testing is: Smoke testing is a safe harmless procedure of blowing smoke into parts of the sewer and drain lines to detect sources of unwanted leaks and sources of sewer odors.In relation to software, the definition is Smoke testing is non-exhaustive software testing, ascertaining that the most crucial functions of a program work, but not bothering with finer details.
Static testing - Test activities that are performed without running the software is called static testing. Static testing includes code inspections, walkthroughs, and desk checks
Dynamic testing - test activities that involve running the software are called dynamic testing.
Regression testing - Testing of a previously verified program or application following program modification for extension or correction to ensure no new defects have been introduced.Automated testing tools can be especially useful for this type of testing.
Acceptance testing - final testing based on specifications of the end-user or customer, or based on use by end-users/customers over some limited period of time.
Performance testing - Validates that both the online response time and batch run times meet the defined performance requirements.Usability testing - testing for 'user-friendliness'. Clearly this is subjective, and will depend on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers.
Install/uninstall testing - testing of full, partial, or upgrade install/uninstall processes.
Recovery testing - testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.
Security testing - testing how well the system protects against unauthorized internal or external access, willful damage, etc; may require sophisticated testing techniques.
Compatibility testing - testing how well software performs in a particular hardware/software/ operating system/network/etc. environment.
Exploratory testing - often taken to mean a creative, informal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it.
Ad-hoc testing - similar to exploratory testing, but often taken to mean that the testers have significant understanding of the software before testing it.
Monkey testing:-monkey testing is a testing that runs with no specific test in mind. The monkey in this case is the producer of any input data (whether that be file data, or input device data). Keep pressing some keys randomely and check whether the software fails or not.
User acceptance testing - determining if software is satisfactory to an end-user or customer.Comparison testing - comparing software weaknesses and strengths to competing products.
Alpha testing - testing of an application when development is nearing completion; minor design changes may still be made as a result of such testing. Typically done by users within the development team.
Beta testing - testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers or testers.
Mutation testing - 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
Cross browser testing - application tested with different browser for usablity testing & compatiblity testing
Concurrent testing - Multi-user testing geared towards determining the effects of accessing the same application code, module or database records. Identifies and measures the level of locking, deadlocking and use of single-threaded code and locking semaphores etc.
Negative testing - Testing the application for fail conditions,negative testing is testing the tool with improper inputs.for example entering the special characters for phone number
Load testing -Load testing is a test whose objective is to determine the maximum sustainable load the system can handle. Load is varied from a minimum (zero) to the maximum level the system can sustain without running out of resources or having, transactions suffer (application-specific) excessive delay.Stress testing - Stress testing is subjecting a system to an unreasonable load while denying it the resources (e.g., RAM, disc, mips, interrupts) needed to process that load. The idea is to stress a system to the breaking point in order to find bugs that will make that break potentially harmful. The system is not expected to process the overload without adequate resources, but to behave (e.g., fail) in a decent manner (e.g., not corrupting or losing data). The load (incoming transaction stream) in stress testing is often deliberately distorted so as to force the system into resource depletion.

Testing Vocabulary

Every profession has its own vocabulary. To learn a profession, the first and crucial step is to master its vocabulary. The entire knowledge of a profession is compressed and kept it in its vocabulary.Take our own software testing profession, while communicating with our colleagues, we frequently use terms like 'regression testing', 'System testing', now imagine communicating the same to a person who is not in our profession or who doesn't understand our testing vocabulary, we need to explain in detail each and every term .Communication becomes so difficult and painful. To speak the language of testing, you need to learn its vocabulary.

Find below a huge collection of testing vocabulary

What is quality? or Define quality?

Lot of quality pioneers defined quality in different ways
A quality product is defined as the one that meets product requirements But Quality can only be seen through customer eyes. So the most important definition of quality is meeting customer needs or Understanding customer requirements, expectations and exceeding those expectations. Customer must be satisfied by using the product, then its a quality product.

Affinity Diagram: A group process that takes large amounts of language data, such as developing by brainstorming, and divides it into categories

Audit: This is an inspection/assessment activity that verifies compliance with plans, policies and procedures and ensures that resources are conserved.

Baseline:A quantitative measure of the current level of performance.

Benchmarking: Comparing your company's products, services or processes against best practices or competitive practices, to help define superior performance of a product,service or support processes.

Black-box Testing: A test technique that focuses on testing the functionality of the program component or application against its specifications without knowlegde of how the system constructed.

Boundary value analysis: A data selection technique in which test data is chosen from the "boundaries" of the input or output domain classes, data structures and procedure parameters. Choices often include the actual minimum and maximum boundary values, the maximum value plus or minus one and the minimum value plus or minus one.

Branch Testing: A test method that requires that each possible branch on each decision be executed on at least once.Brainstorming: A group process for generating creative and diverse ideas.

Bug: A catchall term for all software defects or errors.

Certification testing: Acceptance of software by an authorized agent after the software has been validated by the agent or after its validity has been demonstrated to the agent.

Checkpoint(or verification point): Expected behaviour of the application which must be validated with the actual behaviour after certain action has been performed on the application.

Client: The customer that pays for the product received and receives the benefit from the use of the product.

Condition Coverage: A white-box testing technique that measures the number of or percentage of decision outcomes covered by the test cases designed.100% condition coverage would indicate that every possible outcome of each decision had been executed at least once during testing.

Configuration Management Tools Tools that are used to keep track of changes made to systems and all related artifacts. These are also known as version control tools.

Configuration testing: Testing of an application on all supported hardware and software platforms.This may include various combinations of hardware types, configuration settings and software versions.

Completeness: A product is said to be complete if it has met all requirements.

Consistency: Adherence to a given set of rules.

Correctness: The extent to which software is free from design and coding defects. It is also the extent to which software meets the specified requirements and user objectives.

Cost of Quality: Money spent above and beyond expected production costs to ensure that the product the customer receives is a quality product. The cost of quality includes prevention, appraisal, and correction or repair costs.

Conversion Testing: Validates the effectiveness of data conversion processes, including field-field mapping and data translation.

Customer: The individual or organization, internal or external to the producing organization that receives the product.

Cyclomatic complexity: The number of decision statements plus one.

Debugging: The process of analysing and correcting syntactic, logic and other errors identified during testing.

Decision Coverage: A white-box testing technique that measures the number of - or percentage - of decision directions executed by the test case designed. 100% Decision coverage would indicate that all decision directions had been executed at least once during testing. Alternatively each logical path through the program can be tested.

Decision Table A tool for documenting the unique combinations of conditions and associated results in order to derive unique test cases for validation testing.

Defect Tracking Tools Tools for documenting defects as they are found during testing and fortracking their status through to resolution.

Desk Check: A verification technique conducted by the author of the artifcat to verify the completeness of their own work. This technique does not involve anyone else.

Dynamic Analysis: Analysis performed by executing the program code.Dynamic analysis executes or simulates a development phase product and it detects errors by analyzing the response of the product to sets of input data.

Entrance Criteria: Required conditions and standards for work product quality that must be present or met for entry into the next stage of the software development process.

Equivalence Partitioning: A test technique that utilizes a subset of data that is representative of a larger class. This is done in place of undertaking exhaustive testing of each value of the larger class of data.

Error or defect: 1.A discrepancy between a computed, observed or measured value or condition and the true, specified or theortically correct value or conditon 2.Human action that results in software containing a fault (e.g., omission or misinterpretation of user requirements in a software specification, incorrect translation or omission of a requirement in the design specification)

Error Guessing: Test data selection techniques for picking values that seem likely to cause defects. This technique is based upon the theory that test cases and test data can be developed based on intuition and experience of the tester.

Exhaustive Testing: Executing the program through all possible combination of values for program variables.

Exit criteria: Standards for work product quality which block the promotion of incomplete or defective work products to subsequent stages of the software development process.

Flowchart Pictorial representations of data flow and computer logic. It is frequentlyeasier to understand and assess the structure and logic of an application system by developing a flow chart than to attempt to understand narrative descriptions or verbal explanations. The flowcharts for systems are normally developed manually, while flowcharts of programs can be produced.

Force Field Analysis A group technique used to identify both driving and restraining forces thatinfluence a current situation.

Formal Analysis Technique that uses rigorous mathematical techniques to analyze thealgorithms of a solution for numerical properties, efficiency, and correctness.

Functional Testing Testing that ensures all functional requirements are met without regard to the final program structure

Histogram A graphical description of individually measured values in a data set that is organized according to the frequency or relative frequency of occurrence. A histogram illustrates the shape of the distribution of individual values in a data set along with information regarding the average and variation.

Inspection A formal assessment of a work product conducted by one or more qualified independent reviewers to detect defects, violations of development standards, and other problems. Inspections involve authors only when specific questions concerning deliverables exist. An inspection identifies defects, but does not attempt to correct them. Authors take corrective actions and arrange follow-up reviews as needed.

Integration Testing This test begins after two or more programs or application components have been successfully unit tested. It is conducted by the development team to validate the interaction or communication/flow of information between the individual components which will be integrated.

Life Cycle Testing The process of verifying the consistency, completeness, and correctness of software at each stage of the development life cycle.

Pass/Fail Criteria Decision rules used to determine whether a software item or feature passes or fails a test.

Path Testing A test method satisfying the coverage criteria that each logical path through the program be tested. Often, paths through the program are grouped into a finite set of classes and one path from each class is tested.

Performance Test Validates that both the online response time and batch run times meet thedefined performance requirements.

Policy Managerial desires and intents concerning either process (intended objectives) or products (desired attributes).

Population Analysis Analyzes production data to identify, independent from the specifications, the types and frequency of data that the system will have to process/produce. This verifies that the specs can handle types and frequency of actual data and can be used to create validation tests.

Procedure The step-by-step method followed to ensure that standards are met.

Process1. The work effort that produces a product. This includes efforts of people and equipment guided by policies, standards, and procedures.2. A statement of purpose and an essential set of practices (activities) that address that purpose.

Proof of Correctness The use of mathematical logic techniques to show that a relationship between program variables assumed true at program entry implies that another relationship between program variables holds at program exit.

Quality A product is a quality product if it is defect free. To the producer, a product is a quality product if it meets or conforms to the statement of requirements that defines the product. This statement is usually shortened to: quality means meets requirements. From a customer’s perspective, quality means “fit for use.”

Quality Assurance (QA) Deals with 'prevention' of defects in the product being developed.It is associated with a process.The set of support activities (including facilitation, training, measurement, and analysis) needed to provide adequate confidence that processes are established and continuously improved to produce products that meet specifications andare fit for use.

Quality Control (QC) Its focus is defect detection and removal. Testing is a quality control activity

Quality Improvement To change a production process so that the rate at which defective products (defects) are produced is reduced. Some process changes may require the product to be changed

Recovery Test Evaluates the contingency features built into the application for handlinginterruptions and for returning to specific points in the application processing cycle, including checkpoints, backups, restores, and restarts. This test also assures that disaster recovery is possible.

Regression Testing Testing of a previously verified program or application following programmodification for extension or correction to ensure no new defects have been introduced.

Risk Matrix Shows the controls within application systems used to reduce the identified risk, and in what segment of the application those risks exist. One dimension of the matrix is the risk, the second dimension is the segment of the application system, and within the matrix at the intersections are the controls. For example, if a risk is “incorrect input” and the systems segment is “data entry,” then the intersection within the matrix would show the controls designed to reduce the risk of incorrect input during the data entry segment of the application system.

Scatter Plot Diagram A graph designed to show whether there is a relationship between twochanging variables.

Standards The measure used to evaluate products and identify nonconformance. The basis upon which adherence to policies is measured.

Statement of Requirements The exhaustive list of requirements that define a product.

Statement Testing A test method that executes each statement in a program at least once during program testing.

Static Analysis Analysis of a program that is performed without executing the program. Itmay be applied to the requirements, design, or code.

Stress Testing This test subjects a system, or components of a system, to varyingenvironmental conditions that defy normal expectations. For example, high transaction volume, large database size or restart/recovery circumstances. The intention of stress testing is to identify constraints and to ensure that there are no performance problems.

Structural Testing A testing method in which the test data is derived solely from the program structure.

Stub Special code segments that when invoked by a code segment under testing, simulate the behavior of designed and specified modules not yet constructed.

System Test During this event, the entire system is tested to verify that all functional,information, structural and quality requirements have been met.

Test Case Test cases document the input, expected results, andexecution conditions of a given test item.

Test Plan A document describing the intended scope, approach, resources, and schedule of testing activities. It identifies test items, the features to be tested, the testing tasks, the personnel performing each task, and any risks requiring contingency planning.

Test Scripts A tool that specifies an order of actions that should be performed during a test session. The script also contains expected results. Test scripts may be manually prepared using paper forms, or may be automated usingcapture/playback tools or other kinds of automated scripting tools.

Test Suite Manager A tool that allows testers to organize test scripts by function or other grouping.

Unit Test Testing individual programs, modules, or components to demonstrate that the work package executes per specification, and validate the design and technical quality of the application. The focus is on ensuring that the detailed logic within the component is accurate and reliable according to pre-determined specifications. Testing stubs or drivers may be used to simulate behavior of interfacing modules.

Usability Test The purpose of this event is to review the application user interface and other human factors of the application with the people who will be using the application. This is to ensure that the design (layout and sequence, etc.) enables the business functions to be executed as easily and intuitively as possible. This review includes assuring that the user interface adheres to documented User Interface standards, and should be conducted early in the design stage of development. Ideally, an application prototype is used to walk the client group through various business scenarios, although paper copies of screens, windows, menus, and reports can be used.

User Acceptance Test User Acceptance Testing (UAT) is conducted to ensure that the system meets the needs of the organization and the end user/customer. It validates that the system will work as intended by the user in the real world, and is based on real world business scenarios, not system requirements. Essentially, this test validates that the right system was built.

Validation Determination of the correctness of the final program or software produced from a development project with respect to the user needs and requirements.

Verification1. The process of determining whether the products of a given phase of the software development cycle fulfill the requirements established during the previous phase.2. The act of reviewing, inspecting, testing, checking, auditing, or otherwise establishing and documenting whether items, processes, services, or documents conform to specified requirements.

Walkthroughs During a walkthrough, the producer of a product “walks through” orparaphrases the products content, while a team of other individuals follow along. The team’s job is to ask questions and raise issues about the product that may lead to defect identification.

White-box Testing A testing technique that assumes that the path of the logic in a program unit or component is known. White-box testing usually consists of testing paths, branch by branch, to produce predictable results. This technique is usually used during tests executed by the development team, such as Unit or Component testing