I guess severity replicate the seriousness of the bug where as priority refers to which bug should rectify first. of course if the severity is high the same case is with priority in normal.

Severity decided by the tester where as priority decided by developers. Which one need to answer first knows through priority not with severity. How serious of the bug knows through severity.

Severity is nothing collision of that bug on the application. Priority is nothing but weight to resolve the bug yeah of course by looking severity we can judge but sometimes high severity bug doesn’t have high priority At the same time High priority bug don’t have high severity. So we need both severity and priority

Test case would have detail steps of what the application is made-up to do. So

Functionality of application is acknowledged.
In addition you can refer to Backend, I mean glance into the Database. To gain more information of the application

There are two ways to execute test case:

1. Manual Runner Tool for manual execution and updating of test status.
2. Automated test case execution by specifying Host name and other automation pertaining details.

Retesting:
Re-execution of test cases on same application put up with different input values is retesting.

Regression Testing:
Re-execution of test cases on updated form of build is called regression testing.

Bug log is a document which keep the information of the bug where as bug tracking is the process.

Bug will be in open position while developer is working on it Fixed after developer completes his work if it is not fixed correctly the tester puts it in reopen After fixing the bug properly it is in closed state.

A traceability matrix is formed by associating necessities with the work products that satisfy them. Tests are linked with the requirements on which they are based and the product tested to assemble the requirement.

A traceability matrix is a statement from the requirements database or repository.

Positive Testing:Testing the application functionality with suitable inputs and confirming that output is right

Negative testing:Testing the application functionality with unacceptable inputs and verifying the output.

Difference is nothing but how the application perform when we enter some unacceptable inputs suppose if it accepts invalid input the application Functionality is wrong

Risk Analysis: A systematic use of accessible information to decide how frequently specified events and unspecified events may happen and the magnitude of their likely consequences.

We have management tools like Test Director, Team rack, Rational Clear Quest, Bug Zilla etc.,

Functional Unit Teset cases (FUT)
Integration Test cases (IT)
System Test cases (ST)
User Inerface Test cases
Validations

Verification typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. This can be done with checklists, issues lists, walkthroughs, and inspection meetings. Validation typically involves actual testing and takes place after verifications are completed. The term ‘IV & V’ refers to Independent Verification and Validation.

A ‘walkthrough’ is an informal meeting for evaluation or informational purposes. Little or no preparation is usually required.