I also think the letter drives home the point (whether this was intentional, I don't know) that as testers, a significant aspect of our job is to question. If we encounter behavior we don't understand, we question it. It doesn't always mean we "don't like" the behavior or think it's "bad" or even "wrong." We might simply be questioning whether what we found was the intended behavior.

Thank you for your answer. Up until now I wasn't aware, that users of your/this software required knowledge of fundamentals of windows programming.

I think you should start warn users about this prior to downloading it, so it will only be operated by qualified personnel. Perhaps you do, but I don't remember seeing it. Maybe it could be emphasized more.

I am happy to know that you monitor usage for this specific behaviour. That hints to me, that you're to some extent aware that there might be a problem here, otherwise, why monitor it ? Of course it may be so, that your usage monitoring is targeted at something else, and only as an extra outcome, unintentionally actually, you can see when this 'issue' comes up. I have no idea of knowing; I trust you do your best efforts.

However, I agree with my colleague that your answer doesn't target the point: that data is in fact lost and that the consequences are perhaps not quite understood and predictable. Be that as it may – as this is not a real bug report, but a debate, in which the product in question could have been just about any product.
The interesting part is your keen dismissal, which I think could not have been constructed in a more precise and illustrative way; thank you for that.

All over the world developers answer bug reports and complains in this fashion: without targeting the bug, it's dismissed by use of
- it's old news (been in our forum)
- not intelligent/skilled use ('anyone familiar…')
- wrong forum/procedure (please use bug database…)
- not happening frequently enough ('users generally don't hit this issue')
- uprising the design to be flawless ('it's by design').

Besides the obvious arrogant part of the dismissal, it's exposing something even more daunting:
- you knew it and didn't handle it!
- your process is ignoring stuff you might pick up, because it didn't come through the right channels (like a radio distress call: "we're drowning" -> "please send in a form in three copies on the right kind of paper")
- using a low frequency to evaluate a risk, while a risk is a product of both frequency and impact. Ignoring a huge impact because of a low frequency can potentially be fatal. In this case: a hacker needs only one day to gain access. It'll show in your statistics, but ..
- ignoring that designs, however well constructed and manufactured, are never flawless is dangerous. The bug might point exactly this out. The argument is vague: "it doesn't work" – "but it's how we designed it" = "you might have designed it wrong".

In the end it always turns out so, that its never a competition as to who are best at running projects and maintenance procedures, interpreting contracts, designs, requirements and all – but simply a question of whether the product survives the usage of the users, who are lawfully ignorant of all those matters.

Kind regards,
Another Tester

In your post you outline a lot of different reasons why the bug occur.

As you say: “it might be good idea to seek an explanation.”

I’m not sure it always efficient to seek an explanation. The main reason to seek explanation, as tester, is to identify more possible defects in the surroundings of the first bug. On the other hand it could be time consuming to seek explanation. Off course, as you say, most of the possible explanations should have been eliminated by the developer throughout unit test/checks.

If you have a test team with a lot of experienced tester hunting bugs you have to make sure they are using their time in the best way. I’m thinking that applying “Lean thinking” could help to locate waste in the test process. I might be that seeking explanation could be a waste. Sometimes it will be necessary (and profitable) to dig very deep into the bugs, sometimes not.

… I think it might be important, though, for us to understand why the problem is there in the first place. That's because I don't know whether the problem that I'm seeing is a big deal. And the thing is, until you've looked at the code, neither do you…

If we look at developers and testers as one team working close together things will be much more efficient. The time from finding a bug to report and fix will most of the time be shortened.

Concerning bugs, it is always discussions about priority and importance. The tester may think the bug is an A-rated since he cannot perform more tests in that specific area until it is fixed. The developer may think it is C-rated since it is a very small bug not affecting something important. The project management is looking at customer value and thinks the bug is D-rated since it has very low customer impact.

To be able to rate bugs correct I think it is necessary to have bug rating meetings with the appropriate people (developers, tester, project, market). This may sound obvious but working as consultant in many different environments I can say this is not always the case.

I think it is important to have these meetings before the bug is reported into any tracking system.

/Daniel Åberg

I'm glad you've looked into some of the specifics of the problem. That is, to my mind, responsible and capable technical work. Quick, too. But I'm not sure you've addressed the bug itself.

The 32768 limit – as anyone familiar with the basic fundamentals of windows programming knows, is the windows limit on characters in a standard text box. We could (I suppose) have added logic to limit the text to match with our api, but the _less_buggy_ approach was to simply let windows handle the text in the normal manner.

As anyone familiar with the basic fundamentals of Windows programming knows, you can also constrain the input from an edit control by sending the edit control the EM_SETLIMITTEXT message. The current approach isn't any less buggy, since the bug is that not all of the text being sent gets across AND there's no notice of that. Data disappears without explanation and apparent awareness of it. In addition, we don't know from the outside whether the edit box's memory is coming from Windows' heap or ours, or how that memory is being managed.

But all that is actually beside the point. You'll appreciate, I hope, that the specifics of the Skype bug was to provide an example—something that people reading the blog post could reproduce easily. You'll also recognize, as I said at the very beginning of the post, that I put a ton more detail into the letter to the programmer than I would put into an ordinary bug report. My point was not to expose a bug in Skype, but rather to give an example of some of the kinds of thinking that testers need to consider (in my view, at least) when reflecting on a bug that seems, from the outside, trivial. Your answer is of the exact kind that would prompt my letter, rather than one that would address it.

…someone who looks at "bugs" with a different lens than you do.

I'm glad that you look at bugs through a different lens. We need all kinds of them, from telescopes to microscopes to contact lenses to fisheyes to fresnels, the better to choose what we're going to find and fix.

Any notions about that second bug?

—Michael B.

Someone asked this in our forums (in a much more concise manner) –
http://forum.skype.com/lofiversion/index.php/t68833.html

The 32768 limit – as anyone familiar with the basic fundamentals of windows programming knows, is the windows limit on characters in a standard text box. We could (I suppose) have added logic to limit the text to match with our api, but the _less_buggy_ approach was to simply let windows handle the text in the normal manner. We monitor usage, and except for a brief, tiny spike last week, users generally don't hit this "issue"

Also, please consider using our bug database in the future – https://developer.skype.com/jira/browse/SPA

-Not really a skype developer – just someone who looks at "bugs" with a different lens than you do.