Software Verification : Verification is the process of manually examining / reviewing a document. The document may be SRS, SDD, the program itself or any document prepared during any phase of software development.
The objective of any verification method is to review the documents with the purpose of finding faults. Many methods are commonly used in practice like peer reviews, walkthroughs, inspections, etc. Verification helps in prevention of potential faults, which may lead to failure of software. Verification and validation activities may be performed after the implementation phase. However, only verification is possible in the phases prior to implementation like the
requirement phase, the design phase and even most of the implementation phase.
1) Peer Reviews
Any type of testing (verification or validation), even adhoc and undisciplined, is better than no testing if it is carried out by person(s) other than the developers / writers of the document with the purpose of finding faults. We give the document(s) / program(s) to someone else and ask to review the document(s) / program(s). We expect views about
the quality of the document(s) and also expect to find faults. This type of informal activity may give very good results without spending any significant resources.
Many studies have shown the importance of peer review due to its efficiency and significance. Our thrust should be to find faults in the document(s) / program(s) and not in the persons who have developed them. The activities involved may be SRS document verification, SDD verification and program verification. The reviewer may prepare a report
of observations and findings or may inform verbally during discussions.
Walkthroughs are more formal and systematic than peer reviews. In a walkthrough, the author of the document presents the document to a small group of two to seven persons. Participants are not expected to prepare anything. Only the presenter, who is the author, prepares for the meeting. The document(s) is / are distributed to all participants. During the meeting, the author introduces the material in order to make them familiar with it. All
participants may write their observations on any display mechanism like boards, sheets, projection systems, etc. so that every one may see and give views. After the review, the author writes a report about findings and any faults pointed out in the meeting.
The disadvantages of this system are the non-preparation of participants and incompleteness of the document(s) presented by the author(s). The author may hide some critical areas and unnecessarily emphasize on some specific areas of his / her interest. Walkthroughs may help us to find potential faults and may also be used for sharing the documents with others.
Many names are used for this verification method like formal reviews, technical reviews, inspections, formal technical reviews, etc. This is the most structured and most formal type of verification method and is commonly known as inspections. The presenter is not the author but some other person who prepares and understands the document being
presented. This forces that person to learn and review that document prior to the meeting. The document(s) is / are distributed to all participants in advance in order to give them sufficient time for preparation.
Important points are displayed by some display mechanism so that everyone can see them. The moderator, preferably a senior person, conducts such meetings and respects everyone’s views. The idea is not to criticize anyone but to understand their views in order to improve the quality of the document being presented. Sometimes a checklist is also
used to review the document. After the meeting, a report is prepared by the moderator and circulated to all participants. They may give their views again, if any, or discuss with the moderator. A final report is prepared after incorporating necessary suggestions by the moderator. Inspections are very effective to find potential faults and problems in the document like SRS, SDD, source code, etc.