Welcome to the Lounge

BobJanova10-Apr-14 22:50

BobJanova

10-Apr-14 22:50

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.

JimmyRopes10-Apr-14 22:53

10-Apr-14 22:53

BobJanova wrote:
and the tester knows his limits when it comes to coding.

What coder knows his limits? Unsure | :~

The report of my death was an exaggeration - Mark Twain

Simply Elegant Designs JimmyRopes Designs

I'm on-line therefore I am.
JimmyRopes

SortaCore10-Apr-14 23:43

10-Apr-14 23:43

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.

JimmyRopes11-Apr-14 0:29

11-Apr-14 0:29

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

SortaCore11-Apr-14 0:37

11-Apr-14 0:37

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.

JimmyRopes11-Apr-14 0:42

11-Apr-14 0:42

If you are not a programmer why did you change the code? D'Oh! | :doh:

The report of my death was an exaggeration - Mark Twain

Simply Elegant Designs JimmyRopes Designs

I'm on-line therefore I am.
JimmyRopes

SortaCore11-Apr-14 0:48

11-Apr-14 0:48

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.

JimmyRopes11-Apr-14 0:59

11-Apr-14 0:59

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

SortaCore11-Apr-14 1:04

11-Apr-14 1:04

Ah, I did say "outside of variables" in my post.
Changing variables is definitely inviting trouble. I agree with you on that point.

JimmyRopes11-Apr-14 1:08

11-Apr-14 1:08

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

jschell11-Apr-14 8:50

jschell

11-Apr-14 8:50

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.

Michael Haines11-Apr-14 1:05

11-Apr-14 1:05

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

JimmyRopes11-Apr-14 1:14

11-Apr-14 1:14

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

Michael Haines14-Apr-14 4:51

14-Apr-14 4:51

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

JimmyRopes14-Apr-14 5:56

14-Apr-14 5:56

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. Unsure | :~

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 Haines15-Apr-14 0:35

15-Apr-14 0:35

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

JimmyRopes15-Apr-14 2:24

15-Apr-14 2:24

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. Unsure | :~

The report of my death was an exaggeration - Mark Twain

Simply Elegant Designs JimmyRopes Designs

I'm on-line therefore I am.
JimmyRopes

Deflinek11-Apr-14 2:56

Deflinek

11-Apr-14 2:56

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 Wink | ;)

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."

Michael Haines14-Apr-14 4:57

14-Apr-14 4:57

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

JimmyRopes14-Apr-14 5:51

14-Apr-14 5:51

Michael Haines wrote:
My QA is made up mostly of analysts who don't want to code - at all.

A blessing in disguise. Unsure | :~

The report of my death was an exaggeration - Mark Twain

Simply Elegant Designs JimmyRopes Designs

I'm on-line therefore I am.
JimmyRopes

Dan Neely11-Apr-14 2:29

Dan Neely

11-Apr-14 2:29

As long as it's limited to typo level fixes I don't have a problem with it, provided you have someone reviewing every change the tester makes. I'd be leery of letting someone just brought in to test try to fix anything more complex though; for the same reason I'd be leery about bringing a new dev into the project a week before release. I'm not as dogmatic as Mark is, because real world staffing constraints mean you can't always do things the best way; and it's still a step up from the same group of devs who wrote the app doing all the testing. (Nevermind not actually doing any formal testing before release at all. *shudder* BTDTGTWTF)

Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius

Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt

Naeem ul Haq11-Apr-14 3:36

Naeem ul Haq

11-Apr-14 3:36

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 | [Coffee]

mBuchwald11-Apr-14 4:04

mBuchwald

11-Apr-14 4:04

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.

jschell11-Apr-14 8:44

jschell

11-Apr-14 8:44

Kieryn Phipps wrote:
Thoughts?

Who QA tests the QC lead's fixes?