Usability testing is a testing methodology where the end customer is asked to use the software to see if the product is easy to use, to see the customer’s perception and task time. The best way to finalize the customer point of view for usability is by using prototype or mock-up software during the initial stages. By giving the customer the prototype before the development start-up we confirm that we are not missing anything from the user point of view.

There are three main categories of defects:

1. Wrong: The requirements have been implemented incorrectly. This defect is a variance from the given specification.
2. Missing: There was a requirement given by the customer and it was not done. This is a variance from the specifications, an indication that a specification was not implemented, or a requirement of the customer was not noted properly.
3. Extra: A requirement incorporated into the product that was not given by the end customer. This is always a variance from the specification, but may be an attribute desired by the user of the product. However, it is considered a defect because it’s a variance from the existing requirements.

In any project the acceptance document is normally prepared using the following inputs. This can vary from company to company and from project to project.
1.Requirement document: This document specifies what exactly is needed in the project from the customers perspective.
2.Input from customer: This can be discussions, informal talks, emails, etc.
3. Project plan: The project plan prepared by the project manager also serves as good input to finalize your acceptance test.

In real projects, tailored models are proven to be the best, because they share features from The Waterfall, Iterative, Evolutionary models, etc., and can fit into real life time projects. Tailored models are most productive and beneficial for many organizations. If it’s a pure testing project, then the V model is the best.

The design phase is more error prone than the execution phase. One of the most frequent defects which occur during design is that the product does not cover the complete requirements of the customer. Second is wrong or bad architecture and technical decisions make the next phase, execution, more prone to defects. Because the design phase drives the execution phase it’s the most critical phase to test. The testing of the design phase can be done by good review. On average, 60% of defects occur during design and 40% during the execution phase.

No an increase in testing does not always mean improvement of the product, company, or project. In real test scenarios only 20% of test plans are critical from a business angle. Running those critical test plans will assure that the testing is properly done. The following graph explains the impact of under testing and over testing. If you under test a system the number of defects will increase, but if you over test a system your cost of testing will increase. Even if your defects come down your cost of testing has gone up.

Verification is static type of s/w testing. It means code is not executed. The product is evaluated by going through the code. Types of verification are:
1. Walkthrough: Walkthroughs are informal, initiated by the author of the s/w product to a colleague for assistance in locating defects or suggestions for improvements. They are usually unplanned. Author explains the product; colleague comes out with observations and author notes down relevant points and takes corrective actions.
2. Inspection: Inspection is a thorough word-by-word checking of a software product with the intention of Locating defects, Confirming traceability of relevant requirements etc.

Unit testing – Testing performed on a single, stand-alone module or unit of code.
Integration Tests – Testing performed on groups of modules to ensure that data and control are passed properly between modules.
System testing – Testing a predetermined combination of tests that, when executed successfully meets requirements.
Acceptance testing – Testing to ensure that the system meets the needs of the organization and the end user or customer (i.e., validates that the right system was built).

Verification is a review without actually executing the process while validation is checking the product with actual execution. For instance, code review and syntax check is verification while actually running the product and checking the results is validation.

It includes tracing the accuracy of the devices used in the production, development and testing. Devices used must be maintained and calibrated to ensure that it is working in good order.

Alpha and beta testing has different meanings to different people. Alpha testing is the acceptance testing done at the development site. Some organizations have a different visualization of alpha testing. They consider alpha testing as testing which is conducted on early, unstable versions of software. On the contrary beta testing is acceptance testing conducted at the customer end.
In short, the difference between beta testing and alpha testing is the location where the tests are done.

The difference between pilot and beta testing is that pilot testing is nothing but actually using the product (limited to some users) and in beta testing we do not input real data, but it’s installed at the end customer to validate if the product can be used in production.

There are four major ways of rolling out any project:
Pilot: The actual production system is installed at a single or limited number of users. Pilot basically means that the product is actually rolled out to limited users for real work.
Gradual Implementation: In this implementation we ship the entire product to the limited users or all users at the customer end. Here, the developers get instant feedback from the recipients which allow them to make changes before the product is available. But the downside is that developers and testers maintain more than one version at one time.
Parallel Implementation: In these types of rollouts the existing application is run side by side with the new application. If there are any issues with the new application we again move back to the old application. One of the biggest problems with parallel implementation is we need extra hardware, software, and resources.

Acceptance testing checks the system against the “Requirements.” It is similar to System testing in that the whole system is checked but the important difference is the change in focus:
System testing checks that the system that was specified has been delivered. Acceptance testing checks that the system will deliver what was requested. The customer should always do Acceptance testing and not the developer.
The customer knows what is required from the system to achieve value in the business and is the only person qualified to make that judgement. This testing is more about ensuring that the software is delivered as defined by the customer. It’s like getting a green light from the customer that the software meets expectations and is ready to be used.