Verification and Validation

Testing is the process which begins right from Requirement phase; hence the idea of catching defects at each stage, before the actual testing is started leads us to define Verification and Validation.
Verification and Validation are the activities performed to improve the quality and reliability of the system and assure the product satisfies the customer needs. Verification assures the product of each development phase meets their respective requirements. Validation assures the final product meets the client requirements.

When we ask the question "Are we producing the product right?” the activities which take care are part of Verification. Whereas when we ask "Are we producing the right product?" the activities which take care are part of Validation. Hence activities like Requirement Review, Design Review, Code Review, etc... Are the part of Verification and activities like Unit Testing, Integration Testing, System Testing are the part of Validation.

General Definition:
Verification is the process of evaluating a system or component to determine whether the product of a given phase satisfies the conditions imposed at the start of that phase.
Validation is the process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements

Verification is a Quality improvement process. It is a Low level activity performed during development on key artifacts, like walkthroughs, reviews and inspections, mentor feedback, training, checklists and standards; it demonstrates consistency, completeness, and correctness of the software at each stage and between each stage of the development life cycle.
Validation process ensures the functionality. It is a High level activity performed after a work product is produced against established criteria ensuring that the product integrates correctly into the environment, it determines correctness of the final software product by a development project with respect to the user needs and requirements

Note: There are different process and methodologies followed in various organizations. The above content is as per my experience in industry so far.

 

Please feel free to write comments if you like my post or else if your opinion is different or you may like to add any more points in them.

Severity Vs Priority

Severity and Priority are two completely different concepts when it comes to managing Software defects.
•    Bug severity indicates how much effect a bug is doing on the application.
•    Bug priority indicates how important or how quickly it is to fix that bug.

Severity defines the impact that a given defect has on the system.
They are classified in following sections

1. Blocker
   Application crashes or fails to initialize. Database connectivity issue where system is unable to fetch data or fetches wrong data.
2. Critical
   Important feature in test fails.
3. Major
   Secondary feature in test is not operating as expected.
4. Normal
   Secondary feature in test has some not so important issues. Minor feature in test is not operating as expected.
5. Minor
   Secondary feature in test has some UI issues. Minor feature in test has some not so important issues.
6. Trivial
   Minor feature in test has some UI issues or typos.
7. Enhancement
   Any modification in the existing product which is not covered in requirements, but the stated modification shall be essential for look and feel or for business.

These days Normal and Trivial are not in much use, most of the bug reporting tool have Blocker, Critical, Major, Minor and Enhancement as severity values in their drop-down for Severity field.

Priority defines the order in which we should resolve a defect.
They are classified in following sections

1. Priority 1
   -    Should be fixed as soon as possible.
   -    The application hangs or crashes (Blockers, Critical and Show stopper Issues).
   -    Data loss taking place.
   -    Memory Leakages are identified.
   -    Implementation is opposite to the requirement specified.
2. Priority 2
   -    Should be considered to fix as soon as possible.
   -    Having important feature some logical issues. (Wrong functionality implemented).
   -    Performance Issues.
   -    Major Cosmetic Issues
   -    Important Typo errors to be fixed
3. Priority 3
   -    Should be considered to fix.
   -    Having secondary or other feature some logical issues. (Wrong functionality implemented).
   -    Minor Cosmetic Issues
4. Priority 4
   -    Should be considering to be fixed before build is released to clients.
   -    Minor Cosmetic Issues.
   -    Other Typo Errors.
5. Priority 5
   -    Enhancement and Suggestion.

Some bug reporting tool as High, Medium and Low as their Priority values in their drop-down for Priority values.

Following are the examples where different combination of Severity and Priority can be clubbed.

• High severity, High priority
  If we need to print some data on paper or display some data on screen, and you observed that the data is not printed. For example a Mobile number which is a mandatory field is to be entered in an application and it is to be printed, but it is not printed even though user has entered data. The scenario stated is of High Severity and High Priority. 
• High severity, Low priority
  If we need to print some data on paper or display some data on screen, and you observed that the data is printed but not in order in which we expected. For example an address is to be printed as Building name, followed by Flat No but in actual implementation the order is not as per requirement. The scenario stated is of High Severity but with Low Priority. 
• Low severity, High priority
  If we need to print some data on paper or display some data on screen, and you observed that the data is printed but it gets trimmed at the end. For example a Mobile number which is a mandatory field is to be entered in an application and it is to be printed, but it is not printed completed. For example user enters 10 digits and in actual implementation only 8 – 9 digits are printed even though there is more space which permits more digit to be printed. The scenario stated is of Low Severity and High Priority. 
• Low severity, Low priority
  If we need to print some data on paper or display some data on screen, and you observed that the data is printed but some punctuation are missing as we expected. For example an address is to be printed as Building name followed by comma and Flat No but in actual implementation the comma is missing. The scenario stated is of Low Severity but with Low Priority.

Note: There are different process and methodologies followed in various organizations. The above content is as per my experience in industry so far.

Please feel free to write comments if you like my post or else if your opinion is different or you may like to add any more points in them.

A Story: Software Developer Versus Software Testing Guru

Hello Friends,

I had received a mail few years back a converstaion between Testing Guru and University Scholar. I would like to share the story with you all.

---

A university scholar, Mr. John Smith approaches his friend a software-testing guru telling him that he has a Bachelor in programming,

and now would like to learn the software testing to complete his knowledge and to find a job as a software tester. After summing him up for a few

minutes, the software-testing guru told him "I seriously doubt that you are ready to study software testing. It's the serious topic. If you wish

however I am willing to examine you in logic, and if you pass the test I will help teach you software testing. "

The young man agrees. Software testing guru holds up two fingers "Two men come down a chimney.

One comes with a clean face and the other comes out with a dirty face. Which one washes his face?

The young man stares at the software-testing guru. "Is that a test in Logic?" software testing guru nods.

"The one with the dirty face washes his face," He answers wearily.

"Wrong. The one with the clean face washes his face. Examine the simple logic. The one with the dirty face looks at the one with the clean face

and thinks his face is clean. The one with the clean face looks at the one with the dirty face and thinks his face is dirty. So; the one with the

clean face washes his face."

"Very clever" Says Smith. "Give me another test"

The software-testing guru again holds up two fingers "Two men come down a chimney. One comes out with a clean face and the other comes out with a

dirty face. Which one washes his face?

"We have already established that. The one with the clean face washes his face"

"Wrong. Each one washes his face. Examine the simple logic. The one with the dirty face looks at the one with the clean face and thinks his face is

clean. The one with the clean face looks at the one with the dirty face and thinks his face is dirty. So; the one with the clean face washes his

face. When the one with the dirty face sees the one with the clean face washing his face, he also washes his face. So each one washes his face"

"I didn't think of that!" Says Smith. " It's shocking to me that I could make an error in logic. Test me again!."

The software-testing guru holds up two fingers "Two men come down a chimney. One comes out with a clean face and the other comes out with a

dirty face. Which one washes his face?

"Each one washes his face"

"Wrong. Neither one washes his face. Examine the simple logic. The one with the dirty face looks at the one with the clean face and thinks his

face is clean. The one with the clean face looks at the one with the dirty face and thinks his face is dirty. But when the one with clean face sees

that the one with the dirty face doesn't wash his face, he also doesn't wash his face So neither one washes his face".

Smith is desperate. "I am qualified to study software testing. Please give me one more test"

He groans when the software-testing guru lifts his two fingers, "Two men come down a chimney. One comes out with a clean face and the other comes

out with a dirty face. Which one washes his face?

"Neither one washes his face"

"Wrong. Do you now see, John, why programming knowledge is an insufficient basis for studying the software testing? Tell me, how is it possible for

two men to come down the same chimney, and for one to come out with a clean face and the other with a dirty face? Don’t you see?

GUYS !!! Requirements for testers will look the same but expectations from clients will vary every now and then…

So never under estimate TESTERS.. 

---

I hope you all like the conversation, Please feel free to share it among your friends.
As Development is a core strength of Software Industry, Testing is the spine to it. Both goes hand in hand.

Don't forget testing is a creative and challenging task. Finally it depends on your skill and experience, how you handle this challenge.