Hot answers tagged

9

Does this actually catch, before production, many of the "surprise" problems we might anticipate? Or is there a more fundamental flaw in the approach that will cause deleterious changes to pass testing and affect production? You are wise to have a test system that you can use for catching performance issues, but your "scaling" approach is flawed. ...


9

No. The items you mention scale very differently and there are far too many factors and resources that will get used. For instance if I time requests on a local server using an application I'll find things like 1 user = 10 second response average (time per request) 10 users = 2.5 second average 100 users = 2.5 second average 1000 users = 20 second average ...


5

Presumably the database is just a piece of your overall system, and your goal is to determine whether database changes break things or slow the system down. Using a downsized database is a reasonable way to check whether database changes break things. I'm not sure it makes sense to use a downsized database for load testing. Whether this makes sense ...


3

There are several tools available over the web but my favourite one is Octopus Deploy, because after a relative simple configuration it can deploy your build, setting up automatically your testing environment. The configuration can be done through a user friendly interface and, it's important at least for me, it's free for a limited number of "tentacles" ...


3

Generally you should think of tests as doing Setup Execution Given X, When Y happens, Then expect Z Teardown This actually occurs at two (or more) levels: Entire test suite Certain files, constants, database commands, etc. need to be run before the entire test suite. Often there is no 'tear-down' in this area. Each test Each test should also have ...


2

Maybe setting up a VM of your environment is a solution you can look into. So as part of running your tests, you spin up a VM (which has everything where it should be) then run your suite of tests within it.


2

I prefer to use separate tools for deployment/configuration and running tests, because a tool that focuses on one thing will do better than a tool that tries to do everything. There are innumerable tools for automating deployments, where a deployment includes installing binaries and configuration files. Some popular ones include Puppet and Ansible. For ...


2

Test environment will NOT scale proportionally. But what you can do is: make test environment as similar to PROD as you possibly can (with possibly less servers, that's what we do: have about half of the servers in PROD) replicate most of the complexity you can (fallback servers as in PROD) replicate the load from PROD in a reasonable way (we collect ...


2

Ideally the best thing is to have UAT or Staging environment which would be exact replica of the production to test your changes there If your application has "dead" time i.e. in the night or during weekends it should be possible to test it on production environment during that period. Load testing on scaled down environments is the "last resort". You'll ...


1

The 'case' for access is doing your job. If your job responsibilities aren't documented that that's the first thing you need to do - sit down with your management and agree on the job responsibilities. They you can talk about what you will need to do in order to do your job. one example: access the QA server to test x. However we can't really answer this ...


1

What do you look for in a staging environment as a QA professional[?] If at all possible your 'staging' environment will be analogous to your Production environments. The web server would be hosted by the same provider and using the same Apache or IIS version. The SQL server would be the same too. You might request a nightly replication so you have ...



Only top voted, non community-wiki answers of a minimum length are eligible