Testers coding bug fixes directly?
-
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.
-
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 good and bad, it's good because you have an extra set of hands to help you with small tasks, but it's bad because if he breaks something he may simply wash his/her hands and pass the problem to you.
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
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:
Good or bad?
In general, a good thing. But ensure that any check-ins are first reviewed by a senior dev. Over time, some types of fixes may be permitted without review. I would encourage the QC engineer to continue pursuing his/her programming skills (by formal training - by that I don't necessarily mean a degree program). /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
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?
First it is a bad thing to have hard-code string UI messages as it will make harder to localize the application if the need comes or if the message is used at many locations. Second, the developer might be better at evaluating the impact of change. Maybe the string is written in a fixed size buffer or is restricted in available UI space or used at more than one location or other similar things for which the tester might not be able to properly evaluate the impact. Third it might make it harder to follow the history if such changes are made in the middle of other unrelated changes so it might be preferable to review and fix all mistakes at once. It could also help ensure consiostency where all similar errors are corrected at once for example if the same word was always spelled wrong.
Philippe Mori
-
yawn.... Yeah yeah yeah, we all know what can happen, but we are talking about display strings. Name one instance where oy have even seen code that compares or uses in some way "Enter you age" or some such.
"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
This one time I was asked to change a dynamically generated list make anything with the same "{value} - " mutually exclusive. They're horrible hacks that only happen due to improper scoping, but anyone unfamiliar with the code could trigger weird bugs if maybe they decided that a letter in "{value}" wasn't properly capitalized or something.
-
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. JimmyRopesActually, 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
-
I'm sorry but it won't be faster. If your team is small then your devs probably know the app inside out. Let the QA guy tell the devs where he thinks the change should be made. If he is correct, it will be 2 mins to get it fixed. If there is something else - the hardcoded variable is used elsewhere the QA guy doesn't know about - the dev will know it and fix it properly. Changes outside of the dev team - especially small one - will make things much slower in future and harder for maintenance. I know every manager wants to deliver on time and the pesky QA guys just go in the way ;) I think it is better to ship with small visible bugs the client knows about (QA reported, but no time to fix), than ship with masked bugs as they will hit you harder later.
-- "My software never has bugs. It just develops random features."
I am glad that you all have your own processes in place. Please don't believe that EVERYONE else does it the same way. I do not have this problem - I merely suggested it was manageable and potentially effective. My QA is made up mostly of analysts who don't want to code - at all. "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
-
I am glad that you all have your own processes in place. Please don't believe that EVERYONE else does it the same way. I do not have this problem - I merely suggested it was manageable and potentially effective. My QA is made up mostly of analysts who don't want to code - at all. "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:
My QA is made up mostly of analysts who don't want to code - at all.
A blessing in disguise. :~
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
Michael Haines wrote:
The result is that the dev manager is ultimately responsible and should be reviewing when/if it happens.
I hate to say this, but does the manager understand the intricacies of the code? If they were managing and not micromanaging then they don't. :~ The dev is the only person who knows the code so they should be the one making the changes. It is alright for the QA person to indicate where they think the changes should be made, but the dev should have final say.
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am. JimmyRopes -
Michael Haines wrote:
The result is that the dev manager is ultimately responsible and should be reviewing when/if it happens.
I hate to say this, but does the manager understand the intricacies of the code? If they were managing and not micromanaging then they don't. :~ The dev is the only person who knows the code so they should be the one making the changes. It is alright for the QA person to indicate where they think the changes should be made, but the dev should have final say.
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am. JimmyRopesJimmyRopes wrote: I hate to say this, but does the manager understand the intricacies of the code? If it were me, the answer would be yes. "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
-
JimmyRopes wrote: I hate to say this, but does the manager understand the intricacies of the code? If it were me, the answer would be yes. "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:
JimmyRopes wrote:
I hate to say this, but does the manager understand the intricacies of the code?
If it were me, the answer would be yes.Then you are not managing. You are a micromanager. :~
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am. JimmyRopes