|
Well, my model above is not only provocative. It is plain wrong.
Using (bug) metrics to affect payments is in not a good option as people will spend their time to overcome and optimize those metrics and fight over them, rather than work.
However, most companies, including my one, use similar metrics to affect payments. Those models are not as obvious as I wrote but often similar (even thought our testers payment model used to be for some time exactly as above - a daily nightmare).
No one knows how much money this really costs. I am just surprised that time after time, those who have the power to decide on such stuff think it is a nice idea to try it out in different forms.
|
|
|
|
|
I think, after some basic testing, it's the testers task to examine the program carefully. The programmer often just won't find the bugs because he doesn't press the buttons in random order or in an order that was probably never specified.
However, what do you do if there are no dedicated testers?
|
|
|
|
|
I let the other programmers in the team test my code and also if necessary I give it to the one or two people in the department that are good at making commercial software break..
John
|
|
|
|
|
John M. Drescher wrote: I give it to the one or two people in the department that are good at making commercial software break..
Too bad there is no CG in my department ...
|
|
|
|
|
Answers are nothing but wishful thinking
|
|
|
|
|
No, really... besides unless at gunpoint, which developer tests his own code WELL? I mean not just "yes it compiled" or "oh yeah, I ran a (very simple) test case and it worked". Developers like to WRITE code, not test it. Testing is waste of time... so much more code can be written in this time
|
|
|
|
|
|
I take it you are speaking for yourself? Because you are certainly not speaking for me.
I (like many others here) take pride in my code, and strive to release it only when it is as fault free as I can make it. It is then the testers job to make sure I didn't miss anything and have interpreted the requirement correctly.
"Just bash the code out" is is a piss-poor excuse for programming, and annoys teh hell out of me when I meet such software. At least now I will know one person to blame for it in future...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
As a manager and a programmer this is the one way to get on my bad side. I mean if any of my programmers submit code to me as done but they obviously have not even run the debugger I get very upset at that. I do not expect code to be bug free but at least the obvious bugs if you ran the program for 5 minutes in the debugger should have been caught..
John
|
|
|
|
|
This is what I am talking about - 5 minutes of debugging to check the most obvious problems. No imagination to check anything weird like filling the form bottom-up or just chaotic.
No developer would admit about being lousy at testing but this is the sad truth. Give a product to real customers (read: people who don't want to use it and try to hack it in every possible way), I mean - give it after one-week of "thorough testing" and in the next day or two you get a few pages with bugs and error reports.
It's that programmers who design a system know how it works and expect it to be used "properly". Even simple stuff like entering $123.45 as price not 123.45 may go thorough undetected.
To everyone who claims to test good: do you spend more time to test your code than it takes to write it? Really?
|
|
|
|
|
I guess you don't get the irony in my post.
Tell me how many developers you know who test their code thoroughly? And how much time they spend on testing? Anything close to the time it took them to write the code?
Most developers THINK they test their code well. Believe me for 20 years I saw so much code and dealt with so much developers and I can responsibly say that testing isn't their strong side.
modified on Tuesday, December 14, 2010 8:36 PM
|
|
|
|
|
nsimeonov wrote: And how much time they spend on testing
I tend to spend about the same time testing as actual coding, I hate it when a tester comes back with an obvious error that should have been picked up during development.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Developers should fully test their own code and work with testers to produce a test plan and a regression test plan. The testers should use the test plans plus some additional random tests they think of.
JR
|
|
|
|
|
Define "fully"
I believe that integration and system level tests aka "validation tests" should be performed independently.
But unit-test and other verification activities, such as, code review should be done by developers.
I subscribe to Test Driven Development.
|
|
|
|
|
fully = to the best of their limited abilities.
JR
|
|
|
|
|
I don't like the word "fully". I have previously worked as a dedicated software tester for 6 years in a large international company. That company had both time and money to divide tasks, so that a person don't end up with a conflict of interests. In smaller companies, one have to think a little smarter to achieve a similar goal.
My experience from that time, is that a developer should write code and do some "simple" test activities as code review and unit testing. All other test activities must be left to the dedicated testers.
As a functional tester, I had many long talks with developers when constructing, for example when I needed to construct sequence diagrams for my functional tests. At that time in the process, the developer was only a "consultant", he/she didn't own the test process.
If a company can't afford to have dedicated testers, one should at least avoid that the developer tests his own code.
There's not a data type big enough to count all the bugs and corrections in a project that was found by a fresh pair of eyes
|
|
|
|
|
I presume that the end-user is:
- unlucky
- with two left hands
- curious
- with evil intentions.
Enough?
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
I think you should start a new testing methodology based on those principles!
|
|
|
|
|
Or maybe I call it PARANOIA ?
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
The PARANOIA Testing Method. I like it!
Put a few words together in a folder with some pictures - and you're on the road to making millions!
|
|
|
|
|
rmallamace wrote: I think you should start a new testing methodology based on those principles!
That's a perfect Idea
|
|
|
|
|
Thanks for saying this!
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
|
Agree. That is why authors are not supposed to edit their own work. That is the job of an editor.
|
|
|
|
|
I agree that there should be independent testing particularly at the functional and requirements level.
However, code is a work product and a developer should deliver a quality work product. A developer who takes ownership over what he delivers needs to be able to say, "My code functions as I intended".
A writer .e.g. might proof-read, spell check and grammar check their document prior to handing it over to someone else to proof-read it. No editor wants to receive a document that is full of typos.
I would also argue that regarding unit-test the developer is the best qualified to perform it. Once it becomes integrated or a system level test a dedicated tester will be the best choice.
I also believe in Test-Driven-Development and so when writing new code will often write the tests first and then the code.
The end result is that very few bugs are submitted against my code.
Our company also practices code-review. We are semi-agile.
I have worked on both sides - as a dedicated tester and as a developer. I have seen far better success in quality projects being released on time when developers do their own code verification coupled with independent validation as opposed to independent test alone.
|
|
|
|