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:

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.

TestCase.AddTestCase ("Démarrage de la plate-forme Telerik> Acheter la plate-forme Telerik");

XmlBillingInfo billingInfo = xmlInvoice.BillingInfo; [1945907]

TestCase.AddActionStep ("Type Nom de facturation = {0}", billingInfo.FirstName);

billingInfoMap.BillingFirst = billingInfo.

TestCase.AddActionStep ("Type Nom de facturation = {0}", billingInfo.LastName);

de . billingInfoMap.BillingLastName = billingInfo.LastName;

TestCase.AddActionStep ("Type Email de facturation = {0}", billingInfo.Email); [1945910].

billingInfoMap.BillingEmail = billingInfo.Email;

TestCase.AddActionStep ("Type Billing Company = {0}", billingInfo .CompanyName);

billingInfoCarte.BillingCompany = billingInfo.CompanyName;

TestCase.AddActionStep ("Type de texte) = {0} ", billingInfo.Phone);

billingInfoMap.BillingPhone = billingInfo.Phone;

de test .AddActionStep ("Type Billing Address = {0}", billingInfo.Address);

billingInfoMap.BillingAddress = billingInfo.Address;

Source link