Alpha testing is an internal acceptance testing. This is
simulated or actual operational testing by users/customers
or dedicated test team at the developer's site.

Beta testing comes after alpha testing. Versions of
developed sotware called beta versions are released to
limited audience outside of the company. Sometimes these
versions are released to the public to increase feedback
fields for the future users.

Validation ensures that functionality, as defined in requirements, is the intended behavior of the product; validation typically involves actual testing and takes place after verifications are completed.

Difference between Verification and Validation:
Verification takes place before validation, and not vice versa. Verification evaluates documents, plans, code, requirements, and specifications. Validation, on the other hand, evaluates the product itself. The inputs of verification are checklists, issues lists, walkthroughs and inspection meetings, reviews and meetings. The input of validation, on the other hand, is the actual testing of an actual product. The output of verification is a nearly perfect set of documents, plans, specifications, and requirements document. The output of validation, on the other hand, is a nearly perfect, actual product.

• Smoke testing originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch fire and smoke. In software industry, smoke testing is a shallow and wide approach whereby all areas of the application without getting into too deep, is tested.
• A smoke test is scripted, either using a written set of tests or an automated test
• A Smoke test is designed to touch every part of the application in a cursory way. It’s shallow and wide.
• Smoke testing is conducted to ensure whether the most crucial functions of a program are working, but not bothering with finer details. (Such as build verification).
• Smoke testing is normal health check up to a build of an application before taking it to testing in depth.

SANITY TESTING:

• A sanity test is a narrow regression test that focuses on one or a few areas of functionality. Sanity testing is usually narrow and deep.
• A sanity test is usually unscripted.
• A Sanity test is used to determine a small section of the application is still working after a minor change.
• Sanity testing is a cursory testing, it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing.
• Sanity testing is to verify whether requirements are met or not, checking all features breadth-first.

* Quality Assurance: A set of activities designed to ensure that the development and/or maintenance process is adequate to ensure a system will meet its objectives.

* Quality Control: A set of activities designed to evaluate a developed work product.

* Testing: The process of executing a system with the intent of finding defects. (Note that the “process of executing a system” includes test planning prior to the execution of the test cases.)

QA activities ensure that the process is defined and appropriate. Methodology and standards development are examples of QA activities. A QA review would focus on the process elements of a project – e.g., are requirements being defined at the proper level of detail. In contrast, QC activities focus on finding defects in specific deliverables – e.g., are the defined requirements the right requirements. Testing is one example of a QC activity, but there are others such as inspections. Both QA and QC activities are generally required for successful software development.

Controversy can arise around who should be responsible for QA and QC activities — i.e., whether a group external to the project management structure should have responsibility for either QA or QC. The correct answer will vary depending on the situation, but Mosaic’s experience suggests that:

* While line management should have the primary responsibility for implementing the appropriate QA, QC and testing activities on a project, an external QA function can provide valuable expertise and perspective.

* The amount of external QA/QC should be a function of the project risk and the process maturity of an organization. As organizations mature, management and staff will implement the proper QA and QC approaches as a matter of habit. When this happens only minimal external guidance and review are needed.

Version number has four parts:
Major part . Minor part :-A new Major or Minor part indicates that the new version is incompatible with the old one. For example, version 2.0.0.0 should be incompatible with version 1.1.2.5.
You should change major version numbers whenever you introduce an incompatibility into your code.
Major part involves a total rewrite or rearchitecting of a software product.
Changes in language, major changes in design, and changes in platform fall into this category. This number starts at 1 (one).
Build part:-A new build part indicates probable compatibility.
Typically you should change minor version numbers when you introduce a service pack or a minor upgrade.
For example, version 1.8.0.0 is probably compatible with version 1.7.0.0.
Minor part involves additions in features that require changes in documentation/external API. This number starts at 0 (zero).
Revision part:-A new revision part indicates a QFE (Quick Fix Engineering) release that is compatible with the previous version and that should be installed. For example, version 1.6.5.13 might be a mandatory bug-fix upgrade to version 1.6.5.12.
This is any change that doesn’t require documentation/external API changes. This number starts at 0 (zero).

Setting the Version attribute to “1.0.*” tells use 1 for the major part, 0 for the minor part, and to come up with build and revision part numbers automatically. You can also specify all four parts of the version number explicitly:
All version numbering is based on external view. Meaning, this is a number scheme that intended to reflect the release of a product, not the internal production. Thus, recompilation does not effect the version number.
The terms “alpha” and “beta” shall not be used in the version number.
These terms reflect little these days and aren’t qualitative (i.e. “1.0.0″ sorts before “1.0.0 alpha”, but should sort after).

ii) Demonstration
Having the customer or a representative use the product to ensure it meets some minimum constraints (i.e., usability). Also can be used to perform some acceptance tests where the product is running in the intended environment versus some test or development lab. For example: Having pilots fly an aircraft before the customer signs off on the program.
iii) Analysis
Using some form of analysis to validate that the product will perform as needed when demonstrating it is too costly, unsafe, or generally impractical. For example: Using interpolation of performance load based on the worst case, that is feasible to generate, to validate a need that is more stringent than this worst case. If it can be shown that there is no scaling problem, this would be sufficient to validate the performance need.
iv) Prior data
When a component being used has been already validated for a previous project that had similar or stricter constraints. For example: Using a well-known encryption component to meet security needs when the component has been already validated for tougher security requirements.
Early validation
Leaving validation until the end of the project severely increases the risk of failure. Validation activities early in the project can reduce that risk. Early validation activities reveal:
i) Clarifications
Perhaps the most important purpose of early validation is to clarify the real meaning of requirements. The obvious cases are where requirements are incomplete. However, the riskiest requirements are subjective. These include phrases such as “readable” or “user-friendly” or involve human interfaces in general. Early validation can get a response to various interpretations and provide more specifics in areas such as acceptable size, placement, or motion.
ii) Drivers
Some requirements are more critical to the customer than others. Some have larger cost or design impact on the product. With early validation you can uncover the customer�s priorities and relate them to the development impact to identify the serious drivers.

iii) Additions
You can use early validation to discover and coordinate new requirements during the program. An issue is that no spec is totally complete, and it is assumed that the designer has a familiarity with the intended end use environment. Particularly in a new environment that the designer is not familiar with, early validation of requirements can uncover missing requirements. Another use is to coordinate derived requirements with the customer. In this case, the need is often driven by the customer�s lack of knowledge with the technologies being applied and their impact on the use of the product.
iv) Hidden expectations:
Discussions with the customer can reveal unstated expectations or assumptions about the design. One hint is extreme detail in the requirements that may be surrogate for “I want it to work like the old or another system.”
Various approaches to early validation include:
Very early validation of requirements closely parallels good requirements elicitation and analysis. Techniques for doing this include involving the user, site visits, or goal-based use cases.

Levels of Verification
There are four levels of verification:
i) Component Testing
Testing conducted to verify the implementation of the design for one software element (unit, module) or a collection of software elements.
ii) Integration Testing
An orderly progression of testing in which various software elements and/or hardware elements are integrated together and tested. This testing proceeds until the entire system has been integrated.
iii) System Testing
The process of testing an integrated hardware and software system to verify that the system meets its specified requirements.
iv) Acceptance Testing
Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system.

Types of Verification
There are four types of verification that can be applied to the various levels outlined above:
i) Inspection
Typical techniques include desk checking, walkthroughs, software reviews, technical reviews, and formal inspections (e.g., Fagan approach).
ii) Analysis
Mathematical verification of the test item, which can include estimation of execution times and estimation of system resources.
iii) Testing
Also known as “white box” or “logic driven” testing. Given input values are traced through the test item to assure that they generate the expected output values, with the expected intermediate values along the way. Typical techniques include statement coverage, condition coverage, and decision coverage.
iv) Demonstration
Also known as “black box” or “input/output driven” testing. Given input values are entered, and the resulting output values are compared against the expected output values. Typical techniques include error guessing, boundary-value analysis, and equivalence partitioning.
Explanation
The four methods for verification can be used at any of the levels although some work better than others for a given level of verification.
As an example, the most effective way to find anomalies at the component level is inspection. On the other hand, inspection is not applicable at the system level (you don’t look at the details of code when performing system level testing).
A logical approach to testing is to utilize techniques and methods that are most effective at a given level.
Component level verification can easily get very expensive.
Companies need to avoid making statements like “all paths and branches will be executed during component testing.”
These statements make for a very expensive test program, as all code developed is required to have one of the most labor-intensive type of testing performed on it.
To minimize the costs of component verification, the V&V group develops rules for determining the type of verification method(s) needed for each of the software functions.
As an example, very low complexity software function, which is not on the safety critical list, may only need informal inspection (walkthrough) performed.
Other complicated functions typically require white box testing since the functions become difficult to determine how they work.
We recommend performing inspections before doing the white box testing for a given module as it is less expensive to find the errors earlier in the development.
The resulting V&V effort has become a significant part of the software development effort for a medical device.
One of the key pieces to demonstrate that the system is implemented completely is a Requirements Traceability Matrix (RTM), which documents each of the requirements traced to design items, code, unit, integration and system test cases.
The RTM is an easy and effective way for documenting – what are the requirements, where are they implemented, and how have you tested them.

Inspections and walkthroughs concentrate on assessing correctness.  Reviews seek to ascertain that tolerable levels of quality are being attained.  The review team is more concerned with design deficiencies and deviations from the conceptual model and M&S requirements than it is with the intricate line-by-line details of the implementation.  The focus of a review is not on discovering technical flaws but on ensuring that the design and development fully and accurately address the needs of the application.  For this reason, the review process is effective early on during requirements verification and conceptual model validation.  [Hollocker, 1987; Perry, 1995; Sommerville, 1996; Whitner and Balci, 1989].

• Coordinator, often the V&V Agent, who organizes, moderates, and follows up the walkthrough activities
• Presenter, usually the Developer
• Recorder
• Maintenance oracle, who focuses on long-term implications
• Standards bearer, who assesses adherence to standards
• Accreditation Agent, who reflects the needs and concerns of the User
• Additional reviewers such as the M&S PM and auditors

Except for the Developer, none of the team members should be involved directly in the development effort.  [Adrion et al., 1982; Deutsch, 1982; Myers, 1978, 1979; Yourdon, 1985].