Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

QA and DB Design team sleeping in same "bed"? Expand / Collapse
Author
Message
Posted Sunday, January 26, 2014 11:23 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Monday, July 14, 2014 11:18 AM
Points: 865, Visits: 869
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



Post #1534797
Posted Sunday, January 26, 2014 12:38 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 8:06 PM
Points: 36,786, Visits: 31,243
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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1534809
Posted Sunday, January 26, 2014 4:36 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Monday, July 14, 2014 11:18 AM
Points: 865, Visits: 869
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



Post #1534830
Posted Sunday, January 26, 2014 6:27 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 8:06 PM
Points: 36,786, Visits: 31,243
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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1534835
Posted Sunday, January 26, 2014 10:06 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Monday, July 14, 2014 11:18 AM
Points: 865, Visits: 869
Jeff,

Again thanks for your insights.

edm2



Post #1534845
Posted Tuesday, January 28, 2014 8:34 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Today @ 8:10 AM
Points: 861, Visits: 2,360
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.
Post #1535496
Posted Wednesday, January 29, 2014 11:14 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Today @ 6:30 PM
Points: 49, Visits: 231
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.
Post #1536054
Posted Friday, January 31, 2014 3:34 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 4:10 PM
Points: 33,095, Visits: 15,202
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
Post #1537011
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse