Parallel/audit testing is testing where the user reconciles the output of the new system to the output of the current system to verify the new system performs the operations correctly. Let us say, for example, the currently software is in the mainframe system which calculates the interest rate. The company wants to change this mainframe system to web-based application. While testing the new web based application, we need to verify that the web-based application calculates the same interest rate. This is parallel testing.

 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.

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.

Walkthrogh: Very informal type of review or testing method. Done by peers, so its called peer review.

Inspection: very technical type of review or testing method, done by the highly technically sound people.

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.

The Bug Tracking System role is discussed below:

- Testers and developers can know the status of the bug at every stage.

- Changes to the Status will be available to all team members.

- Developers and Testers can easily interact with bugs.

- Repetition of bugs will be avoided.

- Easy to distribute the bug among the developer.

- It will act as a centralized one for defects.