|
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!
|
|
|
|
|
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?
|
|
|
|
|
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!
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
Even better the QA guy can tell the place in code that he thinks should be fixed. That way devs don't waste time looking for right method but can spot if the QA guy was wrong and is just going to mask some other bug.
--
"My software never has bugs. It just develops random features."
|
|
|
|
|
It amuses me to read about the coder and QA tester being different people. You people don't know how good you have it... 
|
|
|
|
|
Heh, I used to work for company that looked at QA as money waste. You know - they don't "produce" anything and slow down development as instead of new features they want the bugs fixed...
It was quite a few years ago. I'm not sure if they changed their mind or just died in pain
--
"My software never has bugs. It just develops random features."
|
|
|
|
|
Well I'm glad to say our place doesn't see it that way! We'd have separate QA people, but our niche market isn't big enough to support more than the 1.5 developers + 1 customer support that we have. Us doing everything is just a practicality we have to deal with.
|
|
|
|
|
The consensus seems this is a bad idea. This doesn't mean that the QC guy can't be a developer for some of the time if his aspiration is in that direction. It just means that the QC process cannot be corrupted to allow QC people to develop and QC at the same time.
Peter Wasser
"The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." - Bertrand Russell
|
|
|
|
|
I think it's okay as long as the bug fix is not signed off by the person that fixes it, and the tester knows his limits when it comes to coding.
|
|
|
|
|
BobJanova wrote: and the tester knows his limits when it comes to coding.
What coder knows his limits? 
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
It should be fine if it's only UI messages - if they're kept outside of variables. Such as a messagebox with a fixed caption, or a constant variable. Otherwise you risk coding problems such as "I'll just change the text that's passed to this strcpy()... oops." "I'll just change the text in this char[26]... oops."
If the changes they make are under version control the coder could always review them. The thing is, if they do break it, they can just hide behind "I'm not a programmer"... quite legitimately.
|
|
|
|
|
SortaCore wrote: if they do break it, they can just hide behind "I'm not a programmer
When you change code you have just become a programmer.
Alternatively, if you are not a programmer why did you change the code?
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
JimmyRopes wrote: When you change code you have just become a programmer.
Not something I agree with. I might be able to fix a car, but I don't become a mechanic from doing that. Or whack a nail into a plank of wood and become a "DIY guy".
Code to me is the mechanics of the program, not the UI wording. When a program goes multi-language, it'll probably end up with separate language files anyway, which don't contain any code, just variants of UI text; so surely changing that text would make you a programmer, since it affected the program?
Heck, you could draw a new icon file and change the program. And if it's embedded into the application, you've just changed the machine code. Congrats on your new job title.
|
|
|
|
|
If you are not a programmer why did you change the code? 
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
Changing the interface, not the code. As in my example, if there was an icon file separate in the project, but embedded when the program was produced, a graphics designer could freely change the icon without being told he "changed the code" or that he's a coder.
|
|
|
|
|
Apparently the QA person is taking more liberty than just changing icons. (S)he is changing variables, albeit hard coded ones that probably should not have been, which can have unexpected consequences.
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
Ah, I did say "outside of variables" in my post.
Changing variables is definitely inviting trouble. I agree with you on that point.
|
|
|
|
|
That is just it. The poster said they were changing variables, albeit hard coded ones.
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
SortaCore wrote: If the changes they make are under version control the coder could always review them
If the changes are not under version control then that is a problem regardless of who is making the change.
SortaCore wrote: The thing is, if they do break it, they can just hide behind
If they broke it then they broke it. Period.
The choice after that is whether they still get a chance to not break it in the future.
|
|
|
|
|
Everyone's responses against so far have been a bunch of "What Ifs" (or clever cliches in Latin).
What if allowing the QA to fix a typo brings the project in a day early, and the Dev Manager gets a nice huge bonus?
What if a developer changes something he/she really doesn't understand and delays the project for weeks?
Separation of responsibility is a nice guideline, but exceptions almost always prove the rule.
Who's QA'ing the QA? Hopefully, the dev manager is.
You may have guessed that I am a dev manager.
"I am rarely happier than when spending entire day programming my computer to perform automatically a task that it would otherwise take me a good ten seconds to do by hand."
- Douglas Adams
|
|
|
|
|
Michael Haines wrote: You may have guessed that I am a dev manager.
Then you are asking for trouble.
Any changes "out of band" should not be done. There is a process in place to insure that casual changes do not take place. It is there for a very good reason. Regardless of all good intentions people will make mistakes.
Sorry if your bonus is not as big, but the process has to be followed if consistency is to be maintained.
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
Actually, I do not have this situation. The QA staff here does not code at all.
I was just stating that putting a process in place that allows this is completely possible.
The result is that the dev manager is ultimately responsible and should be reviewing when/if it happens.
"I am rarely happier than when spending entire day programming my computer to perform automatically a task that it would otherwise take me a good ten seconds to do by hand."
- Douglas Adams
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
