Tag Info

Hot answers tagged

367

This sounds absolutely nutty. It is expending a great deal of effort for very questionable benefit, and the practice seems based on some faulty premises: That QA won't work hard unless they know they are being tested every day (which cannot be good for morale) That there are not enough unintentionally introduced bugs in the software for QA to find That ...


181

Well, based on what I've learned: It's not a school nor job interview; The testers are not children; It's not a game; It wastes company's money. The QA are not there only to find bugs but also to worry about how intuitive the system is, what is the learning curve for the user, usability, and accessibility in general. For example: "Is the system ugly?", ...


139

What looks like guessing from the outside often turns out to be what I call "debugging in your mind". In a way, this is similar to grandmasters' ability to play chess without looking at a chess board. It is by far the most efficient debugging technique I know, because it does not require a debugger at all. Your brain explores multiple code paths at the same ...


93

The usual suspects are: You thought it worked yesterday, but after a full day of work you were too blind to realize that it didn't work. This morning you no longer can refer to what was in IDE cache memory yesterday. The workstation has rebooted last night or a nightly maintenance operation cleared /tmp directories. Something has changed in the code base: ...


92

Well, it's pretty simple: not all exceptions are bugs (and similarly, not all bugs manifest themselves as exceptions). As example of an exception that's not a bug, if you're reading a file from a USB drive and someone yanks the drive out of the socket. That's going to raise an exception (in most languages that support exceptions, that is). But it's not a ...


90

Bad idea. From the tester's point of view: "So they will test hard, because they know there are bugs present and not finding them might be considered as their incompetence." Basically the devs are booby-trapping the code. Few people like doing work which is ultimately pointless (because the bugs are known in advance) but which still affect how they are ...


80

Many answers have questioned your boss' methods/tactics/metrics/etc. But that is beside the point. Maybe you ARE slow. Every room of developpers has to have ONE that's slower than the rest, right? (That's just straight set-theory.) So let's assume that's you. The answer is, WHY are you slow? (Clearly that is the question you have to answer before you can ...


79

Quit. No, not your job! Just get up and go home. You're done for the day or the weekend. 19 times out of 20 when you come back to the problem next, the solution will present itself within an hour.


79

By using a debugger. For the most part, this is also what an IDE does behind the scenes -- it just wraps the experience in a GUI. On Unix, one of the most commonly used debuggers is GNU gdb, which has largely supplanted the earlier Unix debuggers such as dbx. To get an idea of what debugging looks like / feels like from the command line, you can look at ...


63

Is it reasonable to insist on reproducing every defect and debug it before diagnosing and fixing it? You should give it your best effort. I know that sometimes there are conditions and environments that are so complex they can't be reproduced exactly, but you should certainly try if you can. If you never reproduced the bug and saw it for yourself, how ...


58

Reproducing a bug that rarely happens. Especially when coping with multithreading.


56

Your boss may be correct: you may be "underperforming" (more on that in a minute). But it may not be just your level of competence that's to blame. I don't think it would be a reach to suggest forces outside your control are causing you stress, which is having a negative effect on your performance. Let's have a look at a few of the reasons your boss may now ...


49

1) If it's not working today, it wasn't working yesterday either. You thought it was working, but it wasn't. 2) There is a problem, and it must be solved. Don't think about who's responsible for this or about blaming others. If nothing has changed between yesterday and today (like I presume reading your question), it means you should do a better job at ...


47

I agree totally with the answers above as to why this is bad for motivation and just generally awful people management. However, there are probably sound technical reasons for not doing this as well: Just before the product goes to QA, the dev team adds some intentional bugs at random places in the code. They properly back up the original, working ...


46

Is there some kind of cultivatable behaviour [...] that can help me at least reduce such kind of mistake Absolutely, it is called four-eyes-principle. If you had you shown your crontab entry to a second person (a person knowing cron, of course), chances are high the mistake would have been avoided. In programming, when it comes to this, people mostly ...


45

Unit testing. After I started applying unit testing I found that the code I wrote became better structured. It was then easier to avoid and spot bugs. I spent less time debugging, but more time with writing unit test. I also think that the time invested in unit tests has a better return of investment then debugging. After a debugging session I just fixed ...


45

A Duck From http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html: A feature added for no other reason than to draw management attention and be removed, thus avoiding unnecessary changes in other aspects of the product.


44

Before ten hours go by, I would get some help. Describe the problem to someone else, anyone else, even your rubber duck. Ask someone else to take a look at the code, or step through it with them. Isolate it. Delete a bunch of stuff, then bring it back bit by bit until the problem reappears. Get some sleep!


44

Edit I want to be clear that this answer is only talking about the concept of testing your QA process, and I'm not defending the specific methodology portrayed in the question. End Edit There is a valid reason to check if your testing/checking is actually working. Let me give you an example from manufacturing, but the principle is the same. It's typical ...


43

Build an SSCCE (short, self contained, correct example). If the bug disappears when you remove some of the extra details for the SSCCE, then you found it. Otherwise you will have an SSCCE that you give or post that ideally eliminates the code that you are concerned about sharing.


40

The more I know a code base, the less I need a debugger (but I'd still check the reported error, it is an important clue in any reasoning). It is a fine tool to understand some dynamic behavior of small to medium complexity, but I often find out that it focus me on the details instead of the bigger picture. And after a while, that's where the problems are: ...


39

Yes its very important About that particular candidate, it is possible that s/he was not familiar enough with code-base x to debug it. A good problem solver should be able to debug, as all that is usually required is to have a very logical method/approach.


39

The best programmers are masters of debugging. You're worrying too much friend. Using the debugger every day is a sign that you live in the real world.


39

You want to look at a logging framework, and maybe at a logging facade framework. There are multiple logging frameworks out there, often with overlapping functionalities, so much so that over time many evolved to rely on a common API, or have come to be used through a facade framework to abstract their use and allow them to be swapped in place if needed. ...


38

Some work environments are unworkable. I've seen environments in which no one could survive (save for those who were in at the beginning) because so much was undocumented and questions were so vehemently discouraged. You really need to be honest with yourself regarding the expectations and the resources provided to help you to meet them. The problem may not ...


36

It affects the efficiency in a very good way. I feel that it's used too seldom by developers. Not only is it good for debugging but it can also give you an insight in profiling. For example when line stepping you can feel "ahh" this line took a little too long time to execute and you get a feeling for where the bottlenecks in your app are.


36

I really have a hard time seeing where I went wrong The major mistake was that you reinvented the wheel. Instead of using default mecanisms for logging, you invented your own, which displayed the information within the page. A logging framework would rather store logs in log files, letting you to consult those logs later by SSHing to the server. As for ...


35

I would say that not using a debugger is a sign of inexperience. Stepping through code line by line is the best way to trace the flow of execution.


35

Unit testing, so that you know whether your code works in the first place. At least some amount of upfront design, so that you know what you are coding. Code reviews, because two heads are better than one, and four eyes are better than two. Not to mention that even trying to explain your code to someone else reveals many problems. Version control, so that ...


35

They may not be bad programmers, but they are probably terribly inefficient troubleshooters. I tend to follow the advice from Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems (David Agans), and this one falls squarely under the guidance of "Quit thinking and look"



Only top voted, non community-wiki answers of a minimum length are eligible