I'm wondering from your experience, what is the most useful techniques for finding (or preventing) bugs? Or to ask this another way, how do rank these techniques in your own experience?
Expanded my answer here:
I'd rank them as:
Our company doesn't do continuous integration so I can not rank it.
I would rank them as :
Unit testing has had and always will have the biggest impact for me.
Everything else either doesn't work, breaks under stress or doesn't yield enough ROI.
During development I use a combination of test-driven development and static analysis of the code (e.g. QAC or QAC++).
One other thing:
Other things help but ultimately knowing what you trying to solve and not letting the drive to be "done" derail your train is the key.
Just my two cents.
I am a huge fan of code review, and from my experience, it is where we've seen the most bugs fixed. While doing a deferred code review by using tools like the new code review module in FogBugz is very helpful, I've seen a lot more bugs found (and epiphanies experienced) while doing in-person review.
For those doubting the power of code review, I highly recommend trying out the Rubber Duck Debugging technique (and hey, it works even better when your rubber duck is a fellow coder). Just going through your code while explaining it is a great way to spot logical errors and some mistakes. I added a small honourable mention at the end for static analysis tools, which may not be able to debug business logic, but it can be handy to spot simple mistakes and inefficiencies.
Preventing bugs:
Finding bugs:
While writing my own code
My most useful technique for finding bugs is using ASSERTs.
I have found many very subtle bugs (and also many not so subtle) this way. Bugs that would otherwise go unnoticed but nevertheless cause e.g. incorrect results. For instance only for particular kind of input. In many cases it would not have been possible to predict the existence of a bug, even with a lot of thinking.
ASSERTs are available in one form or the other in most environments. I have used them with C, C++, VB.NET, C#, Python and Perl. The action when an ASSERT evaluates to false does not necessarily have to be to quit the program. They can also be logged to a file or a dialog box is shown (stopping execution). The latter is the default for Visual Studio (desktop applications only?).
I love the ideas of IMVU and continuous deployment. Of course it requires a ton of automated testing, but also severely limits the impact of issues that do arise.
Here's the blog. Good stuff:
G'day,
As you debug, keep a record and then back out your fix to verify that you've properly fixed the problem.
This is the simplest thing that I have found that helps me to debug and make sure that I've fixed the problem.
Quite often it is not that last thing that fixed the problem but it can be a mixture of various effects. Performing this simple check will show you the actual fix.
HTH
cheers,
Preventing and finding bugs starts from the start of the project ebfore programmers start coding. The few things that everybody should keep n mind are as follows:
requirement analysis -> requirement should be analysed properly with the customers and if possible with the system engineers with developers and testers attending the same
brain storming between the developers and testers on how they understand the requirements
Plan to be done by both developers (Design) and testers (Test plan)
After coding the developer should start the Unit testing and the tester should help in giving new scenarios that are missing
Lastly the tester will start his testing alongwith developers
One thing we should keep in mind that it can't be eliminated but can be reduced with the joint approach of developers nad testers.
I wish I were as good at this as I should be, but here are methods I try to follow:
Since I cannot think of a bug that was not an incompletely-implemented feature, I try to minimize the number of separate editing steps needed to make forseeable changes. This involves esoteric tricks like differential execution, and other DSL-like techniques, but that comes at the cost of a learning curve.
Coverage. Coverage tools bother me, because they seem to be too hands-off. I try to insert in every routine and every branch statements that look like: COVTEST("name of routine", "some comment") and implement this in such a way that it records the fact that it has been executed (but only once). When the app finishes executing, the record of statements encountered is sent to a file. An external grep is done to find all such statements in the source code, and an external utility can generate a list of all such statements not yet executed. This directs me to test those parts of the code, and is very useful.
Monte-Carlo testing. I have a problem with unit-testing as it's widely understood. It seems to exist mainly to see that complex data structures aren't screwed up. My projects de-emphasize data structure and emphasize language, so the combinatorics of cases to consider can seem to be impossibly large. What I've found useful is to have a random problem generator, along with a parallel (but simpler and less efficient) implementation, to make up problems at random, run them, and compare the results. When this works well, the preponderance of bugs found gradually shifts from the product code to the test code.
These different methods address different possible errors, so no one of them is sufficient. In addition, I'm lucky to have very good (and patient) QE people who test the code, because every progammerer has blind spots to possible problems.
All the listed methods are valid points. There is nothing like testing your code thoroughly. Find all possible distinct scenarios you can think of testing. Good documentation also helps when the product is a software library or an api.
I believe that a wholistic answer to this not at all subjective question must explore different types of bugs and their causes.
I wholeheartedly agree with most previous answers here, but I think they are focused on and limited to the coding process (i.e. the process between receiving the specification for a component on one end and integration on the other end), and to improving the quality there. It is not difficult to see that a better process for writing code will lead to better code, i.e. using best practices for structuring/desiging the code, unit-testing, and releasing will reduce the chance for error on the developer side. Avoidance and early detection strategies are a part of this.
However, in my experience, coding errors make up a relatively small portion of the whole set of defects. In between the scoping process and the delivery of the final product in a full-lifecycle software project, bugs that result from incomplete or incorrect specifications are much more difficult to detect and avoid. Developers can argue that such defects are not really bugs, but from the user's or customer's perspective, they are of course. As developers, we have less control over this type of bug, though.
The best quality code cannot replace quality in the QA process. A strict separation of roles between developer and tester improves the detection rate. Testers should work with subject-matter experts on developing test plans that cover all use cases. All parties involved in the project need to share the view that QA is a critical component to success, that it takes time, and that shortcuts will lead to trouble.
As trivial as it sounds, frequent and formal communication between developers, testers, and the customer/end users throughout the project is probably the most effective strategy to detect and avoid bugs that are not a result of coding errors.
My personal favorite is the check all code pathways. While one interpretation of this is white-box testing, the other is to ensure that the requirements are complete. This can mean asking a lot of questions and sometimes getting a, "I never thought of that..." responses and possibly working things through and handling the fact that the user may not have thought things through, the programmer may help finish resolving the fuzzy requirements.