Why developers are poor testers and what can be done about it
-
In many cases, the testers tend to be unhappy with the results of developer’s testing. There are various reason to why developers don’t have a “natural ability” to excel at testing.
Because it works on their machine?
-
In many cases, the testers tend to be unhappy with the results of developer’s testing. There are various reason to why developers don’t have a “natural ability” to excel at testing.
Because it works on their machine?
Unfortunately, it is bounded to happen. Developers are more focused on the technical part of the system or feature or whatever they are testing. Creating test cases might help, but again, developers have a hard time to get into a "normal" users' head and get all possible paths.
-
In many cases, the testers tend to be unhappy with the results of developer’s testing. There are various reason to why developers don’t have a “natural ability” to excel at testing.
Because it works on their machine?
Am I the only one who gets excited when it works in another's machine? I mean, there is always that sense of mystery and "did I do that?"
-
Am I the only one who gets excited when it works in another's machine? I mean, there is always that sense of mystery and "did I do that?"
I am excited too.... particularly if they stop the app for a while ans restart it successfully! I mean many a time my servers depends on a few external piece of software and I am wary that the chain of dependency is broken...
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
-
In many cases, the testers tend to be unhappy with the results of developer’s testing. There are various reason to why developers don’t have a “natural ability” to excel at testing.
Because it works on their machine?
That well written article is a good find. Sadly, knowing the reasons why developers are bad testers won't be enough to make them good testers, but at least some people get aware of it and can try to circumvent some of the problems. And when it comes to Requirements Engineering, the situation is again similar. As a developer, you cannot be good requirements engineer at the same time...
-
Unfortunately, it is bounded to happen. Developers are more focused on the technical part of the system or feature or whatever they are testing. Creating test cases might help, but again, developers have a hard time to get into a "normal" users' head and get all possible paths.
Developers shouldn't be writing test cases for code they've written. It's not that they have a hard time getting into the end-users head, it's that they are subconsciously aware of the weaknesses of their code, and will avoid testing those weaknesses. At my last job, we had a dedicated QA team that wrote test cases according to the requirements document.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
In many cases, the testers tend to be unhappy with the results of developer’s testing. There are various reason to why developers don’t have a “natural ability” to excel at testing.
Because it works on their machine?
Yes, Because it works on our machines. I always experiencing this. A developer system has SDK and Runtime environment installed for the software application he is developing. So most of the time, his application works correctly on his machine. :(
VR Karthikeyan
-
In many cases, the testers tend to be unhappy with the results of developer’s testing. There are various reason to why developers don’t have a “natural ability” to excel at testing.
Because it works on their machine?
Over time I have moved (evolved ?), reluctantly, from the view that one person, or team, can "do it all" to a view I believe is similar to what John Simmons expressed here, which I interpret as a kind of "organizational separation of roles and concerns." It is possible to have a "brilliant" programmer/developer who would also be an idiot at writing tests ? I think that's possible. On a simple level, this boils down to: developers' time is worth more than tester's time, and a system architect's time is worth more than developers' time, and the project manager's time is worth more than anyone else's. I do think developers should test as they develop against obvious sources of error: null references, etc. But, I think the idea of TDD generally sucks, unless you have a resource for expert-level test design, and are willing to use (can afford to use) that resource for that purpose. I think we need to distinguish between different levels of testing: 1. code-testing the app against a carefully designed set of tests: designed by those familiar with the app and its requirements. 2. use-tests of the app by "modal users" or simulated modal users with "real-world" data and usage modes. 3. idiot-proof testing of the app by those who don't have a clue. imho, all are potentially valuable. imho, there is no one size-fits-all rule for any of this; the issues in a small-team working face-to-face are quite different from those in a project with a large team and/or contractors working off-site. A stand-alone app with no plug-ins, no web interaction, or extensions, has a different set of possible issues than an app that relies on the web, that hosts 3rd.party whatevers.
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008