Manual automated tests



  • I just discovered that our system has a pile of automated tests. *joy*

    I also discovered that although we have Hudson, we do not use it to automatically run said automated tests periodically.

    Why? Because the way it's set up, the automated tests will start our db-wrapper-server, tomcat and our application-server. However, they don't  start the queue manager.

    As such, we must manually start the queue manager, then run the tests, then manually stop the queue manager.

    Why? Because the port is being multiplexed, and they don't want the tests failing if the messages get pulled by something else other than the tests.

    Wheeee...

     



  •  That's sad.  Can't you put your test environment on a seprate network?  <insert rant about people who will spend millions of dollars on developers but almost no resources on equipment for testing, then expect the software to work in production>



  • @dogbrags said:

    <insert rant about people who will spend millions of dollars on developers but almost no resources on equipment for testing, then expect the software to work in production>

    Yes, this is my "people who apparently run software development but have absolutely no idea how much things actually cost, especially payroll" rant. Which seems to be the cause of something like 80% of the WTFs on this site.



  • @dogbrags said:

     That's sad.  Can't you put your test environment on a seprate network?  <insert rant about people who will spend millions of dollars on developers but almost no resources on equipment for testing, then expect the software to work in production>

    What test environment? QA, pre-prod and dev are all the same box, in use by 10 developers, 2 qa folks, 4 DBAs, 3 SAs and any number of managers. To be fair, it's a pretty powerful machine, but it's so overloaded...


  • @snoofle said:

    QA, pre-prod and dev are all the same box
     

     Think yourselves lucky that doesn't include production.




  • @snoofle said:

    @dogbrags said:

     That's sad.  Can't you put your test environment on a seprate network?  <insert rant about people who will spend millions of dollars on developers but almost no resources on equipment for testing, then expect the software to work in production>

    What test environment? QA, pre-prod and dev are all the same box, in use by 10 developers, 2 qa folks, 4 DBAs, 3 SAs and any number of managers. To be fair, it's a pretty powerful machine, but it's so overloaded...
     

    Come on.   YOU should be pushing hard for a separate QA environment that closely resembles the production environment.  QA testing must ensure that the system under test is locked down and can't be changed by devs; (both so that QA knows what they're testing -- software and data -- is set up as needed for each test; and that an issue can be reproduced so that QA can re-test after dev has fixed it).

    All it takes is one major bug that is not caught by QA, that would have been caught if they had a better environment, to justify the expense of a separate environment.

    And if you still can't convince the PHB that you need more equipment, well then it's time to look for some other place.

     


     

     


  • ♿ (Parody)

    @dogbrags said:

    Come on. YOU should be pushing hard for a separate QA environment that closely resembles the production environment.

    LOL. Yeah, PHBs love taking orders from temporary contractors.



  • How beefy are your desktops? Grab a copy of VMWare, make a dev disk image, and pass it along to all the devs. That'll take tons of pressure off the "everything" server.



  • @boomzilla said:

    @dogbrags said:
    Come on. YOU should be pushing hard for a separate QA environment that closely resembles the production environment.
    LOL. Yeah, PHBs love taking orders from temporary contractors.
    No kidding...  I've seen it before; when shit hits the fan and as long as you've done your due dilligence (saving emails, memo to note, etc), then you're generally covered.  I've seen it go up the chain *past* the CIO to the board, and voila, new CIO...


Log in to reply