Utilize um ambiente de testes local
Se você é um testador trabalhando com automação de testes, há chances de você ter a base de código da aplicação rodando localmente em seu computador.
É mais fácil sair usando esse código que já está rodando em seu ambiente local para conduzir seus testes de histórias. Os benefícios são que que ele sempre estará atualizado, pois assim que um desenvolvedor envia uma mudança, você pode pegar todas as alterações e então estará trabalhando com uma cópia “fresca” da aplicação.
Como parte dos seus testes, você pode mudar o que desejar, tais como configurações da aplicação e banco de dados, para ver o que acontece, sem ter que se preocupar em impactar o ambiente de testes que outros estejam usando.
Você pode até mesmo corrigir os bugs assim que eles aparecem (se essa for sua escolha).
Isso reduz a sobrecarga de se ter múltiplos ambientes para testes de histórias, já que ambientes de testes devem ser configurados e gerenciados.
Utilize um ambiente de testes integrado
Você deveria sempre testar suas histórias de usuário em um ambiente de testes integrado: ou seja, um ambiente que é gerenciado centralmente e integrado com outos sistemas.
Uma razão é que quando você está testando; você não está testando somente sua aplicação, mas que sua aplicação pode ser implantada e pode funcionar em um ambiente dedicado. Isso significa que você irá encontrar problemas que não apareceriam localmente – tal como esquecer de incluir um arquivo para ser implantado, que não irá aparecer ao testar localmente.
Você também testa que você pode acessar sua aplicação através da rede usando um endereço de IP externo, em vez de usar o localhost, e resolver eventuais problemas de conectividade.
Você também estará testando como sua aplicação desempenha sob um hardware mais realista do que simplesmente a máquina de desenvolvimento.
É relativamente fácil configurar um pipeline automatizado de entrega contínua para implantar automaticamente para um ambiente de testes, então, você pode rodar seus testes de histórias assim que elas são completadas pelos programadores.
TALKING ABOUT TESTING 
Meu voto vai para ambos 🙂
Ter um ambiente de testes local, igualzim ao que existe no servidor, é, além de libertador, questão de sobrevivência. Vc se vê responsável pela manutenção desse ambiente (e começa a entender o que acontece debaixo dos panos, como, por exemplo, o build da aplicação é feito), não precisa perguntar “posso reiniciar o DB ou alguem tá usando?” toda vez que rodar um teste, pode pedir para um Dev corrigir os bugs mais críticos e menos dispendiosos (“ah, é só alterar aquela linha do arquivo.gigante.js”) diretamente na sua máquina, etc
Porém, um projeto tem que seguir um caminho único, e um ambiente integrado é obrigação gerencial. Concordo com o Alister/Walmyr sobre também testar lá. Se você fez testes automatizados, esse re-teste vem de graça até!