We have 1443 open issues for RAD Studio on https://quality.embarcadero.com/browse/RSP

We have 1443 open issues for RAD Studio on https://quality.embarcadero.com/browse/RSP

How can we help to solve them?
https://quality.embarcadero.com/browse/RSP

Comments

  1. Johan Bontes No I didn't! Your point is: "If it works for me, it is good" and this is not true at all. Some bugs only manifest themselves under very special circumstances not easily reproducible. But once the source of the bug is clearly visible, it should be fixed doesn't matter what QA team has to say about it. If QA team opinion is all that counts, let's just write every code inside a try..except..end block, and all your problems are solved! No visible bugs anymore! What do you think? I DO KNOW people/developer teams/companies that just ignore errors that are only visible to the final user (i.e. if you just trap the exception, everything is fine!). What do you think about it?
    People are trying to make software just like they make cars (yes, the old analogy here!) and this is stupid! And that's why 10 y.o. bugs are still around, and that's why each version introduces more and more bugs.

    ReplyDelete
  2. I'll give you just one more example: One day I was working for a company... each bug report was added to our bug track system. A QA team member was responsible for testing the report and decide if it was a real bug or something else. There was a real bad Access Violation happening in the application and I reported it, of course. A complete document explaining WHERE it happens, WHEN it happens and WHY it happens. I also included the solution: The developer should just add this: "if Assigned(MyInstance) then" before calling the method. The application was full of try..except..end blocks just trapping "unwanted" exceptions, and this was one of them. Once the QA member could NEVER see the exception happening, what do you think it happened after that? A) The QA decided to close it with the old "it works for me" shit, or B) The QA asked someone to give it a look?
    I think you know the answer. And based on the previous answer, there is another one:
    What do you think will happen to this AV? A) Will be fixed by itself, or B) Will come back to bite you again?

    ReplyDelete
  3. If I can (and have the time), I exemplify the bugs I find with actual code. My motivation for doing this is that the software is becoming increasingly complex and massively big, and the developer may have to work on someone else's code, which he/she did not design, and may not even have used - and actual code will then be very, very helpful. It also makes it possible for someone else to quickly verify that they see the same problem. Finally - once the problem is solved - the code will verify that as well.

    ReplyDelete

Post a Comment