Topic: Software Testing-Testing Techniques

Software Testing-Testing Techniques

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.

• Benefits


• Improved Code Quality


• Improved code quality is ensured by the enforcement of coding standards.


• Improved Application Performance
is ensured by the review of all database access paths by the DBA and technical lead, and the improvement/removal of questionable coding practices.

• Improved Developer Performance
is ensured by the mentoring of the developer by the DBA and technical lead, the discussion of coding style and technique. Peer reviews are an important component of a continuing training plan. How else can a developer hone his skills? Few training vendors offer formal sessions for developers with more than five years of experience, and fewer employers take advantage of those sessions.

• Excuses
• Here are a few of the many excuses offered for not enforcing code walkthroughs as a shop standard.
  
• Volumes of data
Technical leads and database administrators are unwilling to spend time wading through large Natural and COBOL listings searching for a few simple source changes. Database administrators need to see quickly what database accesses were added or changed.

• Deleted code
Deleted code cannot be reviewed, but leaving the code in place, converted to comments, can render illegible an otherwise well-structured module.

• Manual effort,/li> The amount of effort required by the developer is significant to create useful documentation for a technical walkthrough. The manual procedures involved are difficult, tedious, time-consuming, and error-prone
  
• Lack of Consistency
There must be consistency. If code is accepted by one reviewer but rejected by another, or accepted on one occasion but rejected on another, developers will become confused and frustrated. There must be consensus among the reviewers.
Once standards are published, developers can ensure compliance, allowing a much more positive and less time-consuming review process. Reviewers can direct more attention to unusual and complex coding techniques.

• Developers are reluctant to be involved
Without training, experience, and focus, a technical lead can allow a code walkthrough to degrade into something resembling a lynching. Constructive criticism deteriorates into destructive criticism.
The process must be considered by all parties an opportunity to train the developer, enlighten the technical lead and database administrator, and maintain or improve the quality and performance of the application system. It should be a win-win situation for all persons involved.
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.