Please register to participate in our discussions with 2 million other members - it's free and quick! Some forums can only be seen by registered members. After you create your account, you'll be able to customize options and access all our 15,000 new posts/day with fewer ads.
I've talked with developers before to see if they had requirements since.. no1 else had them.
Fair question...but the way our system works, the requirements should be attached to the user story. If they aren't, then there aren't any. If I'm working off no requirements, I document my assumptions in the user story. So...read it, and then you'll know what I know. But I share your frustration here.
Quote:
I'm assuming they've been told that bugs had to be reproducible, had to have steps to recreate, and with info on versions?
Also a good question, but the screenshots are attached to the user story with no context and no steps to reproduce. Usually, we don't even know what server they're on because they crop out that part of the image. They'll put a red box around what doesn't look right to them and say something like "Improper values allowed in <name of box>" or "Running monthly total does not tie." Tie to what? What "improper value"? They don't tell us that. I always reject those bugs on general principle, but they never seem to learn from it.
I've noticed that QA professionals from a certain country always do QA this way; it's like they all went through the same training class: "How to suck at QA." And they don't all do it this way, but everyone who does it that way is from that country. Make sense?
As a developer, I require the following from QA:
1.) Expected result (even if you don't have requirements to back this up...use common sense)
2.) Actual result
3.) Exact steps to reproduce including environment and all options entered/boxes checked/radio buttons selected/etc.
If they do 1-3 properly, screenshots are not required.
Quote:
Curious.. so this would be due to the pM's decision to implement such a change?
No, one has nothing to do with the other. Certain QA people seem to have trouble grasping the concept of scope. That's OK; I get that a lot of QA people don't necessarily have a technical background and are still learning. I'm happy to explain it to them, but they also have to be willing to listen to and accept my explanation. A lot of the new breed of QA people refuse to accept what I say and continue to insist that this plane crash over here on the left was caused by a cat licking its butt over here on the right.
So are we done here... Time well spent for both of us right? Is their some formal conclusion we can come to a censuses on now?
I shouldn't say men don't gossip, we gossip all the time about the new co-workers booty or what we did with the bar chick we met for the first time the other night lol......
In all seriousness if there is something frustrating you that a colleagues does either speak up to them or shut up. It's not beta behavior to talk behind someone's back, it's very weak passive behavior that does nothing to solve the problem..
I'm sure most people on here aren't taking this forum that serious where they are venting any serious deep felt anger that they have been holding in until now because someone created a thread that gave them an outlet to vent, yet I still have to encourage people to be more proactive and speak up instead of "gossip" if they have a problem.
LOL. Still you don't get it X number of posts latter.
And I am sure the "bar chicks" eat up all that manly talk about psychology and "invisible energy".
Don't get me started! I have a co-worker who does not know how to use proper grammar or punctuation. She even talks using words such as "dey", "dem" and "mines". Very nerve racking. Then has a question about everything. Been there for a year and a half. You would think she was brand new. But then again, always playing on her cell phone during meetings, so there you go. Has no clue what is going on. And she likes to pick up new tasks before she finishes one. She also uses her kid as an excuse to work from home, etc. Never goes above and beyond, yet I work on the complicated items. BTW, we work in IT, so items that come in are worked on in order. Not, pick and choose easy tasks.
People who keep trying to push their work off onto other people.
People who don't pay attention to the same thing you've told them *literally fifteen flippin' times* (and I have the emails to prove it) and keep asking you for the information and to explain the issue again. Don't get surprised if I start treating you like an idiot at this point. I get having to explain once. I can even understand having to provide the information a second time--emails can get accidentally deleted or misfiled. But if we're going into my having to provide the same information *again* every time we talk because you 'can't find it' and you 'don't remember what we said', then there's an issue, and I'm getting pretty aggravated, because I have other things that need my attention.
Refusing to take notes when I answer technical questions, then coming to me and asking me the exact same question again. And again. And again. And again.
Demanding that I (the developer) tell them (the QA person) exactly what their test cases are and how to execute them. No! Go bother the BA; they're the ones who should have written requirements. If I was going to take the time to tell you how to do your job, I'd just test the code myself. Why do we need YOU if you don't know how to do the job?
Reporting "bugs" using a single screen shot. STOP THAT.
Refusing to understand that I (the database developer) could not have caused an issue with data validation on a field in a .NET application when I changed the stored procedure that runs an SSRS (SQL Server Reporting Services) report. No, no, no. Not mine, not a regression error, out of scope, go bother the project manager if you want it fixed.
Refusing to learn simple SQL and expecting me to write queries for them. Uh, no. At least put in some effort.
Sounds like you have very junior QA there.
About the test cases I will give you a simple example:
The BA req is: User should be able to open his account when the user enters a 5 digit code into the text box at the account page and clicks ok.
Now, to get this 5 digits code you need to perform 4 hours of data setup, including complicated SQL joins, and the BA has no clue how to do it technically. That's why they, usually junior QAs who get 50% of your hourly rate, are coming to you, as you know all the technical aspects of the new functionality of the app.
Also a good question, but the screenshots are attached to the user story with no context and no steps to reproduce. Usually, we don't even know what server they're on because they crop out that part of the image. They'll put a red box around what doesn't look right to them and say something like "Improper values allowed in <name of box>" or "Running monthly total does not tie." Tie to what? What "improper value"? They don't tell us that. I always reject those bugs on general principle, but they never seem to learn from it.
I've noticed that QA professionals from a certain country always do QA this way; it's like they all went through the same training class: "How to suck at QA." And they don't all do it this way, but everyone who does it that way is from that country. Make sense?
As a developer, I require the following from QA:
1.) Expected result (even if you don't have requirements to back this up...use common sense)
2.) Actual result
3.) Exact steps to reproduce including environment and all options entered/boxes checked/radio buttons selected/etc.
If they do 1-3 properly, screenshots are not required.
It's so strange. Writing a decent bug is an absolute basic of QA. I really don't get where did your bosses found those people. In every interview I ask the applicant to write a bug. If he doesn't have clear and detailed steps, expected, actual, and a screenshot/video, he is out.
Sounds like you have very junior QA there.
About the test cases I will give you a simple example:
The BA req is: User should be able to open his account when the user enters a 5 digit code into the text box at the account page and clicks ok.
Now, to get this 5 digits code you need to perform 4 hours of data setup, including complicated SQL joins, and the BA has no clue how to do it technically. That's why they, usually junior QAs who get 50% of your hourly rate, are coming to you, as you know all the technical aspects of the new functionality of the app.
They're all from India; sorry, but it's the truth. Our BAs usually have no clue about anything and don't care to learn...for some reason, we insist on hiring non-technical BAs even though they've proven time and again to be completely ineffective in our environment.
If the change can only be seen on the back end and requires anything more than a fairly basic SQL query, I will provide a validation script for QA and tell them what the expected result is. Sometimes the fix can be verified through the front end, but I don't know how to do it because I don't write front ends. I unit test on the back end. If I don't know how to view the change via the GUI, I'll refer them to an application developer (I'm a back end developer, most of our app devs are middle tier & GUI guys).
Even under those circumstances, I have had some come to me and say "I don't have SQL on my machine" or "I don't know how to run a SQL query." I offer to teach them and they say "I don't want to learn, I am automation specialist." Those exact words have been spoken to me as a response to an offer of help.
Quote:
Originally Posted by mash123
It's so strange. Writing a decent bug is an absolute basic of QA. I really don't get where did your bosses found those people. In every interview I ask the applicant to write a bug. If he doesn't have clear and detailed steps, expected, actual, and a screenshot/video, he is out.
I know exactly where they found them: H1B-reliant companies who think any living humanoid with an IQ above room temperature can do QA.
Hint: They're wrong.
If I were interviewing the QA people, the last three hires wouldn't have happened. They're all useless.
Please register to post and access all features of our very popular forum. It is free and quick. Over $68,000 in prizes has already been given out to active posters on our forum. Additional giveaways are planned.
Detailed information about all U.S. cities, counties, and zip codes on our site: City-data.com.
Please register to participate in our discussions with 2 million other members - it's free and quick! Some forums can only be seen by registered members. After you create your account, you'll be able to customize options and access all our 15,000 new posts/day with fewer ads.
Yikes.
The real life trolls thinking of themselves as "alpha males" are incredibly annoying.
