Software Testing - simple traceabiltiy document to track functoinal changes

Author

simple traceabiltiy document to track functoinal changes

smandelster@gmail.com

2006-01-10, 4:17 am

We are a small travel technology company with about 7 developers and 2
QA staff. We are proponents of the Agile SDLC and do code reviews, etc
and are a java shop for the most part, but also use XML data services
and .NET.

I would like to create a document that traces any functional changes
that may impede upon other classes/functions, etc to have developers
fill out and include in the code review process and QA will use this as
a guide of things to put extra focus on during regression testing.

I want the document to be simple and general so as to not be too
complicated and time consuming, but I also would like it to be useful
both to the development and QA teams. Do you have any ideas of what I
might be referring to or can you point me in the right direction?

I think I'm referring to a traceability matrix, but I feel that that
might be a bit much to require developers to update for every change,
in our fast-paced environment and may not prove helpful or effective.

I'm thinking more of a checklist, i.e. Function(s) concerned?,
Framework change?, DB change?, classes affected? etc.

Any ideas as to the name of such a document or any examples would be
greatly appreciated.

thank you in advance,

Steve

Michael Bolton

2006-01-10, 4:17 am

>I would like to create a document that traces any functional changes
that may impede upon other classes/functions, etc to have developers
fill out and include in the code review process and QA will use this as
a guide of things to put extra focus on during regression testing.

Conversations? A wiki? A dump from your source management tool? A
table in Excel that contains the columns that you specify in your
original post ("Function(s) concerned?, Framework change?, DB change?,
classes affected? etc.")

---Michael B.

Phlip

2006-01-10, 4:17 am

Michael Bolton wrote:

> that may impede upon other classes/functions, etc to have developers
> fill out and include in the code review process and QA will use this as
> a guide of things to put extra focus on during regression testing.
>
> Conversations? A wiki? A dump from your source management tool? A
> table in Excel that contains the columns that you specify in your
> original post ("Function(s) concerned?, Framework change?, DB change?,
> classes affected? etc.")

Passing all tests before you commit your changes, so you already know the
other stuff works?

--
Phlip
[url]http://www.greencheese.org/Z

Land[/url] <-- NOT a blog!!!

shelley@osel.netkonect.co.uk

2006-01-10, 4:17 am

I've seen testers use an 'interaction diagram':

This is a simply a diagram that has the changed function/class at the
centre and all affected functions around it - often with predecessors
at the top and sucessors underneath. The nature of the interfaces can
be described on the diagram.

Ad hoc annotation is usually added - but its the diagram that is rthe
useful part.

One diagram for each changed function/class or else it becomes
ambiguous. So if there are changes to four functions there will be four
interaction diagrams.

Simple, easy and surprisingly effective.

shelley@osel.netkonect.co.uk

2006-01-10, 4:17 am

I've seen testers use 'interaction diagrams'.

For any changed function or class a diagram is drawn that shows the
function surrounded by interacting functions - often with predecessors
above and sucessors below. The interfaces (lines) can be annotated to
explain or describe the interaction.

One diagram is drawn for each function/class changed - otherwise it
becomes ambiguous or confusing.

Its simple, quick and surprisingly effective.

Sponsored Links