We need to have a requirement document if not otherwise 
atleast the info pulled /carried forward since previous 
project

Traceability Matrix: 

It's a document that maps requirements to Testcases.
For every requirement there will be  a Requirement ID, Req.
Description. For each Requirement there will be one more
testcases. In the same way for every TestCase there will be
a TestCase ID, Testcase Description.

USE: 

Using Traceability Matrix we can tell the coverage of the
Testcases.

i.e WE can identify the requirements which have bug fixes
and related functionalities.

Trecebility matrix is mapping between software Requierment
and Test case . It is use to make sure that test case
consists all Functional  Requierment .

In a software development process, a traceability matrix is 
a table that correlates any two baselined documents that 
require a many to many relationship to determine the 
completeness of the relationship. It is often used with 
high-level requirements (sometimes known as marketing 
requirements) and detailed requirements of the software 
product to the matching parts of high-level design, 
detailed design, test plan, and test cases.

Common usage is to take the identifier for each of the 
items of one document and place them in the left column. 
The identifiers for the other document are placed across 
the top row. When an item in the left column is related to 
an item across the top, a mark is placed in the 
intersecting cell. The number of relationships are added up 
for each row and each column. This value indicates the 
mapping of the two items. Zero values indicate that no 
relationship exists. It must be determined if one must be 
made. Large values imply that the item is too complex and 
should be simplified.

To ease the creation of traceability matrices, it is 
advisable to add the relationships to the source documents 
for both backward traceability and forward traceability. In 
other words, when an item is changed in one baselined 
document, it's easy to see what needs to be changed in the 
other.

i think first u have to prepare the use case in case of 
developer has send the use case for you.


By viewing the use case the tester shall prepare the 
testcases

See writing test cases from SRS document is very difficult.

Hi Priya,  
SRS means nothing, but what you required to complete /
prepare something required some necessary things....this
type of document called as SRS.
for e.g. Company ABC provides insurance for students...for
this SRS like: insurance policy conditions in depth
(eligibility, limitations, etc.)  some mandatory fields.

Based on those conditions you have to prepare test cases.

here is the sample test plan

TEST PLAN (Sample)
courtesy of sqatestester.com

   

Company Name

Test Plan  Revision C     


 

  Revision History 

DATE
 REV
 AUTHOR DESCRIPTION 
5/14/98
 A
   First Draft 
5/21/98
 B
   Second Draft 
5/25/98
 C
   Added FTBT 
        
        
        
        
        
        
        
        
        
        
        
        
        
        
        
        
        

  Table of Contents 1.    Introduction       4
1.1.     Test Plan Objectives. 4
2.    Scope…. 4
2.1.     Data Entry  4
2.2.    ReportsFile Transfer….. 4
2.3.     File Transfer….. 4
2.4.  Security    4
3.    Test Strategy……. 5
3.1. System Test………. 5
3.2. Performance Test………. 5
3.3. Security Test………. 5
3.4. Automated Test………. 5
3.5. Stress and Volume Test………. 5
3.6. Recovery Test………. 5
3.7. Documentation Test……. 5
3.8. Beta Test    5
3.9. User Acceptance Test………. 5
4.       Environment Requirements 6
4.1. Data Entry workstations 6
4.2 MainFrame 6
5.    Test Schedule…… 6
6.    Control Procedures… 6
6.1 Reviews 6
6.2 Bug Review meetings… 6
6.3 Change Request…. 6
6.4 Defect Reporting… 6
7.    Functions To Be Tested 7
8.  Resources and Responsibilities       7
8.1. Resources. 7
8.2.    Responsibilities    7
9.    Deliverables       8
10.  Suspension / Exit Criteria… 9
11.  Resumption Criteria……… 9
12.       Dependencies   9
12.1    Personnel Dependencies    9
12.2    Software Dependencies    9
12.3 Hardware Dependancies    9
12.3    Test Data & Database… 9
13.  Risks….. 9
13.1. Schedule… 9
13.2. Technical… 9
13.3. Management 9
13.4. Personnel 10
13.5 Requirements    10
14. Tools….. 10
15.       Documentation  10
16. Approvals 11
  

1.    Introduction
 The company has outgrown its current payroll system & is 
developing a new system that will allow for further growth 
and provide additional features. The software test 
department has been tasked with testing the new system. The 
new system will do the following:

§         Provide the users with menus, directions & error 
messages to direct him/her on the various options.

§         Handle the update/addition of employee 
information.

§         Print various reports.

§         Create a payroll file and transfer the file to 
the mainframe.

§         Run on the Banyan Vines Network using IBM 
compatible PCs as data entry terminals

1.1.  Test Plan Objectives
This Test Plan for the new Payroll System supports the 
following objectives:

§         Define the activities required to prepare for and 
conduct System, Beta and User Acceptance testing.

§         Communicate to all responsible parties the System 
Test strategy.

§         Define deliverables and responsible parties.

§         Communicate to all responsible parties the 
various Dependencies and Risks

 

2.   Scope
2.1.         Data Entry
The new payroll system should allow the payroll clerks to 
enter employee information from IBM compatible PC 
workstations running DOS 3.3 or higher. The system will be 
menu driven and will provide error messages to help direct 
the clerks through various options.

2.2.      Reports
The system will allow the payroll clerks to print 3 types 
of reports. These reports are:

§         A pay period transaction report

§         A pay period exception report

§         A three month history report

2.3.      File Transfer
Once the employee information is entered into the LAN 
database, the payroll system will allow the clerk to create 
a payroll file. This file can then be transferred, over the 
network, to the mainframe.

2.4.  Security
Each payroll clerk will need a userid and password to login 
to the system. The system will require the clerks to change 
the password every 30 days.  

3.           Test Strategy
The test strategy consists of a series of different tests 
that will fully exercise the payroll system. The primary 
purpose of these tests is to uncover the systems 
limitations and measure its full capabilities. A list of 
the various planned tests and a brief explanation follows 
below.

3.1. System Test
The System tests will focus on the behavior of the payroll 
system. User scenarios will be executed against the system 
as well as screen mapping and error message testing. 
Overall, the system tests will test the integrated system 
and verify that it meets the requirements defined in the 
requirements document.

3.2. Performance Test
Performance test will be conducted to ensure that the 
payroll system’s response times meet the user expectations 
and does not exceed the specified performance criteria. 
During these tests, response times will be measured under 
heavy stress and/or volume.

3.3. Security Test
Security tests will determine how secure the new payroll 
system is. The tests will verify that unauthorized user 
access to confidential data is prevented.

3.4. Automated Test
A suite of automated tests will be developed to test the 
basic functionality of the payroll system and perform 
regression testing on areas of the systems that previously 
had critical/major defects. The tool will also assist us by 
executing user scenarios thereby emulating several users.

 

3.5. Stress and Volume Test 
We will subject the payroll system to high input conditions 
and a high volume of data during the peak times. The System 
will be stress tested using twice (20 users) the number of 
expected users.

3.6. Recovery Test   
Recovery tests will force the system to fail in a various 
ways and verify the recovery is properly performed. It is 
vitally important that all payroll data is recovered after 
a system failure & no corruption of the data occurred.    

3.7. Documentation Test  
Tests will be conducted to check the accuracy of the user 
documentation. These tests will ensure that no features are 
missing, and the contents can be easily understood.

3.8. Beta Test
The Payroll department will beta tests the new payroll 
system and will report any defects they find. This will 
subject  the system to tests that could not be performed in 
our test environment.

3.9. User Acceptance Test
Once the payroll system is ready for implementation, the 
Payroll department will perform User Acceptance Testing. 
The purpose of these tests is to confirm that the system is 
developed according to the specified user requirements and 
is ready for operational use. 

4.    Environment Requirements
4.1. Data Entry workstations
§         20 IBM compatible PCs (10 will be used by the 
automation tool to emulate payroll clerks).

§         286 processor (minimum)

§         4mb RAM

§         100 mb Hard Drive

§         DOS 3.3 or higher

§         Attached to Banyan Vines network

§         A Network attached printer

§         20 user ids and passwords (10 will be used by the 
automation tool to emulate payroll clerks).

 

4.2 MainFrame
§         Attached to the Banyan Vines network

§         Access to a test database (to store payroll 
information transferred from LAN payroll system) 

5.   Test Schedule
§         Ramp up / System 
familiarization                      6/01/98       -      
6/15/98

§         System 
Test                                                        
                6/16/98       -      8/26/98

§         Beta 
Test                                                        
              7/28/98       -      8/18/98

§         User Acceptance 
Test                                                      
8/29/98       -      9/03/98

 

6.    Control Procedures
6.1 Reviews
The project team will perform reviews for each Phase. (i.e. 
Requirements Review, Design Review, Code Review, Test Plan 
Review, Test Case Review and Final Test Summary Review). A 
meeting notice, with related documents, will be emailed to 
each participant.

6.2 Bug Review meetings
Regular weekly meeting will be held to discuss reported 
defects. The development department will provide  
status/updates on all defects reported and the test 
department will provide addition defect information if 
needed. All member of the project team will participate.

6.3 Change Request
Once testing begins, changes to the payroll system are 
discouraged. If functional changes are required, these 
proposed changes will be discussed with the Change Control 
Board (CCB). The CCB will determine the impact of the 
change and if/when it should be implemented.

6.4 Defect Reporting
When defects are found, the testers will complete a defect 
report on the defect tracking system. The defect 
tracking       Systems is accessible by testers, developers 
& all members of the project team. When a defect has been 
fixed or more information is needed, the developer will 
change the status of the defect to indicate the current 
state. Once a defect is verified as FIXED by the testers, 
the testers will close the defect report.            

7.    Functions To Be Tested
The following is a list of functions that will be tested: 
§         Add/update employee information

§         Search / Lookup employee information

§         Escape to return to Main Menu

§         Security features

§         Scaling to 700 employee records

§         Error messages

§         Report Printing

§         Creation of payroll file

§         Transfer of payroll file to the mainframe

§         Screen mappings (GUI flow). Includes default 
settings

§         FICA Calculation

§         State Tax Calculation

§         Federal Tax Calculation

§         Gross pay Calculation

§         Net pay Calculation

§         Sick Leave Balance Calculation

§         Annual Leave Balance Calculation A Requirements 
Validation Matrix will “map” the test cases back to the 
requirements. See Deliverables.

8.  Resources and Responsibilities
The Test Lead and Project Manager will determine when 
system test will start and end. The Test lead will also be 
responsible for coordinating schedules, equipment, & tools 
for the testers as well as writing/updating the Test Plan, 
Weekly Test Status reports and Final Test Summary report. 
The testers will be responsible for writing the test cases 
and executing the tests. With the help of the Test Lead, 
the Payroll Department Manager and Payroll clerks will be 
responsible for the Beta and User Acceptance tests.

8.1. Resources
The test team will consist of:§         A Project Manager

§         A Test Lead

§         5 Testers

§         The Payroll Department Manager

§         5 Payroll Clerks

 

8.2.  Responsibilities
     Project Manager Responsible for Project schedules and 
the overall success of the project. Participate on CCB. 
    
     Lead Developer Serve as a primary contact/liaison 
between the development department and the project team. 

Participate on CCB.
 
    
    
     Test Lead Ensures the overall success of the test 
cycles. He/she will coordinate weekly meetings and will 
communicate the testing status to the project team. 

Participate on CCB.
 
    
     Testers Responsible for performing the actual system 
testing. 
    
     Payroll Department Manager Serves as Liaison between 
Payroll department and project team. He/she will help 
coordinate the Beta and User Acceptance testing efforts. 
Participate on CCB. 
    
     Payroll Clerks Will assist in performing the Beta and 
User Acceptance testing. 

 

9.       Deliverables
Deliverable Responsibility Completion Date 
      
Develop Test cases Testers 6/11/98 
      
Test Case Review Test Lead, Dev. Lead, Testers 6/12/98 
      
Develop Automated test suites Testers 7/01/98 
      
Requirements Validation Matrix Test Lead 6/16/98 
      
Obtain User ids and Passwords for payroll system/database 
Test Lead 5/27/98 
      
Execute manual and automated tests Testers & Test Lead 
8/26/98 
      
Complete Defect Reports Everyone testing the product On-
going 
      
Document and communicate test status/coverage Test Lead 
Weekly 
      
Execute Beta tests Payroll Department Clerks 8/18/98 
      
Document and communicate Beta test status/coverage Payroll 
Department Manager 8/18/98 
      
Execute User Acceptance tests Payroll Department Clerks 
9/03/98 
      
Document and communicate Acceptance test status/coverage 
Payroll Department Manager 9/03/98 
      
Final Test Summary Report Test Lead 9/05/98 

  

10. Suspension / Exit Criteria
If any defects are found which seriously impact the test 
progress, the QA manager may choose to

Suspend testing. Criteria that will justify test suspension 
are:

§         Hardware/software is not available at the times 
indicated in the project schedule.

§         Source code contains one or more critical 
defects, which seriously prevents or limits testing 
progress.

§         Assigned test resources are not available when 
needed by the test team.

11.    Resumption Criteria
If testing is suspended, resumption will only occur when 
the problem(s) that caused the suspension has been 
resolved. When a critical defect is the cause of the 
suspension, the “FIX” must be verified by the test 
department before testing is resumed.

12.    Dependencies
12.1  Personnel Dependencies
The test team requires experience testers to develop, 
perform and validate tests.

 The test team will also need the following resources 
available: Application developers and Payroll Clerks.

12.2  Software Dependencies
The source code must be unit tested and provided within the 
scheduled time outlined in the Project Schedule.

12.3 Hardware Dependencies
The Mainframe, 10 PCs (with specified hardware/software) as 
well as the LAN environment need to be available during 
normal working hours. Any downtime will affect the test 
schedule.

12.3  Test Data & Database
Test data (mock employee information) & database should 
also be made available to the testers for use during 
testing.

13.    Risks
13.1. Schedule
The schedule for each phase is very aggressive and could 
affect testing. A slip in the schedule in one of the other 
phases could result in a subsequent slip in the test phase. 
Close project management is crucial to meeting the 
forecasted completion date.

13.2. Technical
Since this is a new payroll system, in the event of a 
failure the old system can be used. We will run our test in 
parallel with the production system so that there is no 
downtime of the current system. 

13.3. Management
            Management support is required so when the 
project falls behind, the test schedule does not

get squeezed to make up for the delay. Management can 
reduce the risk of delays by supporting the test team 
throughout the testing phase and assigning people to this 
project with the required skills set. 

13.4. Personnel
Due to the aggressive schedule, it is very important to 
have experienced testers on this project. Unexpected 
turnovers can impact the schedule. If attrition does 
happen, all efforts must be made to replace the experienced 
individual

13.5 Requirements
The test plan and test schedule are based on the current 
Requirements Document. Any changes to the requirements 
could affect the test schedule and will need to be approved 
by the CCB.

14. Tools
The Acme Automated test tool will be used to help test the 
new payroll system. We have the licensed product onsite and 
installed. All of the testers have been trained on the use 
of this test tool.

15. Documentation
The following documentation will be available at the end of 
the test phase:

§         Test Plan

§         Test Cases

§         Test Case review

§         Requirements Validation Matrix

§         Defect reports

§         Final Test Summary Report

  

16. Approvals
   

Name (Print) Signature Date 
      
1.     
      
2.     
      
3.     
      
4.     
      
5.     

  
  

Pages
LOADRUNNER TUTORIAL 
MORE QUESTIONS 
RATIONAL CLEARQUEST 
RESUME (Sample) 
TEST CASE (Sample) 
TEST ENVIRONMENTS 
TEST PLAN (Sample) 
TESTDIRECTOR TUTORIAL 
TRACEABILITY MATRIX (Sample) 
USE CASE (Sample) 
Archives
January 2007 
Categories
Software Testing (1) 
Meta
Register 
Login 
Valid XHTML 
XFN 
WordPress 

------------------------------------------------------------
--------------------

If the tester thinks that is not a valid defect after 
loging and before sending it to developer, tester can close 
the defect by adding a comment saying "User Error" so this 
defect can be closed. 
We dont need to store any where once the defect is opened 
it will be there in your defects list.

If the defect is send to dev then it will be rejected then 
tester can close it.

Invalid defect should be tracked,thus it will help the 
seniors(Lead/Manager)to identify the number of invalid 
issues,it will further help the management/senior for 
training programmes for the testers, pls correct me if i am 
wrong.

In Design Phase

No Need to wait till Design Phase
Should approach In Analysis Phase 
or prior to it.

During Requirement Analysis phase/after the requirement 
verification has been done.

Weekly Status Reports:

Overall activities Status RED/AMBER/GREEN

1. Title
2. Activities Planned this week:

3. Activities Completed this week:
    - Sr. No
    - Description
    - Planned Start Date
    - Actual Start Date
    - Planned End Date
    - Actual End Date
    - % Compled
    - Status
4. Activities in Progress 
    - Sr. No
    - Description
    - Planned Start Date
    - Actual Start Date
    - Planned End Date
    - Actual End Date
    - % Compled
    - Status
5.Activities planned next week:

6. Defect Matrix
    - No of defects
      i) New
      ii) Open
      iii) Closed
      iv) Deferred
       v) Rejected

7. Risks and Issues if any


Monthly Status report is a high level report
Overall activities Status RED/AMBER/GREEN
1. Activities Planned
2. Activities Completed
3. Activities In Progress
4. Activities Planned Next
5. Risks and Issues

hi rahul 
can explain with example it is useful to me........pls
thnks

Rahul answer is good !!!

To my knowledge the entire TestCase should be Failed. No 
doubt about it.

i think this this test case will failed because we are not
complete 10 step and if 1 step is incomplete then test case
also failed.

The status of test case is fail, because if the required 
tab is not functioning means how can we continue the test 
and hence the status is fail and priority of resolving bug 
is also high.


Naresh
Test Engg.

well,the status of test case is fail,becz if one line is 
missing, and we are not able to execute any step then we 
are not completed, so in this situation, test is fail.

its definately failed.

Status of the test case is fail.
If required tab is not available, you are not getting the
actual results in the test case.So that test case is fail.

Here Our Expected result is 10 steps if step 5 is mismatch 
then the expected result will not be equl to the actul 
result.so Status fail.
If requre tab is not available then status will be fail.

If u r thinking about any application point of view, the 
basic risks would include the following :

1. Critical Defects may be found @ later stages of Testing.
2. Time and Schedule is important concern.
3. If it is a New Application for which u r writing Test 
Plan, the Risk may be like QA resources are still learning 
the application and may need more time to find critical 
defects.
4. Modules with Low risk may be not be tested @ later 
levels.

Their r many risks to point out if u r writing a Test Plan 
for an Enhancement related to a Product.

Do let me know if u come across any doubts....

Environemntal risk.

what is meant by qtp

QTP means Quick Test Processing. It is one of the tool in 
automation  testing.

Hi

   QTP means 'Quick Test Proffesional'.

QTP -'Quick Test Proffesional'.it is the automation tool 
for executing test scripts.it uses vb-scipt concept. and 
support .net,java,vb,all web application API,Activex-
control,mobile application,wireless & other areas..