Here is a sanitized version of an interesting email conversation.
Everyone involved worked for the same company, but for different product lines (Product A and Product B).
Product B was used to track bugs, and included a new snap facility for attaching screenshots to Issue Reports. QAers involved with Product A used Product B internally.
A member of the Product A team concluded that Product B was buggy and shouldn't be used. He even recommended using a competitor's product! As you will read, he was a bit hasty in his conclusions.
--------------------------------------------------------------------------------
From: [Product A Architect]
Sent: Tuesday, June 27, 2006 1:17 PM
To: [QA]
Cc: [Product B Developer]
Subject: Images in [Product B] are very large
Most of the new issue I am seeing require long waits to show images that should be quite small but are being delivered as 1000x1000 (approx) BMP files.
I suspect this is the new screen snap facility in [Product B].
PLEASE don’t use this facility as it is buggy, seems to product HUGE files and probably takes up large amounts of db space. Perhaps I am wrong and this is simply a rendering technique in [Product B], but it does not look like it. If this is not due to the Product B and you are just pasting huge image files PLEASE stop.
I would suggest you start using [Competitor’s Product] for screen shots. It is fast, stable, cheap, allows time taken banners and very impressive in cabability.
[Product A Architect]
Development Manager / Software Architect
--------------------------------------------------------------------------------
From: [Product B Development Manager]
Sent: Tuesday, June 27, 2006 11:52 PM
To: [Product A Architect]
Cc: [QA]; [Product A Development Manager]; [Product B Developer]
Subject: FW: Images in [Product B] are very large
Hi [Product A Architect],
I understand your concern about image sizing and we are looking at this now. Thank you for raising this issue.
Could you please clarify what particular are of the most of your concern when you wrote, “PLEASE don’t use this facility as it is buggy?”
Thanks,
[Product B Development Manager]
--------------------------------------------------------------------------------
From: [Product A Architect]
Sent: Wednesday, June 28, 2006 1:15 PM
To: [Product B Development Manager]
Cc: [QA]; [Product A Development Manager]; [Product B Developer]
Subject: RE: Images in [Product B] are very large
:o)
Wouldn’t you call the creation of full screen images in BMP format (the most inefficient format available) when snapping small sections of image resulting in download waits long enough to prevent common use a bug?
Until that very significant problem is addressed, I would FAR prefer that our QA staff (for [Product A] anyway) not use the facility at all rather than produce unusable and space consuming images. A good screen capture facility is very inexpensive.
I have no specific complaints beyond that.
--------------------------------------------------------------------------------
From: Strazzere, Joe
Sent: Wednesday, June 28, 2006 6:36 AM
To: [Product A Architect]; [Product B Development Manager]
Cc: [QA]; [Product A Development Manager]; [Product B Developer]l; [Product Manager]
Subject: RE: Images in [Product B] are very large
The snap screen facility can indeed produce BMP files, but produces JPG files by default.
I haven’t seen that they are any larger than JPGs produced by other tools. Nor have I seen where it “takes up large amounts of db space”.
If there are bugs, someone should write Issue Reports, rather than just telling people not to use it because “it is buggy”.
The new snap screen feature is part of [Product B], and is now a shipping product.
-joe
--------------------------------------------------------------------------------
From: [Product A Architect]
Sent: Wednesday, June 28, 2006 1:27 PM
To: Strazzere, Joe; [Product B Development Manager]
Cc: [QA]; [Product A Development Manager]; [Product B Developer]l; [Product Manager]
Subject: RE: Images in [Product B] are very large
Perhaps this is just [An individual QAer’s] use of the tool? There is quite certainly a problem somewhere even if you are unaware of it’s existence. If I use a tool and find specific problems, I will forward the specifics to the folks who seem to be using it.
[Product B] is not a tool I work on and I am not involved in the QA or development of it. Like ANY other tool in use for development, if there is a problem in deployment, I will halt use of particular features of the product if it is causing problems. I quite frankly don’t care in the least who supplied the tool: if it does not work, I will ask those using it to stop the process that does not work. We will NOT continue to use it pending an issue resolution just because it is internal product. This is about effective management of a development process for [Product A] and not about the development process of the tool in use.
I do understand the concerns and needs of the [Product B] team, but since this thread exists, they do know about the problem I sensed within the product. If that perceived problem is resolved quickly or is based on a faulty understanding or the use of a separate tool by particular individuals, then we can resume use of that feature. Until the problem is isolated, please refrain from using the snap screen facility for [Product A] bugs since at this time it appears to have some problems.
--------------------------------------------------------------------------------
From: Strazzere, Joe
Sent: Wednesday, June 28, 2006 1:33 PM
To: [Product A Architect]; [Product B Development Manager]
Cc: [QA]; [Product A Development Manager]; [Product B Developer]l; [Product Manager]
Subject: RE: Images in [Product B] are very large
You are correct in your conclusion that some images attached to some Issues are overly-large.
You are incorrect in your conclusion that the snap screen facility is buggy.
[The individual QAer] was using MS-Paint, not snap screen.
-joe
