|
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
|
|
|
|
|
I guess you didn't read what he wrote and you repeated.
Munchies_Matt wrote: So far
From little acorns mighty cockups do grow...
"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: From little acorns mighty cockups do grow...
But great oaks don't grow from marshmallow.
"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 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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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 
I'm assuming that the quote is a play on "Who will guard the guards?[^]"?
|
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
RyanDev wrote: we should hesitate to be so bold in our assumptions
While I would normally agree with this statement, in this instance I cannot. I've seen it often enough that I've just taken to thinking its human nature, or a take on the Peter Principle.
|
|
|
|
|
RyanDev wrote: 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.
I worked in a place like that. What a mess. 
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
Well, there were only 2 of us developers and we we're awesome so it worked ok.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
jeron1 wrote: 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.
And probably an order of magnitude more minutes in people's time to assign a ticket number, approve it into a development cycle, estimate it and account for it in the project plan, etc.
|
|
|
|
|
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!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
