Question 1: Difference between Smoke and Sanity testing? http://www.guru99.com/smoke-sanity-testing.html

Answer 1 : Testing done with an intent to check the major operational features of the build so as to verify that the features are working properly or not is been reffered as “Smoke testing” . For example: - Server Lunching, Driver launching . Whereas the purpose to stable the system by checking the deeper details and the relevant interaction among the modules is been reffered as “Sanity testing”

Question 2: Difference between Sanity and ?

Answer 2 : The purpose of stability of the system by checking the deeper details and the relevant interaction among the modules is been reffered as “Sanity testing” whereas testing done with an intent to check the application under test when there is a change in the software or in the environment of the application under test(AUT) so as to verify wheather a new bug might have not been introduce with an existing system will be reffered as “Regression testing”

Question 3: Difference between Smoke and Regression Testing?

Answer 3 : Testing done with an intent to check the major operational features of the build so as to verify that the features are working properly or not is been reffered as “Smoke testing” . For example: - Server Lunching, Driver launching. Whereas testing done with an intent to check the application under test when there is a change in the software or in the environment of the application under test(AUT) so as to verify wheather a new bug might have not been introduce with an existing system will be reffered as “Regression testing”.

Question 4:Difference between Regression and Re-testing?

Answer 4 : Testing done with an intent to check the application under test when there is a change in the software or in the environment of the application under test(AUT) so as to verify wheather a new bug might have not been introduce with an existing system will be reffered as “Regression testing”. Re-executing the same set up test data on the application under test(AUT) so as to verify the bug has been fixed or not is been reffered as Re-testing.

Question 5: Difference between Compatibilty and Re-testing?

Answer 5 : Testing done with an intent to check the software requirement with AUT to verify the optimize compatibility of the system is been reffered as “”. Re-executing the same set up test data on the application under test(AUT) so as to verify the bug has been fixed or not is been reffered as Re-testing. Question 6: Difference between Userbility and User-interface testing?

Answer 6 : Testing done with an intent to check the ease of use of the application under test(AUT) so as to identify how easy is to learn, observe, and understand that application by verifying the non functional requirements. The purpose of this testing is to ensure the user friendliness of the AUT. Whereas testing done with an intent to check the design specification of the Application under Test(AUT) on the basis of SRS and BRD is been reffered as User-interface testing. The purpose of this testing is to ensure look in for application.

Question 7: What are the advantages and disadvantages of White-Box testing?

Answer 7 : Advantages :-

• Forces test developer to reason carefully about implementation • Approximates the partitioning done by execution equivalence • Reveals errors in "hidden" code: • Beneficent side-effects • Optimizations (e.g. chartable that changes reps when size > 100) • As the knowledge of internal coding structure is prerequisite, it becomes very easy to find out which type of input/data can help in testing the application effectively. • The other advantage of white box testing is that it helps in optimizing the code. • It helps in removing the extra lines of code, which can bring in hidden defects.

Disadvantages :-

• Expensive • Miss cases omitted in the code • As knowledge of code and internal structure is a prerequisite, a skilled tester is needed to carry out this type of testing, which increases the cost. • And it is nearly impossible to look into every bit of code to find out hidden errors, which may create problems, resulting in failure of the application. • Not looking at the code in a runtime environment. That's important for a number of reasons. Exploitation of vulnerability is dependent upon all aspects of the platform being targeted and source code is just of those components. The underlying operating system, the backend database being used, third party security tools, dependent libraries, etc. must all be taken into account when determining exploitability. A source code review is not able to take these factors into account. • Very few white-box tests can be done without modifying the program, changing values to force different execution paths, or to generate a full range of inputs to test a particular function.

Question 8: What are the advantages and disadvantages of Black-Box testing?

Answer 8 : Advantages :-

• Black box tests are reproducible. • The environment the program is running is also tested. • The invested effort can be used multiple times. • Tester needs no knowledge of implementation, including specific programming languages • Tests are done from a user's point of view • Will help to expose any ambiguities or inconsistencies in the specifications • Efficient when used on Larger systems • As the tester and developer are independent of each other, test is balanced and unprejudiced • Tester can be non-technical. • There is no need of having detailed functional knowledge of system to the tester. • Tests will be done from an end user's point of view. Because end user should accept the system. (This is reason, sometimes this testing technique is also called as ) • Testing helps to identify the vagueness and contradiction in functional specifications. • Test cases can be designed as soon as the functional specifications are complete

Disadvantages:-

• The results are often overestimated. • Not all properties of a software product can be tested • The reason for a failure is not found. • Only a small number of possible inputs can actually be tested, to test every possible input stream would take nearly forever • Without clear and concise specifications, test cases are hard to design • There may be unnecessary repetition of test inputs if the tester is not informed of test cases the programmer has already tried • May leave many program paths untested • Cannot be directed toward specific segments of code which may be very complex (and therefore more error prone) • Test cases are tough and challenging to design, without having clear functional specifications • It is difficult to identify tricky inputs, if the test cases are not developed based on specifications. • It is difficult to identify all possible inputs in limited testing time. So writing test cases is slow and difficult • Chances of having unidentified paths during this testing • Chances of having repetition of tests that are already done by programmer.