posted 07-02-2002 11:43 AM         

I have used both in many, many situations - both with and without any real audit trails.

And, not to belabor the point, I have tested systems for which the end result was some form of file - a model file, a document file, a database, whatever. On more than one occasion, we have built regression tests which:
- start with an empty file
- drive the application through the regression steps
- check the resulting file for correctness

Unless you consider the resulting file (which had no time stamps) as an audit trail unto itself, then it was all done without any audit trail and worked quite nicely.

posted 07-02-2002 10:25 PM           

You must also have had a means of capturing online information to correlate file content to user activity.

posted 07-03-2002 03:45 AM         

quote:

---

Originally posted by wooks:
All files have timestamps. Date Created - Date Last modified, and especially since you are starting from an empty file then conceptually that most definitely constitutes some form of audit trail.

---

I think that's stretching the definition a bit! If the file's timestamp were missing or incorrect, would it no longer be an audit trail?

quote:

---

You must also have had a means of capturing online information to correlate file content to user activity.

---

You lost me there.
The test script is the user activity.
What "online information" must I capture?

posted 07-03-2002 04:02 AM           

a record of a sequence of events (as actions performed by a computer) from which a history may be reconstructed

i.e an audit trail.

If the test script is the user activity, then there must be things in the test script to facilitate the reconciliation of the user activity with the outcomes as per the file.

posted 07-03-2002 07:04 AM         

quote:

---

Originally posted by wooks:
Even if the files timestamp was missing the fact that it was known to be empty at the start of the test gives you an audit trail of activity from when the test started.
If it wasn't empty and had no timestamps if you baselined it you could diff it. That would give you

a record of a sequence of events (as actions performed by a computer) from which a history may be reconstructed

i.e an audit trail.

---

I guess we'll have to agree to disagree.
The files I have used do not indicate any sequence of events.

posted 07-03-2002 10:58 AM         

quote:

---

Originally posted by wooks:
does one record not follow another then?

---

If you are asking if the records in the file corresponded to the order in which objects were created - then no.

Imagine if you were testing a word processor, or a drawing tool, or a CAD system.
No real audit trail, but enough output that the file can be used to verify correctness after-the-fact.

posted 07-03-2002 11:31 PM           

Now where you start talking about graphical applications deferred checks are certainly not an attractive option because you will have huge storage requirements, but thats still worth noting that in your test architecture.

However given that testers are always complaining about not being given enough time and at changes impacting their work, one would have thought there would be a greater keeness to exploit the power and flexibility of deferred checking.

Specialist automation skills are required to capture information from GUI's, but once captured it does not require specialist skills to check it. This type of division of responsibility happens everywhere else in the IT industry. Further a script that only has to capture information can be made to be extremely robust.

So my conclusion. All things being equal (and they are more often than not) - deferred is the way to go.

posted 07-04-2002 03:37 AM         

- the possibility of two wrongs making a right

--------------------------------------------------------------------------------
This is just like shouting loudly to prove that its right

------------------
Dinesh

posted 07-04-2002 04:08 AM         

quote:

---

Originally posted by wooks:
Paradoxically one of the best tools I know of purely from the point of view of offering support for automation with deferred checking is WinRunner because of it's GUI Map.

---

???
Can you explain this a bit further?
I don't see any connection between a GUI Map and deferred checking.

posted 07-04-2002 05:01 AM           

Your deferred checks simply become comparisons against this repository and your automation scripts are insulated against change. If there are any changes to the screen all you have to do is generate a new GUI map. Finito.

The main thing mitigating against this approach is that WinRunner only allows for the most primitive of data structures. Ideally you'd want to persist the object attributes in some sort of structured format (not dissimilar to the way the GUI map itself is structured on presentation) to make life easier at the other end.

posted 07-04-2002 05:11 AM           

Get collection of all controls on screen
for each control in collection
persist all it's attributes
next

Tester could activate it at click of a button.

posted 07-04-2002 01:17 PM         

quote:

---

Originally posted by wooks:
In fact come to think of it what stops a developer from providing a component with the application that did just that

Get collection of all controls on screen
for each control in collection
persist all it's attributes
next

Tester could activate it at click of a button.

---

I guess if all you cared about were the attributes of GUI objects that would work. Not much of a test, though. The attributes could all be OK, but the functionality of the application under test could still be completely broken.

Still not sure how this all relates to the GUI Map, since the "Current" attributes aren't necessarily in the GUI Map, until you make them so.