hi

bug validation of is the process after finding the bug in
application which is duty of tester and it should be done
first and foremost as the tester find the bug.

its important in the sense when tester finds the bug , and
by doing bug validation he himself makes sure that whatever
he found is valid one and can be reported to senior

steps to perform bug validation:

when he/she finds the bug at first they have to do:
.note the severity of bug
.check with change request team( to make sure generation of
bug is due to changes made in application)
. refer old release to make sure the bug found is valid and
not repeated.
.check with test case/ test plan/any requirement documents.

to avoid confusion  after finding bug, according to me One
should do 'bug Validation ' before reporting it to higher level

                            cheers
   
                            ravibyndur@yahoo.com

Ravi, you have the understanding of concepts to some extent 
but it looks like you have tried to explain everybody the 
bug process which you are probably following somewhere (in 
a week process based company). Moreover you also didn't 
understand the question.
What is Bug Validation? (its not a process)
Bug validation: Bug and Validation are two different terms. 
Bug means an anomaly and validation means checking with the 
appropriate data whether the functionality is working as 
per the requirement. If a bug is reported on a 
functionality on earlier build(this could be alpha or beta) 
then on next consecutive build (alpha or beta) it should be 
validated in order to Determine if the system complies with 
the requirements and performs functions for which it is 
intended and meets the user needs.

What can be a different resultant 
after the same?
Different resultants of bug validation could be:
1. The bug could be validated using various inputs 
If the bug is passed:
2. Then before closing the bug user/tester can also provide 
information like screenshot of whether the output was 
expected or not.
3. Then before closing the bug user can also provide 
information whether the fix has fulfilled the requirement.
If the bug fails:
4. Then on re-opening the bug what was the outcome could be 
provided as screen shot
5. Then on reopening the bug what other 
features/functionalities are affected can also be informed.

Note bug validation is not only done by testing team it 
could also be done by development team. For e.g, if 
development team reported bugs on alpha build they were 
testing then they might validate on next alpha consecutive 
build or fix it for beta build so that testing team can 
validate it. Thats why I have used the alpha(development 
team) and beta(for testing team) terms for the build.

Ravi, what you have been trying to explain is bug 
process/bug life cycle. What you were trying to provide is 
as follows:
1. Tester finds a bug and logs it with appropriate Priority 
and severity (tester doesnt have to ask to anybody for P/S)
2. Change control board verifies whether the bug (its 
earlier existence in Bug logging software, whether its 
valid) and then assigns it to the appropriate functinality 
stake holder in development.
3. Developer fixes it and provides the information in the 
bug as well as during the release build notes of the next 
consecutive build carrying the fix for the bug.
4. Tester validates the bug in next build and updates the 
status of bug. 
5. If the bug passes then its closed else if its failed 
then the above process is followed as it is.