views:

60

answers:

4

In the place I work, very often it happens that a developer and QA session goes like this: (This is in reference to SQL Server 2005)

QA: I get Invalid object name 'customers'
DEV: huh? can u send me the exact SQL statement you used?
QA: select * from customers
DEV: hmm. (after some thinks) Are you sure you're using CUSTDB?
QA: yes
DEV: (after figuring out that QA was using CUSTDB_PRODUCTION) Please add "USE CUSTDB" and then tell me what you get with that SQL.
QA: Oh, sorry, I was using wrong DB.

The tab-text for the SQL window shows the information of which database the query is running on, but how do you ensure that QA follows this?

I will admit that I have made this mistake of using the wrong DB many times. I don't tend to read the text in the tab.

What are your experiences with this type of scenario? Have you found a way to help mitigate such a problem?

+2  A: 

if your QA is using SSMS for testing you should try the window coloring options in SSMS Tools Pack free add-in for SSMS. this way you could immediately differentiate between servers.

if that's not an option don't allow QA to access production server at all. they shouldn't be able to anyway.

Mladen Prajdic
This sounds promising. Will give it a go. QA had better not come back to me saying the "tab is red" when it ought to be "purplish-yellow" :DBtw, if this doesn't work, i'm coming to get you.
Liao
+1 why have QA got access to the live DB?
Kev Riley
@kev: QA has read-access to the production DB, solely for when the customer reports a problem. we're the first line QA for the customer as well.
Liao
Thanks for that tip! Awesome.
Sam
A: 

I think you need to formalise how QA will report an error.

You need to specify a set of information that they'll supply with every error report, including:

  1. what they were doing (exactly)
  2. their configuration (including the database!)
  3. time/date (so you can match stuff in logs)
  4. how to repeat it (if repeatable)

etc. You can act on that immediately, or log it in an incident tracking system and come back to it later (in which case the above is invaluable, otherwise it's all lost).

The above can be as simple as an email draft/template. But you need to be rigorous about this, otherwise (as you've discovered) you're going to go round in circles, perhaps without all the salient information you require.

Brian Agnew
I completely agree with you, but the "problem" with my company is that things are "super customer dependent". I really wish I could follow your steps to the max, but given that we are *so* customer oriented (not that i like it), your method fails. It's something I really want to push, but no luck so far.
Liao
A: 

If QA are allowed access to both live and dev databases, using SSMS, then there must be some level of accepted responsibility on their part and/or some level of training of them on your part.

They have been given a tool that allows them to ask questions of the data, but are asking the wrong questions, then complaining to you - if I was the DBA, I'd simply remove their access until they could demonstrate they knew what they where doing! I sympathise that that might not go down to well, but at least threatening to do it might make them think a little for themselves.

Think of this question as 'someone is doing something wrong'

There are 2 simple answers:

  • remove their ability to 'do something wrong'
  • train them to do it right


On the same note as Mladen Prajdic, you can colour code query windows in SQL2008 SSMS too.

Kev Riley
A: 

Personally I use the fully qualified name in all queries (server.datatabase.owner.table - well I only use server if I'm deliberately using a linked server) because I move from database to database so much. If you specify the database in the queries to be run, they still work if connected to a differnt database on the same server or if you have a linked server. Have your QA adopt doing this as their standard if they are writing their own queries; if you are writing the test queries then you should be specifying the database name in the query not through a use statment.

HLGEM