January 26, 2014 at 11:23 am
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
January 26, 2014 at 12:38 pm
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 [font="Arial Black"]might [/font]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
Change is inevitable... Change for the better is not.
January 26, 2014 at 4:36 pm
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
January 26, 2014 at 6:27 pm
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
Change is inevitable... Change for the better is not.
January 26, 2014 at 10:06 pm
Jeff,
Again thanks for your insights.
edm2
January 28, 2014 at 8:34 am
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.
January 29, 2014 at 11:14 am
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.
January 31, 2014 at 3:34 pm
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.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply