Peer Review in Software Testing

It is an alternative form of Testing, where some colleagues were invited to examine your work products for defects and improvement opportunities.
Some Peer review approaches are,
 
Inspection – It is a more systematic and rigorous type of peer review. Inspections are more effective at finding defects than are informal reviews.
Ex : In Motorola’s Iridium project nearly 80% of the defects were detected through inspections where only 60% of the defects were detected through formal reviews.

Team Reviews – It is a planned and structured approach but less formal and less rigorous comparing to Inspections.

Walkthrough – It is an informal review because the work product’s author describes it to some colleagues and asks for suggestions. Walkthroughs are informal because they typically do not follow a defined procedure, do not specify exit criteria, require no management reporting, and generate no metrics.

Pair Programming – In Pair Programming, two developers work together on the same program at a single workstation and continuously reviewing their work.

Peer Deskcheck – In Peer Deskcheck only one person besides the author examines the work product. It is an informal review, where the reviewer can use defect checklists and some analysis methods to increase the effectiveness.

Passaround – It is a multiple, concurrent peer deskcheck where several people are invited to provide comments on the product.

Traceability Matrix

Sounds like a big word; it is actually a way to trace that all the requirements have been mapped through the development cycle. For example, that the various sections of design have covered all the requirements, test plans and cases cover all the requirements and so on. The traceability matrix document meets the following need: Provide a traceability analysis or matrix which links requirements, design specifications, hazards, and validation. Traceability among these activities and documents is essential. This document acts as a map, providing the links necessary for determining where information is located.
The client who had ordered for the product specifies his requirements to the development Team and the process of Software Development gets started. In addition to the requirements specified by the client, the development team may also propose various value added suggestions that could be added on to the software. But maintaining a track of all the requirements specified in the requirement document and checking whether all the requirements have been met by the end product is a cumbersome and a laborious process. But if high priority is not provided to this aspect of Software development cycle, it may result in a lot of confusion and arguments between the development team and the client once the product is built.
The remedy for this problem is the Traceability Matrix.
Requirements traceability is defined as the ability to describe and follow the life of a requirement, in both a forward and backward direction (i.e. from its origins, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration in any of these phases).
In a software development process, a traceability matrix is a table that correlates any two baselined documents that require a many to many relationship to determine the completeness of the relationship. It is often used with high-level requirements (sometimes known as marketing requirements) and detailed requirements of the software product to the matching parts of high-level design, detailed design, test plan, and test cases.
Requirements Traceability Matrix Document is the output of Requirements Management phase of SDLC. The Requirements Traceability Matrix (RTM) captures the complete user and system requirements for the system, or a portion of the system. The RTM captures all requirements and their traceability in a single document, and is a mandatory deliverable at the conclusion of the life-cycle.

Why Software Engineering?

The goal of software engineers is to create practical software systems that have social and/or economic value using a systematic software development process. The software development process transforms a user's needs into software, and this process can integrate a subset of the following practices: requirements engineering, system analysis, architecture, design, coding, integration, design and code reviews, testing, maintenance, project management, and configuration management. Software engineers choose an appropriate subset of these practices that best fit the parameters of the software they are developing.


Members of the software industry face many unique challenges during development of a software application. Software is a tractable, not physical medium, which provides limitless opportunities to model a bounded world. Due to the tractability of software, requirements can change frequently during the course of the project, which can lead to uncertainty. Scheduling problems can arise due to schedule optimism and schedule pressure. Software engineers are optimistic on the time it will take to develop a project, and therefore will make aggressive commitments. Schedule pressure comes from these aggressive commitments and the feeling that a project hinges on specific feature. Software engineering deals with the entire process of creating a software product, and the best practices involved with development.
For a brief history of Software Engineering Refer:
Subscribe to: Comments (Atom)