http://www.onestopsoftwaretesting.

com/tr
aceability-matrix-complete-guide/
Traceability Matrix – Complete Guide
Sponsored Links:

Traceability Matrix – A document

showing the relationship between Test Requirements and Test Cases. From
Traceability Matrix, we can check that which requirements are covered in which
test cases and "particular test case covers which requirements".

In this matrix, we can also cover that a particular requirement is covered in

which section of code etc.

In this matrix, the rows will have the requirements. For every document {HLD,
LLD etc}, there will be a separate column. So, in every cell, we need to state,
what section in HLD addresses a particular requirement. Ideally, if every
requirement is addressed in every single document, all the individual cells must
have valid section ids or names filled in. Then we know that every requirement
is addressed. In case of any missing of requirement, we need to go back to the
document and correct it, so that it addressed the requirement.

In a nutshell, requirements traceability is the process of ensuring that one or

more test cases address each requirement.

Example of a Traceability Matrix document:

Req ID Req Description TC001 TC002 TC003
R1.1 ……… Yes Yes
R1.2 ………. Yes
R2.1 ……. Yes

Example of a Traceability Matrix document:

Req ID Req Description TC001 TC002 TC003
R1.1 ……… Yes Yes
R1.2 ………. Yes
R2.1 ……. Yes

Above table shows –

Requirement R1.1 is covered in TC001 and TC003.
R1.2 is covered in TC001.
R2.1 is covered in TC002

Above table also provides the test coverage. Fron Traceability Matrix document,
we can ensure that all the requirements are addressed in the test cases. More
science behind traceability matrix can be found at Software Testing Times (See
below links).

Source Description Tutorial Link

Here wikipedia gives a
complete theoretical information about
WikiPedia Traceability matrix
traceability Matrix. – A Must
- as per wiki
Read for beginners
Traceability Matrix from
Software Testing perspective. This is a very
helpful topic for test
Software Testing leads and managers (also for junior testers if Traceability Matrix
Times they want to grow). It is from Software Testing
a step by step guide to prepare Traceability perspective
Matrix with attached sample
template.
Crosstalk – A
Andrew Kannenberg, Garmin
Journal of Why Software
International Dr. Hossein Saiedian, The
Defence Software Requirements Traceability
University of Kansas
Engineering Remains a Challenge

Re: Why Should we prepare traceability matrix? Answer

#8
RTM is useful for mapping between the requirements
and test
cases. and also useful for each and every phases of
testing
activities.

Among from the we can refer all the requirments are

covered.

Answer 2: A RTM(Requirement Treacibility matrix) is a

matrix
(generally maintained in an excel sheet) that maps
the
usecases in BRD, technical spec, functional spec and
the
testcases we have written..
When this is done, it would be easy for us to
determine the
gaps...
it helps for gap analysis

Traceability Matrix in Quality Center

***********************************
How will we prepare traceability matrix in QC....

Login into QC-Tools -> Trace All Changes.

Depending upon the filter you choose, bidirectional traceability can be achieved.

Forward

Backward

Bidirectional...

Requirement Coverage:

Priority and severity issues:

Business Components(BPT)
*************************

Generally, business components are created and modified in Quality Centre by Subject
Matter Experts. However, you can use the Business Component Keyword View to create,
view, modify, and debug a business component in QTP, if required.

In the Keyword View, business components are divided into steps in a modular,
keyword-driven, table format. Each step is a row that comprises individual parts that you
can easily modify. You create and modify steps by selecting items and operations and
entering additional information, as required.

Each step in a business component is automatically documented as you complete it. This
enables you to view a description of the step in understandable sentences. In addition, if
you added a function library to the application area associated with the business
component, when you define a step by selecting a user-defined operation (function), the
documentation that you added in the function library will be displayed for the step.

Before you create or open a business component, you connect QTP to a Quality Centre
project, which is where business components and application area resources and settings
are stored. Connecting to your Quality Centre project enables QTP to create or open the
business component. This also enables the business component to access all of the
resources defined in the application area on which the component is based.

Important Note: Make sure you have the required Quality Centre permissions before
working with business components and application areas.

If the application area you select does not yet contain all of the required resources and
settings, you can still add steps using the ManualStep function or the Comment option.
This enables you to type in manual steps as you would in Quality Centre or in another
application, such as Microsoft Excel or Microsoft Word. You can also use comments to
add information about a step or to separate sections of your business component. Each
manual step and comment appears as a separate row in the Keyword View.
If you want to delete a component, you can do so only in Quality Centre, regardless of
whether it was created in QTP or in Quality Centre.

Also, if needed, you can convert a business component to a scripted component.

**********************************************************************

Test execution without test cases is called 'Exploratory Testing' and 'Ad-hoc Testing'.

'Exploratory Testing' is described as a simultaneous learning, test design, and test

execution. This technique does not require significant advanced planning and does not
require documentation. Generally, testers that perform 'Exploratory Testing' are
learning the application, testing the applicaton, and designing test cases for future use all
at the same time.

'Ad-hoc Testing' is similar to exploratory testing in that they are not executing test cases
throughout their test efforts, yet it differs because testers generally have significant
understanding of the software during this process. They have likely already executed
their functional test cases and have been asked to be creative and 'go off the beaten path'
in an effort to uncover defects that more formal, structured tests would not find.

2.
Test Scenarios are at high level derived from use/cases and other functional points
mentioned in the requirements specification.

We can carry out execution with these but not to a detailed level. As a single scenario is
normally broken down to multiple test cases.

Hence testing based on just a scenario will just check the basic functionality missing out
on the details.

e.g of a scenario: 'Only valid user should be authorized to access application XYZ'

For the above scenario we will just test the login of application with valid user A and
invalid user B without going into detailed testing of the logon screen unless and until we
don't have all possible combinations of test cases for the scenario.

Scenario testing is a software testing activity that uses scenario tests, or simply
scenarios, which are based on a hypothetical story to help a person think through a
complex problem or system for a testing environment. The ideal scenario has five key
characteristics: it is (a) a story that is (b) motivating, (c) credible, (d) complex, and (e)
easy to evaluate[1]. These tests are usually different from test cases in that test cases are
single steps whereas scenarios cover a number of steps. Test suites and scenarios can be
used in concert for complete system testing.

RE: What is the difference between bug priority & bug severity?
priority defines how fast the bug should be resolved where as the severity defines how
severe the bug it is.It can be known by the extent of negative impact on the related and
other functionalities

Re: Difference between Severity & Priority? Answer

#4
Severit: how bad the defect and its reflect or imapact on
the s/w application with respect to the customer
requirement and on the user.severity given by the test
engineer.

Priority: How important the bug when it is to fix.It

shopuld be fixed on the basis of importancy of requirement.
Priority of the defect decide by the Developement team
member.

I can differenciate with example

suppose we identify two bugs
1. The client logo is not appearing on the web site but the
site is working fine... in this case the severity is low but
the priority is high because from company's reputation it is
most imp to resolve. After all the reputation wins more
clients and projects and hence increases revinue

2. The Qaurterly statement event is not triggering from the

website and we are just at the begining of the new quarter
after a new release.
In this case the Severity is High but priority cauld be low
becase we have time till the quarter ends to fix the bug

So the botemline is that in the priority v/s severity

matrix the priority is completely bussiness impact driven
and the severity is completely technical impact driven. :)

Hope this helps !!

***************************************************************
the diff will be more clear if u go for an example of Low
priority high severity and high priority low severity
1. low p high s :- suppose we have a link on our site that
is visited very rarely may be in once 1000 times on which
our system crashed that is High Severe because whole system
crashes but Low priority because Link is very rare.....
2. misspelled company name or missing logo from front page
have no impact on s/w functionality but having a worst
impact on company's goodwill so this is this case of high
Priority but Low severity........
i hope u will understand...