SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


QA and DB Design team sleeping in same "bed"?


QA and DB Design team sleeping in same "bed"?

Author
Message
Barkingdog
Barkingdog
Ten Centuries
Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)

Group: General Forum Members
Points: 1351 Visits: 921
The DB Design team had a review meeting with the QA folks. At the last meeting one QA team member was really "pissed off" that the Design team had changed the DB schema in substantial ways without informing them that this was happening at the time. That purpose of the review meeting was to inform them what we had done but they wanted to be involved in our design meetings. One the one hand their involvement and interest is appreciated. One the other hand it increases design time and I think don't they need to know every reason behind every DB design decision we make. (I think that "black box" testing by QA is a good thing and intimate knowledge of the box contents could compromise their testing -- for the worse.). Company "politics" aside where do you come in on this?


TIA,
edm2



Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)

Group: General Forum Members
Points: 86664 Visits: 41101
Personally, I think having the QA Team in design meetings is one of the most valuable things that can be done in a project provided that a true bi-directional dialog can be done. I don't believe in holding back any "Black Box" technology from the QA Team because they can provide invaluable insite that Developers and Planners will sometimes miss simply because they're too close to the problem and also have the tendency to only think "happy path" when it comes to testing.

That brings us to your subject of a QA person getting "pissed off" in a design meeting. "It Depends" on why that person was "pissed off". If it was only because they suddenly have more work to do because they need to change their test plans, then that person was might be out of line. Just remember that such changes can make the QA Team "look bad" because such changes mean that they're going to get the product to test later but no one considers the schedule they're being held to. If that's what the real gripe was, then the "piss off" needs to be carefully listened to because it's a real problem that needs to be addressed or bad product could go out the door.

Learn to embrace such conflicts in a thoughtful manner. There's almost always something good that will come out of them because conflict can be the leading cause of innovation. A room full of "yes-men" may be similar to a room full of Lemmings ready to follow the leader over the cliff. ;-)

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Barkingdog
Barkingdog
Ten Centuries
Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)

Group: General Forum Members
Points: 1351 Visits: 921
Jeff,

Thank you for your thoughtful answer. They were annoyed because we had a general DB plan laid out, as presented in "review meeting 1", but because of several "surprises" encountered the DB team was forced to redesign several tables and relationships. These changes were unexpected and only completed about 2 days before "review meeting 2", where they were presented to the QA team. I appreciate your comment about QA needing time to make changes to their scripts but it seems a bit "optimistic", to me, to script for a design that has not been finalized. In this case if would have been better to have the QA members attend the hands-on DB working but I don't know if that is a good precedent.

edm2



Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)

Group: General Forum Members
Points: 86664 Visits: 41101
Barkingdog (1/26/2014)
These changes were unexpected and only completed about 2 days before "review meeting 2"...


I guess I understand their outrage, then. I could be wrong but I've always understood that Design Review Meetings were supposed to happen before new changes and to discuss the status of previous changes. When the problem(s) were first discovered, it would have been prudent to have an urgent unscheduled Design Review Meeting. Yep... that's going look like it's going to slow things down a bit but, in the long run, it will grease the skids for a smooth load because the whole team has been informed. Yeah... QA is a part of the team that Design and Development is on. Everyone has to remember that they're all working for the same company.

To coin a parable, if someone lifts the log from just one end, the other end will still be on the ground and it'll be a real drag (sorry about the pun) to move it to where it needs to be in a timely fashion. Sure, it'll look like work is being done immediately but it would be much more effective and timely to get the team together, explain the plan, maybe take a couple of suggestions on the best way to lift this particular log and what path to follow to the destination, get everyone into position, and then call out "Readyyyyyy! 1... 2... 3.... LIFT!".

As a similie, it'll also keep the log from getting so dirty and it might help keep from dropping the log because everyone knows which way to walk with the log. ;-)

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Barkingdog
Barkingdog
Ten Centuries
Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)

Group: General Forum Members
Points: 1351 Visits: 921
Jeff,

Again thanks for your insights.

edm2



Nadrek
Nadrek
SSCommitted
SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)

Group: General Forum Members
Points: 1901 Visits: 2729
Jeff Moden (1/26/2014)

I guess I understand their outrage, then. I could be wrong but I've always understood that Design Review Meetings were supposed to happen before new changes and to discuss the status of previous changes.


I'd be outraged too if I was supposed to be in design meetings and was instead told about a change after it was "complete", rather than after it was requested/noticed.

I'm going to agree with Jeff completely; given a competent QA team, having them involved in the requirements and design phases is incredibly valuable. You save time later on when you don't have to explain to them what's going on, you save time in the middle when you know what they need before your write up documentation for them (instead of after, requiring rewriting), and you get a completely different set of insights from a group which often has the closest thing to many aspects of an end user's point of view as exists in IT.

Let me say that again - a good QA department's suggestions at requirements and design time are as close to an end user's suggestions would be as you're going to find in IT. QA tends to want things well defined, wants to know they'll be usable, wants to know they'll work right when things are right and break in the desired manner in exception cases, and if you're very lucky, wants to know that the software will have a good workflow and fit well into the rest of the workflows. Likewise, if you're lucky, QA works with all the various groups, and may have some insight into what other teams have tried or need. With a good QA department, you can end up with much happier end users, and with better products.
xsevensinzx
xsevensinzx
SSCrazy
SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)

Group: General Forum Members
Points: 2050 Visits: 2700
Very true Nadrek.

I worked in game development for 7+ years. It was always critical to have QA involved in the reviews. Maybe not every tester, but leadership present is valuable. Like Nadrek mentioned, they are as close to the end user as possible. It wil save a lot of time in the long run when you start including them more rather than blocking them. That's because you are one piece, not the entire pie.

Overall, you should not fear non-developers/designers from dictating your outcome. They are there for influence to help you take the right path with your changes. You can either chose to accept feedback or ignore it. The choice is still up to you.
Steve Jones
Steve Jones
SSC Guru
SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)

Group: Administrators
Points: 62985 Visits: 19111
Personally, I'd look to implement QA sooner in the process. If developers are looking to design differently, this can affect QA, so having them be aware is important. It can make the entire process smoother.

However, I'd make sure QA knows that "informed != getting to design". Instead I'd look for someone in QA that can handle hearing about potential changes without getting worked up. If they are aware of what might be done, they can be thinking about the impact to QA. However, they do have to know that they can't begin changing their test process until the design is finalized.

Takes a very level headed, thoughtful person to do this.

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search