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.

The QA testing process that was followed in my last company where I worked was like this: First of all the Business Requirement Document was prepared as per the client’s requirement (with the muck-up screen shots). Then on the basis of the requirement document, Test Strategy, Test Plans and Test Cases were written in sequential order. Once the Build is made and deployed to the different testing environments where different types of testing were performed to check whether there are any defects.

Basically Load, Stress and Performance Testing are the same. However, Load testing is the test to check the users’ response time of number of users of any one scenario of the application whereas Performance Testing is the test to check the user response time for multiple scenario of the same application.

Use case is nothing but the functional specification document in which all the customer requirements are documented.

Test case is a document which tells wat to test, steps to test and expected and actual results.

Exploratory testing: means testing an application without a test plan and test script. In exploring testing test explore the application on the basis on his knowledge. The tester has no knowledge about the application previously. He explores the application like an end user and try to use it. While using the application his main motive is to find the bugs which are in the application.

Specification-driven testing: means to test the functionality of software according to the user requirements. In this, tester inputs multiple data and monitors the outputs from, the test object. In this testing tester evaluate the showstopper bugs which break the major functionality of the application. This type of testing requires test plan and test.

Regression Testing: When changes in the code of the software are made to fix the previous bug. Then testing needs to be perform to ensure that it will not generate a new bug in the application and it works as specified and that it has not negatively impacted any functionality that it offered previously. Regression Testing is important because of following reason:

- That the application works even after the alteration in the code were made.

- The original functionality continues to work as specified even after doing changes in the software application.

- The alteration to the software application has not introduced any new bugs.

Automated testing cannot replace manual testing because of following reason:

- Automated testing cannot replace the analytical skills required to conduct testing. It can only enhance or supplement manual testing,

- Through manual testing, information can be gathered about the application, and real-time decisions can be made about how to enhance a test that would be too difficult to program into an automated script.

- We need a manual tester to analyze and maintain the automated scripts after they can run.

Bottom Up Approach:

The bottom up approach testing approach is carried out with the help of the test driver. The test driver calls a component to be tested.

The modules in the lower level of call hierarchy are tested independently. Then the next level modules are tested that call previously tested modules. This is done repeatedly until all the modules are included in the testing.

Bottom up testing stops when the top module in the call hierarchy is tested with all lower call hierarchy modules.

Top Down Approach:

The top down approach is carried out with the help of the test stub. Test stub are the dummy programs. The Stub is called from the software component to be tested.

Tests top layer of controlling subsystem first. Then combine modules that are called by the tested modules and test resulted collection of modules.

Do this until all the modules are combined and tested.