Verification is also known as static testing. General flow of software development is, developer develop the software as per the requirement document. But what if there is an ambiguities in requirement documents? What if the requirement is not complete? There are many possibilities. If by ignoring all the possibilities. And developer keeps on developing the software according to these documents then more likely there will be a lots of bugs in software. These bugs will be discovered in testing phase and they report it to developer. As we know that bug found is lateral phases is more costly to fix and more time consuming. If we do verification early in development life cycle then it would not bring so many bugs in software. It will reduce the number of bugs.
If there is a bug in requirement specification then that will definitely bug reflects in developed software. likes it’s an cycle if there is ambiguities in business requirement then that will come to requirement specification then that will further come in developed software. And there ambiguities may arise different issues in software. So it is very needed to do verification testing / static testing.as I said if there is an ambiguities in business requirement then that will come in requirement. But it is not necessary that the ambiguities or defect always present in business requirement. Sometime even business requirement is correct and does not have any issues then also in specification requirement there is chance of ambiguities and defect. So it is necessary to do a verification testing on each phases of development.
The code, function, logic written by developer is also need to be verified means verification testing needed there also.
As a basic idea about verification, a verification is like asking your colleagues, you’re senior to verify the documents, code that you have made. Then your colleagues, senior provides a comment on your document which could help is improving the document, code that you have written. There are different type of verification. Some of the type of verification requires planning and some of them doesn’t require planning.
There are two categories of verification testing / static testing.
- Static analysis
- Review - Formal Review, Informal Review.
Static Analysis :
In static analysis the code written by the developer is analyzed for the structural defect which may lead to defect in future.
They analysis the code try to find out : variable with undefined value, variable that is defined but never used, dead code, commented code and also check the whether the code is written as per the industrial standards or not etc.
Review : Formal Review
Let’s first understand who involves in formal review (Participant of formal review).
- Moderator : This is a person who is responsible for meeting and scheduling.
- Author : Author is a person who created the documents, codes etc.
- Scribe : The defect logging work is done by the Scribe.
- Reviewer : Check the document under review.
- Manager : Manager is a project manager.
These all persons take a park is formal review.
Process of formal review is as follows:
- The review process being with a “request of Review” which is made by the author to the moderator.
- Then moderator do an entry check to insure that the document is ready so that the time will not waste of reviewer.
- If the document found ready Then moderator has to arrange the review meeting, moderator is the person who have to take care of scheduling like date ,time , place and invitation.
- In This phase the reviewer get the short introduction on the objective of the Document under review.
- And the relationship between the document under review and other document is also explained.
- This is step where reviewer individually review the document under review using the related document, procedure and check list that is provided to them provided.
- While reviewing the document , they identifies the defects , questions and comments on the document accordingly there understanding of the document and roles.
- After this they log all the issues in the logging form.
Review Meeting :
This Review Meeting is further divided into three phases.
- Logging Phase : In this Phase, the Defect identified and comments in Preparation step is logged this is phase. This logging of defect and comments is done by author or scribe
- Discussion Phase : this is a second phase of Review Meeting step, here in this phase if there is any part of the document that need to be discussed that part is discussed in this Discussing Phase and the reviewer can take part into the discussion by bring forward there comments and the reasons, and the outcome of the discussion is documented for the further reference.
- Decision Phase : this is the last phase of the Review Meeting, in this Phase reviewer has to take the decision on the Document under review, and this Decision is based on the Major defect found in the document for e.g. if there is more than three major / critical defects are there then this document has to reviewed again after rework.
- If the defect that has identified during the review crosses the certain level then that document has to be reworked by the author to resolve the defect.
- Author not necessarily solve the all the defect, its author’s responsibility to judge which defect should solve and which defect should leave.
Follow Up :
- In this step the moderator check whether author has taken necessary action on all the known defect.
- After rework of author finishes then it moderator’s responsibility to circulate updated document to the participant and collect feedback from them.
- It is moderator’s responsibility to ensure that the information is correct and stored for the future analysis.
Review : informal Review
Second type of review is informal review.
- Main different between formal review and informal review is, informal review is not a planned review. Here an author go to their colleagues and ask for review on document. The author listen the review and comment from their colleagues and if they have valid point then the author consider the suggestion.
Advantages of Software Verification :
- Verification helps in lowering down the count of the defect in the later stages of development .because most of the bugs come from incomplete requirement or incorrect requirement.
- Verifying the product at the starting phase of the development will help in understanding the product in a better way.
- It reduces the chances of failures in the software application or product.
- It helps in building the product as per the customer specifications and needs.