Comment nous testons les logiciels: Services commerciaux Telerik

Vous êtes-vous demandé comment les équipes travaillant sur le logiciel de test des produits Telerik? Dans le chapitre suivant de notre guide détaillé, nous vous donnons un aperçu plus détaillé des processus de nos services aux entreprises. Vous pouvez trouver les chapitres précédents ici .

Une introduction

Vous lisez le quatrième billet d’une série destinée à vous donner un aperçu des coulisses de l’équipe Telerik, qui sont investis dans les pratiques de développement Agile, DevOps, TDD et veillent à la qualité des produits.

Nous partagerons nos idées sur les pratiques et les outils utilisés par nos équipes de développement de produits et de présence sur le Web pour confirmer que nous livrons des logiciels de haute qualité. Nous allons entrer dans les détails pour que vous puissiez apprendre non seulement les détails techniques de ce que nous faisons, mais également pourquoi nous les faisons. Cela vous donnera les outils nécessaires pour devenir des experts en tests.

Remarque importante: une fois terminée, cette série sera rassemblée, mise à jour / perfectionnée et publiée sous forme de livre électronique. Intéressé? Enregistrez-vous pour recevoir le livre électronique en nous envoyant un courrier électronique à l'adresse telerik.testing@telerik.com.

Inscrivez-vous pour l'eBook maintenant

Chapitre trois: Les services d'entreprise Telerik: préserver le succès de l'entreprise 24 / 7

L'équipe Web est le portier de toutes les applications critiques. Ils sont responsables des applications liées à la facturation, à l'authentification, à l'interface utilisateur, à l'administration Web et au panier. La défaillance de l'un de ces systèmes peut nous coûter cher. Les applications pour lesquelles Business Services est responsable couvrent l’ensemble de Progress et comprennent:

1. www.telerik.com
       
2. www.sitefinity.com
3. Tous les produits Telerik et leurs licences, versions, mises à jour
4. Services d'installation du produit.
       
5. Application de compte client Telerik
6. Toute la section d’aide client de Telerik (système de ticket, forums, site de documentation)
7. Système CRM personnalisé Telerik

Approche de test

Les QA de Business Services commencent à participer à la tester les processus de développement le plus tôt possible, en prenant part à toutes les réunions sur les exigences importantes. Le temps est ménagé pour affiner et retravailler les documents relatifs aux exigences et dissiper les malentendus. Après avoir affiné les exigences, l'équipe fournit des estimations pour les calendriers de développement et de test, en fournissant un énoncé écrit de la portée du projet.

Le système de contrôle de source principal du code d'équipe est Microsoft Team Foundation Server (TFS). Pour la qualité du code de production et des tests, nous utilisons un analyseur statique appelé «Style Cop». Les enregistrements ne sont autorisés que lorsque tous les avertissements sont résolus.

Le niveau de défense suivant est l'examen par les pairs ou le code guide; pour les faire respecter, chaque membre de l'équipe dispose de règles d'enregistrement TFS spécifiques installées.

Après cela, les versions de CI récupèrent le code source à partir du contrôle de version, mettant à jour les versions des fichiers binaires, compilant le code, exécutant des tests et produisant le résultat binaires dans un dossier. Les builds CI sont des définitions de build TFS avec un déclencheur "Rolling Builds" sans restrictions supplémentaires, car ils sont indépendants de toute autre partie du processus d'automatisation de la publication. En tant que tels, ils sont conçus pour pouvoir s'exécuter aussi souvent que possible, dans la mesure où des modifications de code justifient le démarrage d'une génération, ainsi que des agents de génération et de test disponibles.

Chacun des travaux de création de package (CP). prend en charge la sortie de la génération pour une application donnée, crée un package de déploiement pour cette application et le déploie dans l'environnement dès sa première étape. Chacune des tâches exécute un script avec des paramètres prédéfinis. Le script est un fichier de commandes qui traite le contenu d'un dossier spécifié et utilise l'outil de ligne de commande d'AppDirector pour créer des packages de déploiement pour chaque sous-dossier. Le travail interroge le contenu d'un dossier prédéfini (toutes les 30 minutes) et s'exécute.

Pour le déploiement d'applications, nous utilisons un outil interne appelé AppDirector. AppDirector gère les pipelines de déploiement pour plusieurs applications et couvrant plusieurs environnements. Après le déploiement d'un package, AppDirector déclenche une génération Jenkins spécifiée responsable du verrouillage de l'environnement (aucun autre déploiement n'est autorisé jusqu'au déverrouillage) et exécute tous les tests E2E / System / UI. Si les tests échouent, la promotion dans les environnements suivants n'est pas autorisée.

Les environnements de test

Continuous Delivery vous permettent de maintenir votre application dans un état où elle est toujours prête à être déployée en production. Voici un exemple de pipeline de livraison continue:

Environnement d'intégration continue

Ici, tous les éléments de l'application sont réunis dans une instance en cours d'exécution. L'ensemble des tests unitaires est régulièrement exécuté à chaque enregistrement. Si les tests échouent, la construction est ignorée, sinon elle est automatiquement promue en Test système. environnement.

System Testing Environment

Ici, tous les tests d'intégration sont exécutés. Si les tests échouent, la construction est ignorée. Si tous les tests réussissent, la construction est automatiquement promue en test d'intégration des systèmes.

System Integration Environment

Au cours des tests d'intégration des systèmes, les agents d'assurance qualité effectuent des tests exploratoires en exécutant tous les tests automatisés et suites de tests de l'interface utilisateur. Les versions réussies seront ensuite transférées dans l'environnement de test d'acceptation des utilisateurs.

Environs d'acceptation des utilisateurs nt

Dans cet environnement de test, les gestionnaires d'utilisateurs de projet valident les user stories afin de déterminer s'ils répondent ou non à leurs critères d'acceptation. Les tests / critères d'acceptation sont généralement définis par les clients ou les analystes, mais sont consignés dans le récit par le responsable de l'équipe SCRUM responsable et validés par les gestionnaires de projet. Il s'agit de tests de haut niveau destinés à vérifier l'exhaustivité d'une ou plusieurs histoires d'utilisateur «jouées» au cours d'un sprint ou d'une itération.

Idéalement, ces tests sont créés par une collaboration entre clients commerciaux, analystes commerciaux, testeurs et développeurs, et doivent inclure à la fois des tests de logique métier et des éléments de validation de l'interface utilisateur. Les clients professionnels, ou propriétaires de produits, sont les principaux acteurs du projet. au fur et à mesure que les histoires d'utilisateurs répondent à leurs critères d'acceptation, les propriétaires d'entreprise savent que les développeurs progressent dans la bonne direction. L'application passe ensuite manuellement à l'environnement de production et le processus de téléchargement du package est déclenché par les gestionnaires de publication. Nous effectuons environ 10 constructions par jour.

Environnement de production

Une fois que l'application est approuvée, l'application devient alors active. Une nouvelle mise à jour est effectuée une fois par semaine.

Gestion des cas de test

Pour la gestion des cas de test, Business Services utilise Microsoft Test Manager. Tous les cas de test sont stockés sous forme d'éléments TFS. La plupart du temps, nous n’utilisons pas directement Microsoft Test Manager; les scénarios de test sont plutôt écrits / lus via Test Case Manager une application qui étend MS Test Manager. L'outil accélère l'écriture et la maintenance des cas de test. Au cours des 18 derniers mois, nous avons créé plus de 4 700 scénarios de test avec plus de 1 200 étapes partagées.

Cas de test générés par des essais, par exemple Cas de tests dynamiques: