Pourquoi les QA devraient-ils avoir leur propre environnement QA? Quels sont les avantages et inconvénients?

Vous configurez généralement un environnement QA distinct, car vous souhaitez donner aux testeurs un environnement isolé sur lequel tester, de sorte que les développeurs et les testeurs puissent fonctionner en même temps.

L'environnement DEV est typiquement volatil, ce qui rend très difficile l'assurance que l'AQ soit très difficile à obtenir tout un cycle de test, en particulier les tests de régression. Si le service QA tente d'exécuter un test de régression complet sur un système qui change constamment, il leur serait impossible d'indiquer de manière fiable que toutes les fonctionnalités sont «fonctionnent» à un moment donné.

Quelques réflexions viennent à l'esprit:

1. Si QA utilise un environnement de développement, cet environnement change probablement. Il est difficile de contrôler l'état de l'environnement avec plusieurs personnes qui travaillent contre elle.
2. En règle générale, les environnements QA imitent plus de près les environnements de production que les environnements de développement. Cela aide à garantir que la fonctionnalité est valable dans un environnement davantage de production.
3. Les développeurs ont tendance à avoir beaucoup d'outils et de choses à exécuter dans leur environnement qui pourraient affecter la validation de la qualité de la qualité.

Dev est où les développeurs apportent leur code ensemble. Il est probable que Dev est dans un état de flux constant. ATTENDU QUE QA devrait être légèrement plus stable. De cette façon, QA est moins susceptible de rencontrer un code qui n'est pas prêt et que les développeurs peuvent apporter leur code ensemble pour tester avant que la qualité ait la main dessus.

Pour nous, nous faisons des rejets programmés dans l'environnement "QA" pendant que nous continuons à développer dans notre environnement de développement. De cette façon, nous ne sommes pas de chevauchement et ils simulent un environnement utilisateur réel.

Outre les autres choses déjà mentionnées dans ce thead, un aspect très important est que vous pouvez Testez le déploiement du code en ayant un environnement de test distinct. Par exemple, s'il existe une modification de configuration importante (telle qu'une mise à jour de la bibliothèque système requise ou une nouvelle table de base de données), vous devez le tester avant de déplacer le code dans l'environnement de production.

Mon déploiement du code de Dev à tester, vous pouvez tester automatiquement si toutes les modifications de dépendances / de configuration sont prises en charge. Il est important de garder l'environnement de test aussi proche que possible de l'environnement de production.

Le point de QA entier est de vous assurer que le produit final répond aux exigences du client et que l'appareil est suffisamment stable pour se déployer.

Maintenant, si Dev et QA partageent le même environnement, alors comment QA pourrait assurer que l'application est stable? Test d'assurance qualité 5 cas de test et ils obtiennent passés , maintenant un développeur met à jour le code et il a un impact sur les fonctionnalités sous-jacentes testées par ces 5 cas de test . Maintenant, lorsque le code va en production. 5 défauts rencontré contre ces 5 cas de test transmis. Ce n'est qu'un exemple, il y en a beaucoup. Je peux écrire une page entière :).

Par conséquent, vous pouvez uniquement tester une application lorsqu'il n'y a aucun changement de code n'est effectué pendant un moment (c'est-à-dire QA que vous pouvez tester permet de dire 200 cas de test pendant le temps entre différentes constructions). Ils peuvent découvrir quelle zone se bloque et critique, etc. Le cas échéant, certains scripts de base de données ont été manqués dans la construction, car certains devaient l'oublier de faire une partie de la construction :)