1. Formal Technical Review in Software Testing
A formal technical review is conducted by the software quality assurance group. A review typically examines only a small part of the software project. Also, only one developer is usually responsible for the artifact.
The artifact is examined on various levels, the first of which is for compliance with the requirements of the software. This includes things like function and logic as well as implementation.
The artifact must also conform to the standards of the process used on the project. This ensures that all artifacts of the project are developed in a uniform manner.
Typically a review will last 2 hours. The review may consist of walk-throughs, code inspections or any other examination. Since the purpose of a review is to find errors, a review can be difficult to control. Care must be taken to ensure that no hard feelings occur as a result.
2. Code Walkthrough in Software Testing
A source code walkthrough often is called a technical code walkthrough or a peer code review. The typical scenario finds a developer inviting his technical lead, a database administrator, and one or more peers to a meeting to review a set of source modules prior to production implementation. Often the modified code is indicated after the fact on a hardcopy listing with annotations or a highlighting pen, or within the code itself with comments.
A code walkthrough is an effective tool in the areas of quality assurance and education. The developer is exposed to alternate methods and processes as the technical lead and database administrator suggest and discuss improvements to the code. The technical lead is assured of an acceptable level of quality and the database administrator is assured of an acceptable level of database performance. The result is better performance of the developer, his programs, and the entire application.
Despite all the benefits of source code walkthroughs, few organizations implement and enforce them as a shop standard. Many excuses are given, but each has a practical solution.
3. Code Review in Software Testing
Code Reviews are a great way to improve both your software and your developers. Traditionally code reviews or peer reviews take place in a regular basis, once a week for instance. Developers swap code they produced during the week and go through a checklist to look for bugs security problems, performance issues, adherence to coding standards, and other issues. The developer then creates a report and goes over what he or she has found in the peer's code. This process allows the developers to learn the tricks other developers have attained over the years.
Traditional code reviews certainly do a lot to improve the quality of the software developed, and the developers themselves, but they certainly also take quite a bit of time. Many of the issues can be easily picked up by an automated code review tool such as CFDEV's tool for reviewing ColdFusion (CFML) code. CFDEV's tool also allows you to easily write your own rules most rules can be written in just 4 lines of CFML code. In addition each issue the reviewer find has an associated document explaining why, and how to fix the issue.
While automated code review tools can cut down the time it takes to review code, there are certain tasks that an automated tool just can't do, such as algorithm design, or logic issues. To get the full benefits of code reviews you should still involve the human eye.
4. Code Inspection in Software Testing
Software inspections have long been considered to be an effective way to detect and remove defects from software. However, there are costs associated with carrying out inspections and these costs may outweigh the expected benefits.
It is important to understand the tradeoffs between these costs and benefits. We believe that these are driven by several mechanisms, both internal and external to the inspection process. Internal factors are associated with the manner in which the steps of the inspection are organized into a process (structure), as well as the manner in which each step is carried out (technique). External ones include differences in reviewer ability and code quality (inputs), and interactions with other inspections, the project schedule, personal calendars, etc. (environment).
Most of the existing literature on inspections have discussed how to get the most benefit out of inspections by proposing changes to the process structure, but with little or no empirical work conducted to demonstrate how they worked better and at what cost.
We hypothesized that these changes will affect the defect detection effectiveness of the inspection, but that any increase in effectiveness will have a corresponding increase in inspection interval and effort. We evaluated this hypothesis with a controlled experiment on a live development project using professional software developers.
We found that these structural changes were largely ineffective in improving the effectiveness of inspections, but certain treatments dramatically increased the inspection interval. We also noted a large amount of unexplained variance in the data suggesting that other factors must have a strong influence on inspection performance.
On further investigation, we found that the inputs into the process (reviewers and code units) account for more of the variation than the original treatment variables, leading us to conclude that better techniques by which reviewers detect defects, not better process structures, are the key to improving inspection effectiveness.