|
At my workplace, we have implemented the concept of a Pre-QA Tester.
One of our brighter QA Testers now sits in the Dev area with a bank of machines. As the developers complete each piece of work, an in-house app is used to zip up the changed source files, and transfer them to an intermediate integration machine. The developers extract the changed files, and build the changed projects in release (with debug info). The Pre-QA tester then copies the binaries and pdb's etc to one of his machines, and begins tesing the specific feature being integrated. As this happens, the developers are running unit tests on the code base. If the unit tests run clean, the code is checked into the main code base. The Pre-QA tester, also checks the general health of the apps continuously.
Now this may sound like a lot of fuss just to check in some code (new developers are often taken aback with the process and the paperwork), but in some cases, the QA tester has failed the story on some strange platform, before the developer has even got to the point of checking the code in. If the same story had to wait for QA ( or post-QA as we call it), it could be up to a week, until the bug is discovered, if it is caught at all.
Since we implemented the Pre-QA tester, the number of defects reaching post-QA plummeted, and the kind of bugs they find, are rarely the no-brainer that developers put in every now and again. In as long as I can remember, there have only been a handful of failed builds, and that is doing 2 builds a day, 7 days a week.
if(E_NOINTERFACE == pThat->QueryInterface(IID_IUnknown,(void**)&pUnk))
{
// I aint no pUnk bitch!
}
|
|
|
|
|
QA department staffed by drunken morons.
-Jack
If things are as bad as they can be, you can be sure there'll be a brighter tomarrow.
|
|
|
|
|
They have "trained testing prfessionals" - is there a difference? 
TOTD: Doubleclicking a personalised menu will remove the personalisation.
|
|
|
|
|
Anyway, here is my answer:
QA department staffed by NOT WELL trained testing professionals
Mauricio Ritter - Brazil
Sonorking now: 100.13560 MRitter
![Jig | [Dance]](https://www.codeproject.com/script/Forums/Images/jig.gif) I've gone sending to outer space, to find another race
|
|
|
|
|
Mauricio Ritter wrote:
QA department staffed by NOT WELL trained testing professionals
Bummer. 
We have a mix - many of our testers are pretty good... others have some issues..
There are three types of people in this world: those who can count, and those who can't.
|
|
|
|
|
The problem with QA is, they don't know how the app works and therefore every "bug" is equally important to them. If a QA finds 2 typos on a web page, he will write formal reports and thinks that he has earned his paycheck for the day.
The problem with a developer is, he thinks that all users including QA should know how the app is implemented (give me a real bug to fix, don't bother me with trivial things).
|
|
|
|
|
This is where a decent functional specification is required. The developer can then code to this and then the tester can test against it. This solves all arguments about how things are supposed to work.
You'll never stop testers nitpicking over typos and the like. They enjoy it too much 
Michael
Programming is great. First they pay you to introduce bugs into software. Then they pay you to remove them again.
|
|
|
|
|
Black Cat wrote:
The problem with QA is, they don't know how the app works and therefore every "bug" is equally important to them
And too right, that is how it should be. A tester should not know how an app was implemented. A tester must come at it from a users perspective, tackle the app as if they were using it in the real world.
Black Cat wrote:
If a QA finds 2 typos on a web page, he will write formal reports and thinks that he has earned his paycheck for the day
Imagine the harm to a good companies image if such a simple thing as a typo is let through. You begin to wonder "if they let through a typo, what other bugs have they let through?"
I think the sheer simplicity of a typo bug makes it worse if it is let through than lets say a memory leek or something else which is hard to track down.
Black Cat wrote:
give me a real bug to fix, don't bother me with trivial things
Oooh, just wait for Christopher Duncan to get his teeth into that one
That goes along the "it is not my job" and "I am better than that" attitudes, which I cannot stand. Prima dona programmers make my management life a misery!
|
|
|
|
|
Paul Watson wrote:
And too right, that is how it should be. A tester should not know how an app was implemented. A tester must come at it from a users perspective, tackle the app as if they were using it in the real world.
Very true!
Paul Watson wrote:
Oooh, just wait for Christopher Duncan to get his teeth into that one
May I try first? 
Paul Watson wrote:
That goes along the "it is not my job" and "I am better than that" attitudes, which I cannot stand.
You are mixing two different things here.
"I am better than that" is definately a stupid attitude, specially if applied to the bug fixing or testing which I take is the context here. I will fix any bug for you, no matter I did it or someone else, no matter it's a typo or design flaw. I can participate in any part that belongs to the job I am paid for. But sometimes I have to say "it is not my job", simply because it isn't
Paul Watson wrote:
Prima dona programmers make my management life a misery!
I will only respect a manager who is at least as good at managing as I am at programming. I don't want to do his job (not my job!), nor I want to "compensate" for his lack of professional skills in management. Everyone needs to know their part of the job. And I certainly don't want to bare responsibility for all things related to production of a good software.
In the context, I do not care how the manager will arrange the testing of my code. I know how to make sure that the bugs are reduced to the minimun. He needs to know that's not enought and organize additional testing.
I C++, therefore I am...
|
|
|
|
|
George wrote:
I will only respect a manager who is at least as good at managing as I am at programming.
Great, that should hold true for everyone in any industry. Respect is very important in an efficient environment.
What I mean by prima donas are jerks who think they are better than everyone else in the office. They want only the "cool" jobs and as soon as a "cool" job becomes yesterdays cool they want a new thing. They complain, they blame their keyboard or their internet connection. They say everyone else sucks and that they are the only real programmer in the team.
You have to basically hand everything to them on a silver platter to get anything done. Most of the time they are more trouble than they are worth and you get rid of them.
While not a feature of a prima dona exclusively I do get annoyed with this: Programmers who do not care about anything but the code they write. They have no involvement in the rest of the company, no vision or understanding of a "work" environment. They think all they have to do is come in, code, then leave at 5pm and they will be fine, that the company will be fine. That is very short sighted IMO.
I like to work with people who care. Who are willing to do some dirty work and pitch in when the tough stuff comes along. When push comes to shove those are the guys I keep and the rest can go find somewhere else to complain.
|
|
|
|
|
Paul Watson wrote:
Great, that should hold true for everyone in any industry. Respect is very important in an efficient environment.
It wasn't me who said "manager" first, I am just trying to stay on topic.
Paul Watson wrote:
What I mean by prima donas are jerks who think they are better than everyone else in the office.
That pretty much desribes 90% of the workforce in any industry
Paul Watson wrote:
They say everyone else sucks and that they are the only real programmer in the team.
I used to think that the others are "still learning".
Paul Watson wrote:
You have to basically hand everything to them on a silver platter to get anything done. Most of the time they are more trouble than they are worth and you get rid of them.
That type of people do happen. Many of them will become managers later on (due to the above awerage ass-licking skills) and are the real pain to deal with.
Paul Watson wrote:
While not a feature of a prima dona exclusively I do get annoyed with this: Programmers who do not care about anything but the code they write.
That is more of a social attitude, and typically is independent on the coding and it's rather a personality issue. Of course you can't just focus on the code, it's not the way society works. Unless of course you are working on your own.
Paul Watson wrote:
I like to work with people who care. Who are willing to do some dirty work and pitch in when the tough stuff comes along. When push comes to shove those are the guys I keep and the rest can go find somewhere else to complain.
I like to work with professionals. They usually "care" (or they would not be able to be proffesionals).
You do dirty work if you have to, but it's way better to avoid the need to do dirty work in the first place!
I C++, therefore I am...
|
|
|
|
|
Paul Watson wrote:
memory leek
If I eat more of those will it improve my memory?
Bruce Duncan, CP#9088, CPUA 0xA1EE, Sonork 100.10030
'ugly naked women are good, when i'm not around, in front of someone else' - Shog9
|
|
|
|
|
Bruce Duncan wrote:
If I eat more of those will it improve my memory?
How embarrasing. Funnily enough I have been eating quite a lot of leeks lately. Spinach, leeks, bacon bits and white sauce is just great
|
|
|
|
|
Black Cat wrote:
The problem with QA is, they don't know how the app works and therefore every "bug" is equally important to them.
Actually all bugs are equally important. It's only the effort required to fix them that makes a difference and forces to prioritise them.
Black Cat wrote:
If a QA finds 2 typos on a web page, he will write formal reports and thinks that he has earned his paycheck for the day.
If it is a web page, I would say that typos are extremely important and probably one of the main focus of QA.
Black Cat wrote:
The problem with a developer is, he thinks that all users including QA should know how the app is implemented (give me a real bug to fix, don't bother me with trivial things).
I am a developer and I think that users shuld only know how to use the application, while QA should have one group that is familiar with the application usage and one group that knows nothing about it (so called monkey-test approach, where commands are issued at random to push the app to the limit and detect how it's dealing with non-standard usage patterns).
All bugs are real, but you should not let the trivial ones out to the testing team to begin with...
I C++, therefore I am...
|
|
|
|
|
George wrote:
If it is a web page, I would say that typos are extremely important and probably one of the main focus of QA
Odd you say that. Websites are filled with typos due to their content rich nature.
If I see a typo in a web page I gloss over it, but if I see a typo in a Windows app then I remember it and feel a bit more wary about the app I am using.
|
|
|
|
|
Paul Watson wrote:
Odd you say that. Websites are filled with typos due to their content rich nature.
OK, so what else would you test on a webpage? Links(which could be as well in the typo's category since it's probably the most common reason for links to be broken)?
I C++, therefore I am...
|
|
|
|
|
George wrote:
OK, so what else would you test on a webpage? Links
People do not seem to understand that a website is an application just like any other. Even one webpage can be complex.
So with that comes many areas that require testing. Content, links, validation, scalability, security etc. etc. etc. Everything and more that one would test for in a Windows app. Plus there are extra things to test for, like if half way through a set of five forms what happens when the user uses the back button to change something? Does the web-app cover that? Or will it fall over.
Just ask Chris what developing, testing (stabilising), deploying and maintaining a web site is like. It is not for monkeys 
|
|
|
|
|
Paul Watson wrote:
People do not seem to understand that a website is an application just like any other.
Well, maybe it's because it actually isn't?
I mean, it doesn't look like one, it doesn't act like one, and it's slow. Nothing like a serious application, more like an application wannabe - so what do you expect?
Paul Watson wrote:
Just ask Chris what developing, testing (stabilising), deploying and maintaining a web site is like. It is not for monkeys
And on the other hand, it's far from the proper application development process as well.
I C++, therefore I am...
|
|
|
|
|
George wrote:
Paul Watson wrote:
People do not seem to understand that a website is an application just like any other.
Well, maybe it's because it actually isn't?
Got news for you George, web based applications are big business, creating millions of dollars of income for developers and and consuming millions more in hardware and servicing costs.
George wrote:
And on the other hand, it's far from the proper application development process as well.
Because of the large amounts of money invested into these projects, process is very much adhered to. Testing is done by very qualified people representing the business and their interests. These people run test scripts rated against the original requirments ( and subsequent change requests) and produce defect reports. The impact of these defects are assesed by the business sponsers and application architects and given a priority for repair. The business, after basic functionality, tends to favour fixing presentation defects.
I pride myself on trying to write error free code, but have yet to find someone who can (including myself). I respect those who can do the repetitive and often mundain task of testing my code ( after I have released what I believe to be error free and unit tested) and welcome the oppertunity to fix defects I know are of my doing. As an architect and team leader I encourage people to work with the testers as they are, as are developers, a nessesary part of the process.
J
|
|
|
|
|
Light up. I like the post that said
"Programming is great. First they pay you to introduce bugs into software. Then they pay you to remove them again."
Seriouly, no one wants to create bugs. Unfortunately, even with the best efforts, bugs do pop up in the worst moment. In the real world, everything has certain priority, so are the bugs.
I just don't see how you can treat all bugs equally.
|
|
|
|
|
Black Cat wrote:
The problem with QA is, they don't know how the app works and therefore every "bug" is equally important to them. If a QA finds 2 typos on a web page, he will write formal reports and thinks that he has earned his paycheck for the day.
The problem with a developer is, he thinks that all users including QA should know how the app is implemented (give me a real bug to fix, don't bother me with trivial things).
And interestingly, the "truth" is somewhere between. In our company, (in theory) the testers log problems, but a separate person (or group) determines how severe it is. For instance, if the code crashes during normal operation, that's considered severe. If a particular piece of text is bold when it should be italics, then that is considered less severe.
The decision to fix something, then, is based on: how much time do we have, how severe is it, and how much code will it take?
However, we do spend a lot of time fixing seemlingly cosmetic stuff (e.g., text). This is especially important when our apps get translated... users hate when a button that was the right size in English turns out to be too small in Spanish, and text is cut off.
I actually don't mind fixing "trivial" things, because they are usually easy to fix. It's the nasty crashes that point to design flaws that are the problem.
There are three types of people in this world: those who can count, and those who can't.
|
|
|
|
|
Testing is part of the development process. This might seem obvious to some, but suprisingly many people do not understand what it means. This is probably due to the idea that "QA will do testing". That idea has the effect of designating testing to QA and programming to Development, thus separating the two. Once separated the satement "Testing is part of the development process" does not hold true anymore and this can have disasterous effects.
I fully agree that QA does the testing, what I disagree with is the way in which development and testing become segragated from each other as an effect. The effect is natural since Testers are employed to do testing and Programmers are employed to do programming, thus creating two 'groups' of people.
What could be done about this? One idea is to only employ programmers and work with a rotation system. For example, a programmer would become a tester for one week every month. Another idea is for the product manager to be a qualified software engineer who is also head of QA.
Whatever method is used the aim should be to keep testing and development process intact.
Regards,
James Pullicino
Drinking In The Sun
Forgot Password?
|
|
|
|
|
I agree with most of that. In our job descriptions, we programmers are not to rely solely on QA to test our products, we have to test them ourselves. QA is good for testing cases we probably didn't think of, for doing regression tests, tests on different operating systems, etc.
Programmers are good at general testing (does the app do what it's supposed to without crashing), unit testing (which requires knowledge of the code), and such.
There are three types of people in this world: those who can count, and those who can't.
|
|
|
|
|
[James Pullicino] wrote:
Testing is part of the development process.
Sure. I agree to testing the code I wrote to ensure it does what was intended by the customer (as defined in the requirement paper). Testing the functionality of the coded unit before giving it to the QA staff is therefore essential.
The QA staff in our house will do the overall testing (testing really all features after a qualified plan), finding bugs and wrong behaviour or side effects which are not obvious to the developers.
Regards,
Erik.
The opinion expressed here is solely mine.
|
|
|
|
|
That gives me time to create new and more interesting bugs while s/he finds the last lot.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
