Results 1 to 8 of 8
  1. #1

    Instant Process Improvement...

    I can't tell you how many times I've heard the story "QA people never have the authority to 'pull the plug' on whether or not software is released'. Up until last week, I was one of those people.
    The day of our release here, I noticed that somehow some code mysteriously crept into my testing environment. This environment is carefully controlled because what's in my environment gets moved into production. Anyway... the developers know not to publish their code to this environment, but still had the rights to the databases, and had the permissions to move their code there from their version control system. An hour before release, hmmmm... what's this???? THIS isn't supposed to be HERE!!! I obviously made the decision to 'pull the plug' on the release, marched over to the developers and informed them that we weren't releasing... asked my boss to come into his office with me, where I explained what happened.
    To make a long story short, I revoked the developers ability to publish code to the Test Environment, including my boss's. My boss's boss came to talk to me, looking for an explanation on what happened. After explaining it to him, I had his COMPLETE backing and trust. Although it makes my job a little bit harder, GOSH, it feels so good to FINALLY have the authority that we QA people have only dreamed about. And now, I'm viewed as this guy who's single-handedly making this company, and this software the VERY BEST IT CAN BE!!!
    Gosh, I love it when things work out like this!

  2. #2

    Re: Instant Process Improvement...

    Interesting. Please keep us informed periodically how this is working out long-term.

    I know that I don't want to be the sole arbiter of what goes into production and what doesn't.

    I want my QAers to be part of the bigger Engineering team tasked with getting releases into production.

    I want our activities to be viewed as support for that process, and not as gatekeeping activities.

    Had I noticed unexpected code in the test environment, I would likely have reacted similarly - sending out a serious warning and taking action. However, I always want the actual ship/not ship decision to be an informed business decision based on input from all parties.

    For me, being "this guy who's single-handedly making this company, and this software the VERY BEST IT CAN BE!" would be a bad thing. I want to help build a team which develops software meeting or exceeding all the business needs. If the quality gate were concentrated into any single hand, I'd feel like I didn't accomplish my mission.

    Every shop is different, though. I glad your new responsiblities are working out for you.
    Joe Strazzere
    Visit my website: AllThingsQuality.com to learn more about quality, testing, and QA!

  3. #3

    Re: Instant Process Improvement...

    I agree with you Joe... this company has been struggling with bad releases, and the development team has had it's share of mud in their face. When they hired me, they desperately needed processes. They needed someone to test the software and to concentrate on the whole release process. Am I a gatekeeper? No. Am I single-handedly making this company a good one? Again, NO! TRUE, I'm the only QA person here, and true, I made the decision to 'pull the plug' on the release and to revoke their ability to publish code to my environment, but I have been, and will remain a member of the team, and will always have my company's best interests at heart. I'm simply doing what they hired me to do, and I have everyone's complete support.

  4. #4
    Super Member
    Join Date
    Oct 2001
    Bucharest, ROMANIA

    Re: Instant Process Improvement...

    Good for you Jim, especially for having everyone's complete support. That's really good.

    Concerning the original topic title... I'd say that you have found a (process) bug, you addressed it, and it seems it was fixed...
    Don't worry, be Happy!

  5. #5

    Re: Instant Process Improvement...

    I was actually expecting alot of 'fall-out' from all of this. But the opposite happened. Full support from everyone. Thank yous. I'm not used to this!!!

  6. #6

    Re: Instant Process Improvement...

    This is how it always works.

    The authority to ship or not ship never resides in QA. It's a mistake to think it ever did. The authority has always resided in the CEO or the board of directors, or the self-funded founder of your company, whomever it may be in your case.

    The key point to Jim's story can be found in this quote:

    "My boss's boss came to talk to me, looking for an explanation on what happened. After explaining it to him, I had his COMPLETE backing and trust."

    What power QA has lies in our test methodology and the communication of information found through that methodology. By informing management of the problem and of the method by which the problem was introduced, Jim got approval for his recommendation to delay release as well as implement some access changes.

    It sounds like the management was already familiar with the havoc untested software changes can wreak so Jim didn't have to explain the risks in much detail. Other bosses still prefer to learn the hard way.

    Bravo, Jim. That is how it is supposed to work.
    Scott Sullivan
    Intelligent White Mice
    ... there's a better way.

  7. #7

    Re: Instant Process Improvement...

    If there has to be a sole arbiter, I would rather it was me than the development staff.

    However, I think all production decisions should be made by a quorum of management staff that are representative of all areas affected by the change. Not the Engineering Team or the Project Team, although they should be able to make recommendations, but by the management team.

    In this case, Jim did talk to management; they made the final decision. I think it's great they have enough respect for him and for his work to given him that level of support. In this case, Jim's "find" and his actions were the catalyst for making the system "The Best it Could Be". Overall, however, it was management's decision to avoid potential error that really tipped the scales. How refreshing. In similar situations, many QA/QC staff have had to bite the bullet...

    I'm not sure whether to offer congratulations or wallow in jealousy. Do you think, Jim, it will affect your working relationship with the development team? Or do they respect you for finding the change and calling them on it?


  8. #8
    Senior Member
    Join Date
    Feb 2000
    Minneapolis, MN

    Re: Instant Process Improvement...

    I'm with Joe on this in that I'd rather be left to make my recommendations to management and have them make the decision.

    Jim in your case, it sounds like there is no strong management in that area, so they were happy to let you take the lead in this instance.

    In the long run though, I'm a little skeptical about how your actions might affect the teamwork and synergy between QA and Development.

    Granted your actions were necessary to take by someone when code slips from DEV to QA without notice, but for QA to take the side that closes off permissions and shuts down releases, to me would damage the team spirit for a long time to come.

    But, do let us know. As someone else said, every shop is different. [img]images/icons/smile.gif[/img]
    Jean James
    I deliver what I promise, and I only promise what I can deliver.



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
BetaSoft Inc.
All times are GMT -8. The time now is 04:01 PM.

Copyright BetaSoft Inc.