Tips for finding things that are broken in your program that you don’t know about?

Question

Today I was working on something for the client when I found a way to break some functions in our program.

(The code is really outdated code, it has been in development for about 10 years, and I have been working here for about a year.)

This did not cause an error or cause the program to crash, but if the user used the program and duplicated the behavior, I am sure that they will support their "WTF"? flag.

In our program, we named fields (text fields) and static texts (labels), which can be associated with text fields. When the text field is not filled with labels (s) that were associated with them, disappear.

The function I broke was when you change the name of a text field that already has one label or more associated with it, and save the file without re-linking one or more labels associated with the text field, -linked labels appear when the text box is empty.

Now I think that a simple observer pattern could solve this problem in the first place, but then I did not write the code.

I thought that if I could dig up more situations like this with the guys in my store, maybe I could discuss them with a look at unit testing, decoupling, applying the patterns in which they are called, and the like.

Therefore, for this reason, I was wondering if anyone has any tips on finding functionality related to violations (but not errors) in any application (website, desktop, etc.)

Answer 1

For the convenience of using the application, it requires a certain set of expected actions.

"Is this SUPPOSED text box doing nothing when I press enter?" Perhaps this is possible, perhaps this is not so. I saw applications in which the tester / reviewer reports something that they SHOULD work in a different way, when in fact the client specifically asked that they DO NOT want the form presented on the return key to press, but only the submit button.

So, you must determine the right behavior before you can determine the wrong behavior.

Answer 2

Hire some testers .

Answer 3

If it has an interface, then one of my favorite unconventional tests poses 5-10 year old children. You will be surprised what they can come up with (especially the younger ones). Although this may sound like a joke, it is not - it really works, because children do not have thinking only along the path of "thinking."

And yes, children are experts in the "breaking things" xP.

Answer 4

Checking the code, that is, reading the source code: if you spent time reading / checking the source code, searching for "smells" or even just looking for code whose behavior you do not immediately understand and agree, can you support your "WTF"? flag too.

Answer 5

Test, test, test.

Do unexpected things. Start doing one task and switch another to see if something is coming. Use the back button when you shouldn't. Open it in two windows. Give him time.

Test in all browsers, especially in IE.

Answer 6

You may find database connections / sessions not released:

• making the minimum number of connections you need to complete
• setting resource limits for this minimum number
• providing one "start" of the script that should use this particular number (and release it later)
• then run it a few times ... have you ended the connection?

I used to work for a company where programmers regularly used to forget about disconnecting db connections. The standard answer was to keep the resource to a minimum, to see if there was a leak, and try to figure out where it was by restarting the system and repeating different scenarios.

Answer 7

The first hour of code review, with the first reviewer, will do everything possible to find quality problems. But here's the thing: you don’t need to convince people of quality problems. You need to convince them of the importance of error correction and rewriting only when the true quality absolutely justifies it.

I used to deal with serious bad code. But you cannot just rewrite. You need a specification before you can even tell whether rewriting is an improvement.

Sometimes you have to get the specification out of code and then test it on some person. But by the time you have done this, you understand the code as written and are now better prepared for repair than rewriting - most of the time.

Repair continues through a process of small modifications that preserve behavior that makes the specification more understandable in code. Then, when you find something wrong, you are not just changing it. You ask until you find the person responsible for this decision, and you get them to show you where the specification says that the behavior of X is correct. (This conversation can take many forms.) If you are lucky, they will tell you that the behavior of X is actually wrong, and you earned your salary.

Answer 8

claim () Also unit testing with coverage analysis.

Answer 9

This is especially true for the Visual Studio IDE, although this probably also applies to others:

During testing, it always starts at some point in the debugger with the inclusion of "Break when an exception is thrown."

This often helps to identify exceptions that are incorrectly masked and constitute errors, but may not be obvious otherwise.

Answer 10

Code reviews should always include unit test code reviews.

The problem is that with special testing it is impossible to know how or how well the developer tested his code. So, you are at the mercy of different developers, define the word "done".

If you include unit test code reviews at the same time as you review production code, you should be aware of whether the code is indeed complete; in that "full" includes "verified." Not just "Hey, I'll throw it through the wall to the testers!".