Quality software is reasonably bug/defect-free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable.

Verification typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. This can be done with checklists, issues lists, walkthroughs, and inspection meetings. Validation typically involves actual testing and takes place after verifications are completed. Both validation and verification process continue in a cycle till the software becomes defect free (Validation --> Reporting --> Fixing (and enhancements) --> Verification).

An inspection is more formalized than a 'walkthrough', typically with 3-8 people including a moderator, reader (the author of whatever is being reviewed), and a recorder to take notes. The subject of the inspection is typically a document such as a requirements spec or a test plan, and the purpose is to find problems and see what's missing, not to fix anything.

Software QA involves the entire software development PROCESS - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to 'prevention'
Testing involves operation of a system or application under controlled conditions and evaluating the results (eg, 'if the user is in interface A of the application while using hardware B, and does C, then D should happen'). The controlled conditions should include both normal and abnormal conditions. Testing should intentionally attempt to make things go wrong to determine if things happen when they shouldn't or things don't happen when they should. It is oriented to 'detection'.

• Obtain requirements, functional design, and internal design specifications and other necessary documents
• Obtain schedule requirements
• Determine project-related personnel and their responsibilities, reporting requirements, required standards and processes (such as release processes, change processes, etc.)
• Identify application's higher-risk aspects, set priorities, and determine scope and limitations of tests
• Determine test approaches and methods - unit, integration, functional, system, load, usability tests, etc.
• Determine test environment requirements (hardware, software, communications, etc.)
• Determine testware requirements (record/playback tools, coverage analyzers, test tracking, problem/bug tracking, etc.)
• Determine test input data requirements
• Identify tasks, those responsible for tasks
• Set schedule estimates, timelines, milestones
• Determine input equivalence classes, boundary value analyses, error classes
• Prepare test plan document and have needed reviews/approvals
• Write test cases
• Have needed reviews/inspections/approvals of test cases
• Prepare test environment and testware, obtain needed user manuals/reference documents/configuration guides/installation guides, set up test tracking processes, set up logging and archiving processes, set up or obtain test input data
• Obtain and install software releases
• Perform tests
• Evaluate and report results
• Track problems/bugs and fixes
• Retest as needed
• Maintain and update test plans, test cases, test environment, and testware through life cycle

The most 'micro' scale of testing; to test particular functions or code modules. Typically done by the programmer and some times by testers, as it requires detailed knowledge of the internal program design and code. Not always easily done unless the application has a well-designed architecture with tight code; may require developing test driver modules or test harnesses.

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. It is not truly system testing because the components are not implemented in the operating environment. This type of testing is especially relevant to client/server and distributed systems.
During the integration testing, the units or components can be assembled using 2 approaches:
Nonincremental integration - "big bang" approach
Disadvantage - When failure  occurs, it is very difficult to locate the faults. After the modification, we have to go through the testing, locating faults, modifying faults again.
Incremental integration
Incremental Integration can be top-down or bottom-up:
Top-down testing starts with main and successively replaces stubs with the real modules.
Major steps:
1.The main control module is used as a test driver and stubs are substituted for all component directly subordinate to the main module.
2.depending on integration approach, subordinate stubs are replaced once a time with actual components.
3.Tests are conducted as each component is integrated.
4.When failures are encountered, locate faults, and perform regression testing to guarantee the modification won't adversely affected other pieces. Then go through 2 ,3, 4 again
Advantages: can verify major control or decision point early in the testing process.
Disadvantages: Stubs are required when perform the integration testing, and generally, develop stubs in very difficulties.

Bottom-up testing builds larger module assemblies from primitive modules.
Major steps
1.Low-level components are combined into clusters which performs a specific subfunction.
2.A driver(a control program for testing( is written to coordinate test case input and output.
3.The cluster is tested
4.Drivers are removed and clusters are combined moving upward in the program structure.
Advantages: Stubs are substituted by drivers, which are much easier to be developed.
Disadvantages: Major control and decision problem will be identified later in the testing process.
Sandwich testing is mainly top-down with bottom-up integration and testing applied to certain widely used components

The system test phase begins once modules are integrated enough to perform tests in a whole system environment.  System testing can occur in parallel with integration test, especially with the top-down method.

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.


Types of 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.

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.

Testing how well software performs in a particular hardware/software/operating system/network/etc. environment.

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.

Similar to exploratory testing, but often taken to mean that the testers have significant understanding of the software before testing it.

Comparing software weaknesses and strengths to competing products.

Testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system's response time degrades or fails.

Black-box type testing that is based on overall requirements specifications; covers all combined parts of a system.

Black-box type testing geared to functional requirements of an application; this type of testing should be done by testers. This doesn't mean that the programmers shouldn't check that their code works before releasing it (which of course applies to any stage of testing.)

Volume testing involves testing the software or Web application using corner cases of "task size" or input data size. The exact volume tests performed depend on the application's functionality, its input and output mechanisms and the technologies used to build the application. Sample volume testing considerations include, but are not limited to:
If the application reads text files as inputs, try feeding it both an empty text file and a huge (hundreds of megabytes) text file
If the application stores data in a database, exercise the application’s functions when the database is empty and when the database contains an extreme amount of data
If the application is designed to handle 100 concurrent requests, send 100 requests simultaneously and then send the 101st request
If a Web application has a form with dozens of text fields that allow a user to enter text strings of unlimited length, try populating all of the fields with a large amount of text and submit the form

Term often used interchangeably with 'load' and 'performance' testing. Also used to describe such tests as system functional testing while under unusually heavy loads, heavy repetition of certain actions or inputs, input of large numerical values, large complex queries to a database system, etc.

This means that you test an application in its normal environment, along with other standard applications, to make sure they all get along together; that is, that they don't corrupt each other's files, they don't crash, they don't consume system resources, they don't lock up the system, they can share the printer peacefully, etc.

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.

Testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.

Testing how well the system protects against unauthorized internal or external access, willful damage, etc; may require sophisticated testing techniques.

Term often used interchangeably with 'stress' and 'load' testing. Ideally 'performance' testing (and any other 'type' of testing) is defined in requirements documentation or QA or Test Plans.

Similar to system testing; the 'macro' end of the test scale; 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.

Re-testing after fixes or modifications of the software or its environment. It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle. Automated testing tools can be especially useful for this type of testing.

With parallel testing, users can easily choose to run batch tests or asynchronous tests depending on the needs of their test systems. Testing multiple units in parallel increases test throughput and lower the manufacturer's cost.

Testing of full, partial, or upgrade install/uninstall processes.

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.

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 end-users or others, not by programmers or testers.

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.