[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[hyades-dev] Meeting Minutes from 2-May-2003 Execution Histories Model Subgroup meeting
|
Attached are the meeting minutes from
the 2-May-2003 Execution Histories Model Subgroup meeting. I have also
included it as in-line text. I apologize for the delay in sending this
out.
Regards,
ashish
------------------------------------------------------------------------
Ashish K. Mathur
IBM - SWG - Rational Division
Phone: (919)845-3213 Fax: (919)845-3250
Email: akmathur@xxxxxxxxxx
____________________________________
Execution Histories Model Subgroup,
2-May-2003
Attending
---------
Ashish Mathur
- IBM Rational Raleigh
Antony Miguel
- Scapa
Gian Franco Bonini
- SAP
Joe Toomey
- IBM Rational Lexington
Marcelo Paternostro
- IBM Toronto
Kent Siefkes
- IBM Rational Raleigh
Serge Lucio
- IBM Rational Lexington
Agenda
----------
1. How
are testcases referenced in their execution histories?
2. What properties of the ExecutionHistory
for a TestSuite do we need to store?
3. What properties of the TestCase do
we need to store in its ExecutionHistory?
4. What kind of events are needed to
be logged?
5. What kind of associations do we need
from the Execution History to the trace?
6. What kind of mappings are needed
between the logged and the behavior in the model if behavior is modeled?
7. Co-ordination with Richard's team
about logging events
8. Solicit team members from the trace
group
Recorded Discussion/Agreements
-----------------------------
1. The Execution history will record
information about each testcase that was executed,
including the version
number from change management system
2. A TestSuite does not have a verdict.
The individual test cases have verdicts. Hence
there is no requirement
to roll-up the verdicts from the TestCases to the TestSuite
3. An ExecutionHistory is separate from
any traces that are recorded when a TestCase
is executed. Created a
TPFExecutionResults class that could be associated with
multiple traces but exactly
one ExecutionHistory in the hyades model. Please check
the updated model in the
next drop.
4. The 'Test Events' (events logged
by the Test code) and the 'SUT Events' (events
logged by the SUT code)
should use the same API logging mechanism as the Logging
Events in Trace.
5. Upon running a testcase and recording
an ExecutionHistory, the TestCase itself is not
made 'dirty' (i.e. The
TestCase state is not changed from 'Saved' to 'Requires to be saved').
6. An ExecutionHistory and its Verdict
will be stored separately for each TestCase executed
in the TestSuite. There
is no requirement to store ExecutionHistory or the overall Verdict
for a TestSuite.
7. TestCase ExecutionHistory contains
-
Name
-
CM Version
-
Verdict
-
RunTime
Questions
--------------
1. Are the log events just another trace?
- Marcelo to check with Richard Duggan
2. Since the ExecutionHistory is stored
separately for each TestCase, there will be
a need to correlate an
execution result to a slice of the trace. Can this be done?
Not in Release 1? - Marcelo
to check with Richard Duggan
3. Does the ExecutionHistory need to
capture the version of the SUT? Or is this a task
of the deployment mechanism?
Action Items
-----------------
1. Check with Harm about a rep from
the trace group - Marcelo
2. Check with Richard about the above
questions - Marcelo
Execution Histores Model Subgroup, 2-May-2003
Attending
---------
Ashish Mathur - IBM Rational Raleigh
Antony Miguel - Scapa
Gian Franco Bonini - SAP
Joe Toomey - IBM Rational Lexington
Marcelo Paternostro - IBM Toronto
Kent Siefkes - IBM Rational Raleigh
Serge Lucio - IBM Rational Lexington
Agenda
----------
1. How are testcases referenced in their execution histories?
2. What properties of the ExecutionHistory for a TestSuite do we need to store?
3. What properties of the TestCase do we need to store in its ExecutionHistory?
4. What kind of events are needed to be logged?
5. What kind of associations do we need from the Execution History to the trace?
6. What kind of mappings are needed between the logged and the behavior in the model if behavior is modeled?
7. Co-ordination with Richard's team about logging events
8. Solicit team members from the trace group
Recorded Discussion/Agreements
-----------------------------
1. The Execution history will record information about each testcase that was executed,
including the version number from change management system
2. A TestSuite does not have a verdict. The individual test cases have verdicts. Hence
there is no requirement to roll-up the verdicts from the TestCases to the TestSuite
3. An ExecutionHistory is separate from any traces that are recorded when a TestCase
is executed. Created a TPFExecutionResults class that could be associated with
multiple traces but exactly one ExecutionHistory in the hyades model. Please check
the updated model in the next drop.
4. The 'Test Events' (events logged by the Test code) and the 'SUT Events' (events
logged by the SUT code) should use the same API logging mechanism as the Logging
Events in Trace.
5. Upon running a testcase and recording an ExecutionHistory, the TestCase itself is not
made 'dirty' (i.e. The TestCase state is not changeed from 'Saved' to 'Requires to be saved').
6. An ExecutionHistory and its Verdict will be stored separately for each TestCase executed
in the TestSuite. There is no requirement to store ExecutionHistory or the overall Verdict
for a TestSuite.
7. TestCase ExecutionHistory contains
- Name
- CM Version
- Verdict
- RunTime
Questions
--------------
1. Are the log events just another trace? - Marcelo to check with Richard Duggan
2. Since the ExecutionHistory is stored separately for each TestCase, there will be
a need to correlate an execution result to a slice of the trace. Can this be done?
Not in Rel 1? - Marcelo to check with Richard Duggan
3. Does the ExecutionHistory need to capture the version of the SUT? Or is this a task
of the deployment mechanism?
Action Items
-----------------
1. Check with Harm about a rep from the trace group - Marcelo
2. Check with Richard about the above questions - Marcelo