Software testing best practices

The objective of testing is to ensure a higher quality for the software product. The better organized the testing is, the more the likelihood that the final product will have fewer defects and better quality. But it is not an easy task to determine how effective the testing is. One way to do that is to benchmark against some best practices, such as the ones being listed below:
These best practices can be broken down into levels, with benchmarking starting at the lowest levels, and after meeting these levels, moving to higher levels. At the end, if there is an impression that you are meeting most of these benchmarks, then there is a higher chance that you will have a very effective testing setup.

Start at the basic level:

• Start with functional Specifications
• ŸReviews and Inspection
• ŸFormal entry and exit criteria
• ŸFunctional test - variations
• ŸMulti-platform testing
• ŸInternal Betas
• ŸAutomated test execution
• ŸBeta programs
• ŸDaily Builds

Functional specification: Enables the quality process of test plan and cases to start as the development process is underway. Further, involvement with the functional specifications deepens the understanding regarding customer workflows. Without functional specifications, the degree of thoroughness required is missing.

Reviews: Software inspection is a very well know efficient technique for debugging code.

Formal entry and exit criteria: Defining a criteria for every step may seem excessive, but it creates a mindset that has already thought through the beginning and end steps for many stages and milestones, and makes declaring milestones a lot easier, with agreement between the Dev and QE teams.

Functional test - variations: This involves varying the sets of input conditions to achieve different output conditions. If this is done in a comprehensive way, then the blackbox testing is said to be close to complete.

Multiple platform testing: Nowadays softwares are available on multiple platforms, and porting from one platform to another results in some changes. It is necessary to define a strategy to figure out the level of testing required across multiple platforms.

Internal Betas: External betas relate to sending software with a certain quality level to testers outside the company. However, if the software development company has a certain size, it can even send the software to its internal folks, providing a good beta testing platform.

Automated test execution: Automation is an integral part of testing processes. Automation can convert replace a fair amount of the manual testing required. In addition, with automation, repetitive testing of software becomes much easier. For example, if you have daily builds, automation can be used to setup a series of test cases that will determine whether the build is usable or not, without human intervention.

Beta Programs: These are a very efficient method of ensuring that there is a wide section of users available to test. They are as close to end users as possible, and provide feedback in terms of functionality, and also a wide coverage. A good example is for a software used for CD / DVD writing, where beta testing will provide coverage on a large number of burning devices, not possible with the testing team.

Daily Builds: Getting a process of daily builds is very useful during the development process. Bugs are turned around faster, new features are available much sooner, and even if a build is not so good, the next one will be available soon. It may seem like overhead, but is very useful.