A bug is something we find in a software product that “doesn’t look right” (this is my personal definition). A bug can be hidden or visible; it can be “already fixed” or “still present”; it can be critical or cosmetic; it can be urgent or of a low priority. What is important is that the more bugs we are able to find and fix before our customers see them, the higher the perceived quality of the software. Simply put, bugs are a very good thing, if they are found by us, not our customers. We pay our programmers for each bug they find. Here is a cheat sheet for them, showing where and how they can find those bugs, to make more money.
Obviously, if something is broken, it’s a bug; no need to mention it here. However, when a product is more or less stable, not too many things are visibly broken. But we still pay for bugs. What should you look out for? Read on. This list (in no particular order) will help you.
Lack of functionality. If a class (yegor256/cactoos#558) or the entire module (yegor256/cactoos#399) doesn’t provide the functionality you expect it to have, it’s a bug.
Lack of tests. If a class doesn’t have a unit test (yegor256/takes#43) or the existing test doesn’t cover some critical aspects of the class (yegor256/cactoos#375), it’s a bug.
Lack of documentation. If, say, a Javadoc block for a class does not clearly explain to you how to use the class, or the entire module is not documented well (yegor256/takes#790), it’s a bug.
Suboptimal implementation. If a piece of code doesn’t look good to you, and you think it can be refactored to look better, it’s a bug.
Design inconsistency. If the design doesn’t look logical to you (yegor256/cactoos#436) and you know how it can be improved, it’s a bug.
Naming is weird. If class, variable or package names don’t look consistent and obvious to you, and you know how they can be fixed (yegor256/cactoos#274), it’s a bug.
Unstable test. If a unit test fails sporadically (yegor256/takes#506) or doesn’t work in some particular environment (yegor256/jpeek#151), it’s a bug.
Also, it’s worth mentioning that minor, cosmetic, or poorly formulated bug reports will most likely be rejected or not paid for. If you want us to pay for your bug reports, make sure they sound right, in order to help us move the project forward to a better state.
| Published on Java Code Geeks with permission by Yegor Bugayenko, partner at our JCG program. See the original article here: More Bugs, Please Opinions expressed by Java Code Geeks contributors are their own. |
