Testers coding bug fixes directly?
-
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[^]
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... ;P
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."
-
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
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."
-
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?
Enforce Code Review process before any check-ins and then you know whether the fix he made is good or bad. Secondly the bugs that he fixes can be assigned to another tester for second round of testing. :java:
-
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 long as it gets marked as 'submitted for QA review' (or however your process works) and someone else in QA has to review and verify it is fixed, then I don't see any real problem. Also assumes (ha!) he sticks to what his proficiency allows him to understand.
-
Gary Wheeler wrote:
"Benefits of a classical education."
You can converse in a dead language. :~
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am. JimmyRopesAlong with Latin, they teach Cobol?
-
I hope you don't have any quick fixes in the code that you haven't been allowed to fix properly because no-one will approve a change that doesn't add any visible value and which rely on those hard coded strings
greldak wrote:
which rely on those hard coded strings
Anyone who writes code like that should be sacked.
"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
-
greldak wrote:
which rely on those hard coded strings
Anyone who writes code like that should be sacked.
"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
Maybe they were or have since left for other reasons but are you sure that everyone including the aforesaid QA is aware of whether or not such code is present in the codebase and coding appropriately. Bear in mind that even though you are aware of how bad some code may be written you may not be allowed to replace it with a proper implementation unless the change is approved. My point is that even such apparently trivial changes can have unforseen consequences particularly in the case of legacy systems which may not have been well maintained in the past. As such any change needs to be properly controlled and tested. Are you certain that the aforesaid QA guy is following that principle - indeed just by doing so it would appear he is not.
-
Maybe they were or have since left for other reasons but are you sure that everyone including the aforesaid QA is aware of whether or not such code is present in the codebase and coding appropriately. Bear in mind that even though you are aware of how bad some code may be written you may not be allowed to replace it with a proper implementation unless the change is approved. My point is that even such apparently trivial changes can have unforseen consequences particularly in the case of legacy systems which may not have been well maintained in the past. As such any change needs to be properly controlled and tested. Are you certain that the aforesaid QA guy is following that principle - indeed just by doing so it would appear he is not.
We are talking a display string here. That's all.
"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
-
We are talking a display string here. That's all.
"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
And I had given an example where even that simple display string changing could change functionality. Just because something appears to be trivial does not mean that it is. It is unlikely that the QA guy will be sufficiently familiar with the code to determine that without spending considerable time reviewing the code. It will be much quicker and safer to have those familiar with the code make such a change. By all means he can identify what he believes needs to be done but he should not be making the change himself.
-
And I had given an example where even that simple display string changing could change functionality. Just because something appears to be trivial does not mean that it is. It is unlikely that the QA guy will be sufficiently familiar with the code to determine that without spending considerable time reviewing the code. It will be much quicker and safer to have those familiar with the code make such a change. By all means he can identify what he believes needs to be done but he should not be making the change himself.
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
-
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
I've seen no shortage of cases where business rules have changed to accomodate legislative changes which only impact certain groups and someone in the past has taken the shortcut of hardcoding the changes rather than allowing them to be configurable. I've even come across code in the past which checks the colour of text being displayed far less the actual text. More common would be in the case of contents of comboboxes where the text displayed is checked rather than the value. When you take over a system that 20 years old and been hacked around by as may developers in that time you get to see a lot of horrors.
-
I've seen no shortage of cases where business rules have changed to accomodate legislative changes which only impact certain groups and someone in the past has taken the shortcut of hardcoding the changes rather than allowing them to be configurable. I've even come across code in the past which checks the colour of text being displayed far less the actual text. More common would be in the case of contents of comboboxes where the text displayed is checked rather than the value. When you take over a system that 20 years old and been hacked around by as may developers in that time you get to see a lot of horrors.
SO that's actually a code review failure and nothing to do with QA.
"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?
-
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 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.
-
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.