Top 5 Software Testing Differences Asked in Software Testing Interview
While attending many Software Testing Interview I collected some important differences which asked by interviewer to explain the differences between many testing terminologies. No matters you are experienced or fresher, these differences could be asked from anyone as these are common questions. So if you are planning for any software testing interview, please at least once go through the following differences specified below for software testing terminologies.
Verification and Validation
Verification checks for are we building the product right where Validation checks for are we building the right product. Verification is the static method where validation is dynamic method. Verification ensure that your requirement meets completely as expected from the product or software build, however validation ensure that product or software meets the end users criteria and expectation. Verification is performed by Quality Assurance team and team assures that software is built as per specified in the specification documents where verification is performed by testing team by providing the multiple inputs or test data. In verification phase we perform walk -through, inspection and review where in validation we perform testing activities.
Priority and Severity
We define severity based on the operation performed by the user. If a user not able to perform any activity due to some reason or bug, then severity is high. Priority depends on features added in the product or software. For example, consider Google page. If you enter any word to search and Google landing to the error page then severity is very high as well as priority is also very high. But if Google is providing the correct result but design is not very user friendly, then priority is low as well as severity is also low. Severity could be critical, major or minor. Priority could be low, medium or high.
Based on priority and severity there could be 4 scenarios:
- High Priority and High Severity
- High Priority and Low Severity
- Low Priority and High Severity
- Low Priority and Low Severity
Suppose a product is launched with brand name “TESTING” which perform the operation to login on home page.
If brand name “TESTING” is correct but product does not allows to login, then priority is high as well as severity is also high. As brand name is TESTING and it is misspelt from TESTING to TESING then it has high priority but low severity. If you forgot your password and click on the link “forgot password” to recover your password, but clicking on the link does not response then severity is high but priority is low. Priority is low because user not going to reset password always. If any design issue is there but user is able to perform all the operations without any error, then priority is low as well as severity is also low.
Severity always related to the functionality where priority is based on the seriousness of the bug.
Re-Testing and Regression Testing
Retesting is performed to ensure that the reported bug or defect is fixed and the same bug or defect is not occurring again. So retesting is only for testing the fixed bugs or defects. In Regression testing we test the application as whole to confirm that bug fix or defect fix should not have effect on existing functionality or features. Regression testing ensure that the existing feature is working as it was working before and there is no bad impact on existing feature after bug or defect fix.
Retesting is performed only for the reported bug fix and not for all the existing test cases. Regression testing is performed for all the existing test cases.
Suppose there is an application that allows user to sign up with name, email and phone number. There is one issue reported as phone number field should not accept alphabet characters. The fix was given by developers after bug reported. Now as a retesting we confirm that issue is fixed (Phone number field is now not accepting alphabet) and as regression testing we confirm that name and email fields are working as it was working before and signup is happening successfully.
Bug and Defect
Sometimes its really confusing and difficult to differentiate between bug and defect as both the terminologies are alike. But still there are some slight difference in bug and defect. Defect is deviation between the expected result and actual result where bug arises due to error in the code or logic. There is not necessary that a defect in the software is a bug. Defect could be functionality level or logical level that did not meet the expected result. Bug generally found before the product deployed to production where defect could be found after the deployment of the product in production. Any mistake done in the code we can say as bug however any defect in the functionality we can say as defect. Defect could be happen because of misunderstanding of requirement.
Suppose there is one online application which allows to sign up. There are three fields Name, Email and Phone number and Submit button. But client wanted to have only Name and Email field and submit button. Client did not want to have Phone number field. So there is defect in the application that developer did not completely understood the requirement and added phone number field. Suppose phone number field was removed and defect is fixed but Submit button is not working then there is a bug in the software.
Stress Testing and Load Testing
Load testing is performed to test the server behavior when more than one users or some specified number of users uses the server at a time, however stress testing is performed by giving maximum load to the server till server stops performing and we check the maximum stress or break point that server can exists. In another way we can say performing test with more than one users is defined as load testing where performing test beyond the limit of the server capacity is defined as stress testing. In load testing we check the server behavior where in stress testing we check the breakpoint of the server. During load test we can define total number or users, time duration for load, ramp up period etc. During stress testing we can define the maximum number of users, continuous load time etc.
Suppose there is one server which capacity is to handle maximum 100 users at a time. While performing load test we give load for 100 users and check the server performance where performing stress test we give load for more than 100 users and we keep on increasing load until server starts misbehaving or breaks or go down.