Interview Questions

 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.

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.

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 5.0, IE 6.0, IE 7.0), Firefox, Safari (for Mac) and so on where as for client server, we don’t need to test in the browsers.

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.

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.

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

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. 

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.