Testers coding bug fixes directly?
-
So I'm a dev manager and our QC lead who is gaining proficiency in coding, though is by no means even a junior programmer has taken it upon himself to directly fix some easy bugs. This is certainly a faster way to get things fixed as our dev resources are severely limited. So far it's restricted to typos/grammar mistakes in hard-coded string UI messages and that type of thing. Good or bad? Thoughts?
-
So I'm a dev manager and our QC lead who is gaining proficiency in coding, though is by no means even a junior programmer has taken it upon himself to directly fix some easy bugs. This is certainly a faster way to get things fixed as our dev resources are severely limited. So far it's restricted to typos/grammar mistakes in hard-coded string UI messages and that type of thing. Good or bad? Thoughts?
Very, very bad. One day he'll fix something he really doesn't understand. Then he'll pass it as fixed because he fixed it so it must be right. You can either do QA or code but not both and certainly not at the same time.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. Those who seek perfection will only find imperfection nils illegitimus carborundum me, me, me me, in pictures
-
Very, very bad. One day he'll fix something he really doesn't understand. Then he'll pass it as fixed because he fixed it so it must be right. You can either do QA or code but not both and certainly not at the same time.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. Those who seek perfection will only find imperfection nils illegitimus carborundum me, me, me me, in pictures
-
So I'm a dev manager and our QC lead who is gaining proficiency in coding, though is by no means even a junior programmer has taken it upon himself to directly fix some easy bugs. This is certainly a faster way to get things fixed as our dev resources are severely limited. So far it's restricted to typos/grammar mistakes in hard-coded string UI messages and that type of thing. Good or bad? Thoughts?
Who's quality checking the quality checker? :) I think it mostly depends on your environment. It can work really well for some people but others need to make sure things always go through the same process. It wouldn't work well where I am because our quality guy is very strict about testing everything. He would want the devs to change it so he could retest. It takes more time but it keeps consistency in process. With quality people making changes do they also have access to source control and other dev environments? The biggest problem you might run into is not being able to keep track of things if they end up making lots of changes.
There are only 10 types of people in the world, those who understand binary and those who don't.
-
So I'm a dev manager and our QC lead who is gaining proficiency in coding, though is by no means even a junior programmer has taken it upon himself to directly fix some easy bugs. This is certainly a faster way to get things fixed as our dev resources are severely limited. So far it's restricted to typos/grammar mistakes in hard-coded string UI messages and that type of thing. Good or bad? Thoughts?
-
So I'm a dev manager and our QC lead who is gaining proficiency in coding, though is by no means even a junior programmer has taken it upon himself to directly fix some easy bugs. This is certainly a faster way to get things fixed as our dev resources are severely limited. So far it's restricted to typos/grammar mistakes in hard-coded string UI messages and that type of thing. Good or bad? Thoughts?
Kieryn Phipps wrote:
. This is certainly a faster way to get things fixed as our dev resources are severely limited
That is the key point - resources are limited! In the ideal world you will have testers and developers having their own responsibilities but the real world is rarely ideal. I am sure you can improve this process as time goes on.
-
So I'm a dev manager and our QC lead who is gaining proficiency in coding, though is by no means even a junior programmer has taken it upon himself to directly fix some easy bugs. This is certainly a faster way to get things fixed as our dev resources are severely limited. So far it's restricted to typos/grammar mistakes in hard-coded string UI messages and that type of thing. Good or bad? Thoughts?
I have to agree with Mark Merrens on this one, nothing good can come of this. As this person gets more confident they'll try and tackle bigger problems which brings greater risks. It could be just as easy as documenting what he thinks should be changed and give it to you, then you could dole the work out after aa number on them have been received. If the fixes are indeed easy, it should just take a couple of minutes for the dev team (the people who could perhaps see the bigger picture) to fix.
-
So I'm a dev manager and our QC lead who is gaining proficiency in coding, though is by no means even a junior programmer has taken it upon himself to directly fix some easy bugs. This is certainly a faster way to get things fixed as our dev resources are severely limited. So far it's restricted to typos/grammar mistakes in hard-coded string UI messages and that type of thing. Good or bad? Thoughts?
As long as he QC person is following the same process (code review, unit test, ... ) as the other developers, why not.. All the change should be traceable. For example we do not check in code if the change is not attached to a known issue in the bug database; even for small trivial changes.
I'd rather be phishing!
-
So I'm a dev manager and our QC lead who is gaining proficiency in coding, though is by no means even a junior programmer has taken it upon himself to directly fix some easy bugs. This is certainly a faster way to get things fixed as our dev resources are severely limited. So far it's restricted to typos/grammar mistakes in hard-coded string UI messages and that type of thing. Good or bad? Thoughts?
Very very bad idea unless you have a formal and rigid means of ensuring that he doesn't get to test anything he's "fixed". Unfortunately I speak from experience - someone who "fixed" something in a business-critical application only saw what they expected to see when they retested it. (We also didn't find the underlying problem for weeks because he managed to bypass the change audit as well, but that was a different issue).
Quote:
This is certainly a faster way to get things fixed...
... It is also a faster way to get things broken! Having said that, if it's restricted to UI messages then presumably your UAT process would be QA'ing that?
-
I have to agree with Mark Merrens on this one, nothing good can come of this. As this person gets more confident they'll try and tackle bigger problems which brings greater risks. It could be just as easy as documenting what he thinks should be changed and give it to you, then you could dole the work out after aa number on them have been received. If the fixes are indeed easy, it should just take a couple of minutes for the dev team (the people who could perhaps see the bigger picture) to fix.
Quote:
As this person gets more confident they'll try and tackle bigger problems
That is certainly a possibility but we should hesitate to be so bold in our assumptions. Heck, in one of my jobs we didn't even have QA. When I was doing asp we did the changes right on the production server sometimes. :)
There are only 10 types of people in the world, those who understand binary and those who don't.
-
Very, very bad. One day he'll fix something he really doesn't understand. Then he'll pass it as fixed because he fixed it so it must be right. You can either do QA or code but not both and certainly not at the same time.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. Those who seek perfection will only find imperfection nils illegitimus carborundum me, me, me me, in pictures
Agreed! The whole idea of having a separate QA dept is that the people involved in the development don't do the testing, because they don't know what to expect. Who is going to test the QA output?
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952) Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
-
Quote:
As this person gets more confident they'll try and tackle bigger problems
That is certainly a possibility but we should hesitate to be so bold in our assumptions. Heck, in one of my jobs we didn't even have QA. When I was doing asp we did the changes right on the production server sometimes. :)
There are only 10 types of people in the world, those who understand binary and those who don't.
-
Who's quality checking the quality checker? :) I think it mostly depends on your environment. It can work really well for some people but others need to make sure things always go through the same process. It wouldn't work well where I am because our quality guy is very strict about testing everything. He would want the devs to change it so he could retest. It takes more time but it keeps consistency in process. With quality people making changes do they also have access to source control and other dev environments? The biggest problem you might run into is not being able to keep track of things if they end up making lots of changes.
There are only 10 types of people in the world, those who understand binary and those who don't.
Quote:
Who's quality checking the quality checker?
NSA, NSA could check everything, this way they would always do something meaningful :laugh: I'm assuming that the quote is a play on "Who will guard the guards?[^]"?
-
So I'm a dev manager and our QC lead who is gaining proficiency in coding, though is by no means even a junior programmer has taken it upon himself to directly fix some easy bugs. This is certainly a faster way to get things fixed as our dev resources are severely limited. So far it's restricted to typos/grammar mistakes in hard-coded string UI messages and that type of thing. Good or bad? Thoughts?
Yes, very bad... by the same token, those that drive cars shouldn't attempt to repair them. That's the mechanic's job! The driver is QA only! How dare they assume to rise above their position in life! People learn by doing. Do any of use remember our first code and how we've improved since then? Peer review.. it might just work!
-
Who QA's the QAs? There's a Latin version of that isn't there?
- I would love to change the world, but they won’t give me the source code.
Quid arsos qual arsolium It roughly translates to "which arse let him touch the code"?
-
So I'm a dev manager and our QC lead who is gaining proficiency in coding, though is by no means even a junior programmer has taken it upon himself to directly fix some easy bugs. This is certainly a faster way to get things fixed as our dev resources are severely limited. So far it's restricted to typos/grammar mistakes in hard-coded string UI messages and that type of thing. Good or bad? Thoughts?
Good. If it gets the bug fixed quick, then what the heck.
"The whole idea that carbon dioxide is the main cause of the recent global warming is based on a guess that was proved false by empirical evidence during the 1990s." climate-models-go-cold
-
Very, very bad. One day he'll fix something he really doesn't understand. Then he'll pass it as fixed because he fixed it so it must be right. You can either do QA or code but not both and certainly not at the same time.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. Those who seek perfection will only find imperfection nils illegitimus carborundum me, me, me me, in pictures
mark merrens wrote:
One day he'll fix something he really doesn't understand.
"So far it's restricted to typos/grammar mistakes in hard-coded string UI messages and that type of thing" Plain English? Come on. Don't be silly.
"The whole idea that carbon dioxide is the main cause of the recent global warming is based on a guess that was proved false by empirical evidence during the 1990s." climate-models-go-cold
-
So I'm a dev manager and our QC lead who is gaining proficiency in coding, though is by no means even a junior programmer has taken it upon himself to directly fix some easy bugs. This is certainly a faster way to get things fixed as our dev resources are severely limited. So far it's restricted to typos/grammar mistakes in hard-coded string UI messages and that type of thing. Good or bad? Thoughts?
I think it's awesome that the guy wants to get his hands dirty and is taking the initiative! Take him under your wing and coach him if you have the time...if not, at least guide him to some helpful resources. Consider that he may bring a fresh insight to your products and customers. :)
"Go forth into the source" - Neal Morse
-
So I'm a dev manager and our QC lead who is gaining proficiency in coding, though is by no means even a junior programmer has taken it upon himself to directly fix some easy bugs. This is certainly a faster way to get things fixed as our dev resources are severely limited. So far it's restricted to typos/grammar mistakes in hard-coded string UI messages and that type of thing. Good or bad? Thoughts?
It's both good and bad for all the reasons already stated. There might be a reason it was coded a certain way that he doesn't know about, and the bug is actually somewhere else. So even if he fixed the problem he encountered he might have created another bug instead. So make sure his fixes gets sent back to the dev team for review.
Wrong is evil and must be defeated. - Jeff Ello[^]
-
So I'm a dev manager and our QC lead who is gaining proficiency in coding, though is by no means even a junior programmer has taken it upon himself to directly fix some easy bugs. This is certainly a faster way to get things fixed as our dev resources are severely limited. So far it's restricted to typos/grammar mistakes in hard-coded string UI messages and that type of thing. Good or bad? Thoughts?
