>I probably should stop responding to this thread since we are not going
>anywhere with this. Yes, I am a musician since I was 10. My master's
>degree is in music composition, but I was a real QA since 1995 till 9-11
>happened. Micro$haft NetMeeting, Lycos parsing engine, and Amazon order
>parsing engine were few of the products I QAed as a subcontractor. I
>hope they are qualified commercial product :-)
They are indeed. But I wonder how the heck you ever got anything done
with the stringent, go for the jugular standard you appear to have used.
With a development team putting out perhaps a dozen or two builds in a
single day during crunch time, we barely had time to install before
another build came onto the server. We'd still be trying to confirm Bug
#23 of 1456 if we had to make a fresh start each time we detected
something :-)
>But we are not here to debate QA philosophy, and we are pretty close to
>pissing contest, which we should avoid (I guess I am guilty as charged as
>well).
Correct. Each to his own. The system I used worked for me and with
minimal effort. And as a regular customer, already without email
services 3 days out of 7, that is the way it should be. I like beta
testing... but only when it is a beta and I'm on the beta team :-)
>That's what I am used to. But again, we are talking this at the QA stand
>point of view, and you are right that you are not QAing PM. My point was
>that there are so many end users who know nothing about software dev and
>like to call something a bug too easily, and you and I know dev eng likes
>to come back to say "it's not a bug" by their trained behavior.
That is true. We used to get a line of BS from one programmer who
refused to call an error in his code a "bug" if the behavior was as
programmed, even if the code was an incorrect implementation of the
specs. We'd mark it as a bug, he'd say his code worked fine, and the bug
wouldn't get fixed. Thankfully he was terminated very shortly thereafter :-)
>Agreed, but where is the obvious?
>Here is your original post:
><<My system, for some unknown reason, occasionally crashes and shuts down
>when left unattended. It doesn't happen very often, but when it does
>PowerMail almost always boots up with something corrupted. <SNIP> But
>whatever the case is, my system is idle, PowerMail is idle, and only one
>or two idle applications are open (IE, SpamSeive, Excalibur). So why do
>I have PowerMail corruption problems so consistently?>>
I see this as plainly obvious. When there is a repeatable problem with
one particular piece of software you always look at that piece of
software FIRST, all other possibilities after. It might turn out to not
be a bug, rather some sort of conflict that is and of itself not the
program's fault. But the best way to figure this out is to look at the
program having the problem before investigating anything else. And that
worked for me because asking Jerome fixed the bulk of my problems without
spending fruitless hours screwing around with my system.
>I just realized you didn't say PM periodic mail check is disabled. It
>was hard to guess what you meant by idle.
I meant "idle", which is why I used that term very specifically. The
problem was you assumed I wasn't using it correctly. When in QA mode the
first thing I do when someone presents a bug report is clarify things.
Usually that clears up things before having to think of a potential
testing solution. Instead of launching into a Norton Utility conspiracy
theory... you could have instead asked me if I was sure the system was
idle and did I think of x, y, and z.
>M$Word periodically caches
>automatically. Do you still call it idle?
>:-)
I was unaware that Word caches when there is no user input for several
hours. I don't understand why it would. And even if it does, it writes
to temp files and therefore is safe from unexpected events.
>That's not what we have been saying. We have been saying we believe
>removing Norton is the first thing to try. If you don't feel that way,
>and are not willing to try our suggestion, our hands are up in the air.
Well, the suggestion wasn't logical. Not only was it the wrong place to
look first off, I'm not using 10.3.x. I see no evidence that the current
version of Norton is unstable with 10.2.8, which is what I am using. If
I were using 10.3.x *and* PM wasn't a logical place to start, then I'd
think you had a valid point.
>Lastly, if PM doesn't close some portion of the database, and a crash
>causes problem because of that, it still is not a bug. It can be bug
>only to programmer who specked, and for us, end user, it is called
>"feature request" for "crash proof behavior".
Correct. If the program is working as designed, but the design is below
the common standard, then it is called an engineering flaw. Much like a
bridge that is built to specs to the letter but collapses when there is a
strong cross wind. To the end user, me, it doesn't matter as I am
watching a back to back 16 hour rebuild and general system performance
hit. It just needs to get fixed. However, in this case Jerome has
already stated that this behavior should not be happening and therefore
it is correct to call the potential problem a bug.
Good news is that I was not able to reproduce the corrupt Search Index
problem today. It could be that I did not duplicate the conditions that
happened to me yesterday, like many times before, or it could be that my
Search Index had been functionally corrupt due to one of the other issues
Jerome fixed for me. And now that it has had a fresh rebuild with the
new build things are better. And I didn't spend 1/2 a day tearing apart
my system looking for red herrings. Not sure if it will corrupt again,
but if it does Jerome and I have a plan for how to deal with it (without
tearing apart my system first).
So the tally of problems so far is:
1. Runtime crashes and corruptions - fixed by using OS sounds and using
latest Beta.
2. Extensive and excessive rebuild times - not fixed, but not an issue
unless corruption starts up again.
3. Idle crashes and corruptions - jury is still out, but so far so good
and therefore I have hopes it will be like #2.
Since I've spent far more time arguing about how to approach identifying
bugs than actually finding them... I'll end with this email :-)
Steve
