Correct Answer: Verification: Verification is a process to ensure that the software that is made, matches the original design In other words, it checks whether the software is made according to the criteria and specification described in the requirement document It is to check whether you built the product right as per design It is a low level checking (It is done in walk-through meetings generally) It checked whether it is made accordingly to the design Validation: Validation is a process to check whether the product design fits the client?s need It checks whether you built the right thing It checks whether it is designed properly

Correct Answer: Test scenarios are derived from requirement documents We follow each and every functionality (called business rules) mentioned in the requirement document One functionality can have multiple business rules For example, let us say in there is one requirement called ?Login? This ?Login? may have various scenarios For example, one scenario is, enter the right User ID and wrong password The system should display an error message Another scenario would be to enter wrong User ID and right Password The system should display an error message The third scenario could be to enter the right User Name and right Password The system should allow the user to get into the system This is how the test cases are derived from the requirement documents or from the Use Cases

Correct Answer: Regression test cases are also based on the requirement documents They are written more into detail and with every release (build), the testers need to do regression testing The criteria for regression testing are; there should be no major defects while we do our smoke test and functional testing

Correct Answer: For both client server and web based applications, the testing is the same except one thing: We test web based applications in different browsers, for example, Internet Explorer (will test in different versions like IE 50, IE 60, IE 70), Firefox, Safari (for Mac) and so on where as for client server, we don?t need to test in the browsers

Correct Answer: Similar to system testing, the *macro* end of the test scale is testing a complete application in a situation that mimics real world use, such as interacting with a database, using network communication, or interacting with other hardware, application, or system

Correct Answer: Security/penetration testing is testing how well the system is protected against unauthorized internal or external access, or willful damage This type of testing usually requires sophisticated testing techniques

Correct Answer: Recovery/error testing is testing how well a system recovers from crashes, hardware failures, or other catastrophic problems

Correct Answer: 1) List down usecases (taken from business cases) from function specs For each use case write a test case and categorize them into sanity tests, functionality, GUI, performance etc Then for each test case, write its workflow 2) For a GUI application - make a list of all GUI controls For each control start writing test cases for testing of the control UI, functionality (impact on the whole application), negative testing (for incorrect inputs), performance etc

Correct Answer: In GUI testing, need to cover the customer requirement if don't have to validate Font size, colors, spellings(labels) etc Every application should follow Microsoft rules like - Controls should be Initcap (ie every label should start with Capital letter )Can observe that in Win applications every label starts with Caps - OK or Cancel button should exist - Controls should not be overlapped - Controls should be alligned properly (left side alignment is mandatory but the right side is optional) - Controls should be visible - Short cut keys should be provided - System menu should exist (ie if u press Alt key + Space bar a menu will appear at the left most corner ) - Mouse pointer events Colors, Label Names, Tab Order, Alignment, graphs , Navigation of the software to test in GUI Testing

Correct Answer: 1) List down usecases (taken from business cases) from function specs For each use case write a test case and categorize them into sanity tests, functionality, GUI, performance etc Then for each test case, write its workflow 2) For a GUI application - make a list of all GUI controls For each control start writing test cases for testing of the control UI, functionality (impact on the whole application), negative testing (for incorrect inputs), performance etc