Reporting Audit

[andyb789]

A common question i get from the developers and testers is "whats changed" when i give them an updated use case specification. Before EA they were used to receiving word docs with track changes. I've tried a few different methods but none completely satisfactory. Any suggestions?

Methods tried:

1. Switch Audit on and view the audit logs. The problem with this is there is so much of it and the Structured Specification for the Use Case is displayed as xml content.

2. Use the RTF Generator to output the audit log. The problem with this is it doesn't report the structured scenarios and if multiple changes to the same element have been made there is no clear before and after picture.

3. Create a basic rtf document before and after the changes with no tables and use the windows compare feature. This is the closest I've got to achieving my needs.

4. Use the Advanced reporting features of EA with sql  to create a custom field (I haven't got this working yet - if anyone has please send me the sql / script)

Thanks...Andy

[qwerty]

I taught to attach a change element to a use case. Using a simple diff is not enough since a change has a motivation which is not to be found by looking at differences. Additionally a profile was used that added tags to the change element to track responsibilities.

q.

[andyb789]

Thanks, I hadn't thought about it from a motivational perspective

[shimon]

I taught to attach a change element to a use case. Using a simple diff is not enough since a change has a motivation which is not to be found by looking at differences. Additionally a profile was used that added tags to the change element to track responsibilities.

q.

Nice idea  

[Eve]

Do package baselines help?

[andyb789]

Baselines don't really help for use case scenarios because there is too much metadata in there, here is an example:

BASELINE BEFORE CHANGE:

      <step name="Example use case step 1" guid="{6E8DD683-0D2C-40fc-B048-BA18D6820208}" level="1" uses="" useslist="" result="" state="" trigger="1" link=""/>
      <step name="Example use case step 2" guid="{EE69FE86-CCDF-460b-8639-4B09C2579EE5}" level="2" uses="" useslist="" result="" state="" trigger="0" link=""/>
      <step name="Example use case step 3" guid="{1341AA7C-4E24-4c50-BB13-C1E2B6E0D4BA}" level="3" uses="" useslist="" result="" state="" trigger="1" link=""/>

BASELINE AFTER CHANGE:

      <step name="Example use case step 1" guid="{6E8DD683-0D2C-40fc-B048-BA18D6820208}" level="1" uses="" useslist="" result="" state="" trigger="1" link=""/>
      <step name="Example use case step 2 CHANGED" guid="{EE69FE86-CCDF-460b-8639-4B09C2579EE5}" level="2" uses="" useslist="" result="" state="" trigger="0" link=""/>
      <step name="Example use case step 3" guid="{1341AA7C-4E24-4c50-BB13-C1E2B6E0D4BA}" level="3" uses="" useslist="" result="" state="" trigger="1" link=""/>

If there was a way of supressing the metadata then this would by useable

[Stefan Bolleininger]

Dear Andy,

for some of my companies I handled such "changes" by using the element status.
I use an Add-in to handle the "OnContextItemModified"-Event and set the element-status to "changed" if is has been edited.
By serching the "changed" elements I can give-out a list of suspected elements, which have to be checked.

You can also use some taggedvalue for this logging if you use the status for another reason.

The code for this events is somewhere within the forum. I guess I posted it, else you may write me an email.

Regards

Stefan