Les 3 principales raisons d’un environnement QA

Imaginez en tant qu’analyste qualité, vous commencez votre journée de test. Vous vous connectez à Sitecore Content Editor, créez une page, nommez-la et ouvrez-la dans Experience Editor, mais recevez un écran blanc « Nos services ne sont pas disponibles ». Vous enquêtez et voyez un déploiement se produire dans votre environnement, qui est DEV. Tout cela a pris 10 minutes mais se produit tout au long de la journée chaque fois qu’un développeur vérifie le code. Une page qui aurait dû prendre 15 minutes à créer prend maintenant 2 heures à cause de toutes les perturbations et recréations de contenu. Semble horrible; vous pensez peut-être, pourquoi n’y a-t-il pas un environnement séparé pour les tests ? Bien sûr, même aujourd’hui, il y a des cas où les projets peuvent ne pas avoir besoin d’un environnement QA pour de nombreuses raisons, mais je suis ici pour essayer de persuader quiconque pourrait être sur la clôture ou penser que vous n’avez peut-être pas besoin d’un environnement QA pourquoi vous devriez.

Mes 3 principales raisons pour un environnement QA

Bonheur

Chaque équipe a besoin d’outils essentiels pour accomplir son travail; quand ils ne le font pas, cela peut être frustrant et conduire au malheur. Un environnement est un outil nécessaire au développement de logiciels. Les développeurs doivent pouvoir enregistrer et déployer du code sur DEV sans craindre qu’il ne retarde les autres membres de l’équipe. L’intégration du code est essentielle pour maintenir une branche principale saine, donc cela devrait se produire souvent. Si une fusion brise l’environnement, ce n’est pas grave ; c’est à cela que sert cet environnement, n’est-ce pas ? Sauf si vous avez 2 personnes QA attendant d’utiliser l’environnement pour les tests. Le partage des environnements met désormais à rude épreuve les deux parties. Chaque jour, cela peut donner l’impression de déplacer des barrages routiers toute la journée pour accomplir des tâches simples, ce qui peut conduire au malheur. Le fait d’avoir un environnement QA séparé résout tous les problèmes répertoriés. Les développeurs peuvent librement s’enregistrer et déployer du code sur DEV tout au long de la journée. Si le DEV tombe en panne, les développeurs ont le temps d’enquêter, et cela n’affecte pas les responsables de l’assurance qualité car ils ne se trouvent pas dans un environnement partagé. Les responsables de l’assurance qualité peuvent travailler et tester dans un environnement d’assurance qualité fermé et stable, et les tâches simples redeviennent simples.

Temps

Le temps perdu s’additionne. La plupart des gens pensent, qui s’en soucie? Le déploiement d’une build ne dure que quelques minutes et l’environnement ne fait que s’emballer. Tous ces blips s’additionnent. Si le code était archivé toutes les heures pendant 8 heures par jour, en moyenne, cela représente environ 10 minutes d’inutilisabilité par déploiement, ce qui représente 80 minutes par jour. Une heure et 20 minutes par jour sont consacrées à la reconnexion à Sitecore, à l’actualisation des écrans, à la recréation du contenu perdu et au test de nouvelles modifications. Les responsables de l’assurance qualité doivent maintenant surveiller les builds et les déploiements pour voir s’ils peuvent créer des pages entre les déploiements. Les tâches les plus simples dans Sitecore prennent désormais le double de temps. Les développeurs doivent se coordonner pour voir si leur enregistrement perturbera les tests d’assurance qualité. Tout retard dans le code atteignant un environnement testable met les sprints en danger et peut entraîner des retards dans les délais. Les sprints deviennent difficiles à planifier et à terminer lorsque le partage d’environnements peut prendre un temps indéterminé. Les équipes peuvent planifier ces pannes, mais elles ne seront jamais exactes à 100 %. Avoir un environnement QA séparé résout le temps perdu lors des déploiements de code.

De l’argent

Avantage de coût- Prenons le coût du temps perdu d’un petit projet par rapport au coût de l’environnement QA pendant UN AN. Dans ce scénario, une équipe de 7 personnes perd 10 minutes par heure lors des déploiements, ce qui représente 80 minutes par jour et par personne. Dans l’exemple ci-dessous, nous utiliserons des calculs simples pour dire que nous ne perdons que 60 minutes par jour ou 5 heures par semaine ouvrable. (Il s’agit d’une estimation basse). Par conséquent, une équipe de 7 personnes coûte au projet 94 420 $ en salaire avec perte de temps (voir les calculs ci-dessous). Prenons maintenant le coût d’un environnement QA par rapport au coût du travail perdu. Tout d’abord, nous devons déterminer le coût de l’environnement QA. Les environnements Sitecore ont de nombreuses variables qui déterminent le prix, mais nous utiliserons une moyenne de 4 000 $ par mois pour cet exemple, ce qui porte son coût annuel à 48 000 $. Maintenant que nous avons le coût de l’environnement QA ci-dessous, vous pouvez voir que le coût du temps perdu, 94 420 $, est supérieur au coût de l’environnement QA de 48 000 $ pour un an. Rien qu’en disposant d’un environnement QA, cette équipe aurait économisé 46 420 $ (94 420 $ – 48 000 $) en un an. Au fur et à mesure que l’équipe grandit ou si un autre groupe est ajouté, le coût du temps perdu continuera d’augmenter, tandis que le coût de l’environnement restera le même. Le fait d’avoir un environnement d’assurance qualité séparé évite les pertes de temps et permet d’économiser de l’argent pour le projet en frais de personnel.

Conclusion

Comme indiqué ci-dessus, ne pas avoir un environnement QA pensant qu’il pourrait économiser de l’argent fera probablement le contraire en coûtant plus cher à l’équipe en bonheur, temps et argent. Configurez votre projet pour réussir en ayant un environnement QA dès le début.