Results 1 to 4 of 4
  1. #1

    dealing with product deployment/implementation teams

    Currently, I am attempting to build a QA process from the ground up. One of the problems I've been running into is that we have a separate department that is responsible for deployment of our client/server/database and web/database applications. There is always tension between this department and the development department.

    To complicate matters, the deployment department actually writes some code to support the deployment, and as such, is kind of in a gray area as far as job roles. They're not really IT, they're not really development, and they're not strictly deployment, either. That said, they never ask anyone to test their work (saying that they deliver only bug free software).

    I have no idea how to deal with them. There is sort of a brick wall between my role (as the sole QA person) and their group. What have any of you done in a situation like this?

    Testing software since 1996

  2. #2

    Re: dealing with product deployment/implementation teams

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by pookietooth:
    That said, they never ask anyone to test their work (saying that they deliver only bug free software).

    So do they in fact always deliver bug-free software?

    - If so, learn how!

    - If not... well it's obvious, isn't it?

    Who gets to decide if something is to be delivered without any testing? Have a long talk with that person. Make sure your QA Plan notes that some software is going out untested. Make sure your plan is read and understood by management.

    - Joe (strazzerj@aol.com)
    Joe Strazzere
    Visit my website: AllThingsQuality.com to learn more about quality, testing, and QA!

  3. #3

    Re: dealing with product deployment/implementation teams

    I think Joe hit the nail on the head with the idea that you want to document your concerns ahead of time, and make sure the appropriate stakeholders have read it and signed off. Either someone with the necessary clout to make things happen will require a change in the process, or (worst case) when something goes wrong they won't be able to come down on you later for not warning them.

    Though not directly involved, I've been in a somewhat similar situation where our customer support group was creating s/w tools to support the installation and management of our products. Initially they were pretty much loose cannons. Once somebody wrote up a bug report pointing out a security hole due to one of their tools, a couple heads rolled and now they're under the same process and CM control as the development group.

    Charles Reace

    Software Testing (n): 1. The art of trying to increase your confidence in a piece of software by finding everything that is wrong with it.

  4. #4
    Senior Member
    Join Date
    Jan 2001
    Toronto, Ontario, Canada

    Re: dealing with product deployment/implementation teams

    creace is correct when they said that you need to document the fact that code is being directly released to the client without testing. Access a risk rating to this continued practice.

    Another method (although it won't make you popular with this group) is to test their scripts during your *down time* one day. I'm sure you'll find something, but anything should raise flags once they realise that this group is operating without a saftey net.

    Good Luck!




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 05:23 PM.

Copyright BetaSoft Inc.