Conformité logicielle DO-178C pour l'aérospatiale et la défense

La norme DO-178C du Comité technique radio pour l'aéronautique (RTCA) est une norme de sécurité fonctionnelle qui fournit des conseils et des considérations pour la production de logiciels destinés aux systèmes et équipements embarqués. L'objectif est de garantir que le système remplit sa fonction prévue avec un niveau de confiance en matière de sécurité conforme aux exigences de navigabilité. Si un aéronef doit survoler l'espace aérien commercial américain, le respect de la norme est obligatoire.

DO-178C fournit les orientations suivantes :

• Objectifs des processus du cycle de vie du logiciel
• Activités qui fournissent un moyen de satisfaire ces objectifs
• Descriptions des preuves sous forme de données sur le cycle de vie du logiciel qui indiquent que les objectifs ont été atteints
• Variations des objectifs, de l'indépendance, des données sur le cycle de vie du logiciel et des catégories de contrôle par niveau de logiciel
• Considérations supplémentaires (par exemple, logiciels développés précédemment) applicables à certaines applications
• Définition des termes fournis dans le glossaire

La norme DO-178C couvre l'intégralité du cycle de vie de l'ingénierie : planification, développement, vérification, assurance qualité, liaison et certification. Elle est subdivisée en 12 sections. La section 1, non illustrée, énonce l'objectif, la portée et les modalités d'utilisation du document.

La RTCA a été fondée en 1935. Il s'agit d'une organisation indépendante de développement de normes qui sert de base à la certification gouvernementale des équipements utilisés par les dizaines de milliers d'avions volant quotidiennement dans l'espace aérien mondial.

La RTCA est une société privée à but non lucratif qui travaille en étroite collaboration avec la Federal Aviation Administration (FAA) et des experts du secteur des États-Unis et du monde entier, tels que le groupe de travail de l'Organisation européenne pour l'équipement de l'aviation civile (EUROCAE), pour contribuer à l'élaboration de cette norme aéronautique complète et contemporaine. L'EUROCAE est une organisation à but non lucratif dont l'objectif est d'élaborer des normes pour l'aviation civile européenne.

La norme DO-178 originale a été publiée en 1982. Cependant, elle n'a pas été jugée utile. Par conséquent, la révision DO-178A a suivi, publiée en 1985. Cette révision se concentrait davantage sur les principes modernes d'ingénierie logicielle et les pratiques de vérification. Elle a introduit une corrélation entre les conditions de défaillance critique avec les numéros de niveau 1, 2 et 3. Le niveau 1, que vous connaissez peut-être mieux sous le nom de niveau d'assurance de développement (DAL), était le plus strict.

En décembre 1992, révision DO-178B a été publié, qui est passé d'un document de type « comment faire » à un document de type « quoi faire ». Une grande attention a été portée aux objectifs que votre processus logiciel doit satisfaire pour atteindre la conformité et, à terme, la certification.

Un autre changement notable a été le nombre de conditions de défaillance critiques possibles définies dans DAL. Elles ont été augmentées à cinq niveaux logiciels et sont passées de chiffres à lettres de A à E. Le niveau A était le plus strict et le niveau E signifiait qu'il n'y avait aucune exigence de sécurité. De plus, il était fortement recommandé de tester vos exigences. Il était conseillé de ne pas consulter le code pour créer des cas de test, mais de consulter vos exigences. Il était soutenu par une couverture de code structurelle pour garantir que vous avez tout couvert.

La norme DO-178B intègre également la traçabilité bidirectionnelle entre les systèmes, les exigences de haut et de bas niveau, y compris les cas de test, et jusqu'au code pour montrer que toutes les exigences ont été mises en œuvre. L'idée de disposer d'outils qualifiés pour l'utilisation a été introduite.

Aujourd'hui, nous en sommes à la révision C. Publiée en janvier 2012, la norme DO-178C a supprimé les formulations imprécises de la norme DO-178B pour plus de clarté. Elle est également le fruit d'un effort conjoint entre la RTCA et l'EUROCAE. Mais la principale différence entre la norme DO-178B et la norme DO-178C est l'adoption d'une approche modulaire des documents d'orientation supplémentaires. Vous disposez désormais de normes supplémentaires, notamment les suivantes.

Ce guide fournit un aperçu condensé de chacune des sections de la norme DO-178C, en soulignant les principaux points à retenir.

Aspects du système liés au développement de logiciels, section 2

La section 2 aborde les processus du cycle de vie du système, les artefacts produits, la manière dont ils s'intègrent dans le cycle de vie du logiciel et le flux d'informations entre ces processus. Une grande partie de ce travail est consacrée à l'analyse des exigences, où les exigences du système logiciel sont initialement élaborées à partir des exigences opérationnelles du système ou des exigences du client, et à la manière dont ces artefacts s'intègrent dans le cycle de vie du logiciel.

Dans le cycle de vie du logiciel, la décomposition des exigences se poursuit, la vérification du logiciel a lieu et, finalement, la certification.

Bien que la norme DO-178C capture le flux entre les cycles de vie du système et du logiciel dans le diagramme ci-dessus, le sujet est bien défini dans le Norme SAE ARP4754ALignes directrices pour le développement des aéronefs et des systèmes civils.

La section 2 aborde les sujets suivants :

• Attribution des exigences système aux logiciels
• Flux d'informations entre les processus du cycle de vie du système et du logiciel et entre les processus du cycle de vie du logiciel et du matériel
• Processus d'évaluation de la sécurité du système, conditions de défaillance, définitions des niveaux de logiciel et détermination du niveau de logiciel » Considérations architecturales
• Considérations architecturales
• Considérations logicielles dans les processus du cycle de vie du système
• Considérations systémiques dans les processus du cycle de vie des logiciels

Une autre partie importante de la section 2 consiste à déterminer le niveau de classification du logiciel ou DAL. Les résultats catastrophiques correspondent à une défaillance du logiciel de contrôle de vol, entraînant la chute d'un avion et la perte de nombreuses vies humaines. Ce niveau de logiciel serait classé comme A.

Le niveau dangereux est un niveau inférieur, donc des blessures graves ou mortelles à un nombre relativement faible d'occupants autres que l'équipage de conduite correspondraient au niveau logiciel B. La classification continue de descendre jusqu'au niveau logiciel E, où il n'y a aucun problème de sécurité en cas de panne.

Une autre perspective ou un autre aspect de cette classification est l'assurance qualité. À chaque augmentation du niveau E au niveau A, le nombre d'objectifs à atteindre augmente. Par exemple, la traçabilité entre les artefacts produits au cours du développement du produit augmente. De plus, les tests logiciels augmentent. Le logiciel peut avoir besoin de satisfaire à la couverture du code d'assemblage ou du code objet au lieu de simplement couvrir les instructions, les branches et les MC/DC.

Pour partager une bonne pratique, si votre logiciel est classé au niveau B ou inférieur, vous pouvez essayer d'atteindre certains ou tous les objectifs du niveau logiciel supérieur suivant. L'effort supplémentaire entre certains niveaux d'assurance de développement peut ne pas être trop important et les avantages pourraient très bien s'avérer payants si les exigences des clients deviennent plus strictes.

Vous trouverez ci-dessous le célèbre modèle en V. Le côté droit capture les phases de conception du système et du logiciel tandis que le côté gauche capture les phases de vérification. La norme ARP4754 est votre document de référence sur le développement de systèmes d'aéronefs en tenant compte de l'environnement opérationnel et des fonctions globales de l'aéronef. Cela comprend la validation des exigences et la vérification de la mise en œuvre de la conception pour la certification et l'assurance produit.

Cycle de vie du logiciel, section 3

La section 3 aborde les différents aspects du processus du cycle de vie du logiciel. La séquence bien connue du cycle de vie du logiciel est la gestion des exigences, la conception, le codage et l'intégration. La norme DO-178C ne recommande pas l'utilisation d'un processus de développement. Il appartient aux organisations de prendre cette décision en fonction de leur propre expérience et de facteurs tels que la technologie actuelle, comme Agile, DevSecOps, CI/CD ou les exigences des clients. Quel que soit le processus choisi, les objectifs de la norme qui doivent être atteints ne sont pas entravés par le processus.

Les processus du cycle de vie du logiciel DO-178C comprennent les éléments suivants :

• Processus de planification du logiciel. Définit et coordonne les activités de développement du logiciel et les processus intégraux d'un projet.
• Processus de développement logiciel. Produire le produit logiciel. Ce processus comprend les processus d'exigences, de conception, de codage et d'intégration.
• Processus logiciels intégraux. Assurer l'exactitude, le contrôle et la fiabilité des processus du cycle de vie du logiciel et de leurs résultats. Ceux-ci comprennent la vérification, la gestion de la configuration, l'assurance qualité et la liaison de certification.

Processus de planification du logiciel, section 4

La section 4 décrit les objectifs et les activités du processus de planification du logiciel. Les objectifs sont clairement définis et consignés dans le tableau A-1 de la norme. Sept objectifs doivent être satisfaits en fonction du niveau du logiciel (AD). Ces objectifs incluent la définition des éléments suivants :

• Processus du cycle de vie du logiciel
• Interrelations entre les processus
• Méthodes et outils à utiliser
• Normes de développement à utiliser pour garantir la sécurité
• Vérification que le logiciel répond aux exigences de développement
• Vérification que les organisations qui réaliseront ces activités

Le processus de planification du logiciel doit également tenir compte de nombreuses considérations, comme l’intention d’utiliser un logiciel déjà développé ou un logiciel commercial prêt à l’emploi (COTS), la qualification des outils et bien d’autres encore décrites dans la section 12.

Le tableau A-1 de la norme résume les objectifs, les niveaux de logiciels qui s'appliquent et les résultats attendus de ces activités, qui sont un ensemble de documents contenant des informations sur l'organisation, la norme industrielle, le développement de logiciels, les outils, les résultats de vérification et la certification.

Processus de développement logiciel, section 5

Le processus de développement logiciel est appliqué tel que défini par le processus de planification du logiciel et le plan de développement logiciel. Que les équipes ou les organisations choisissent une méthodologie de développement logiciel comme DevOps, Spiral, Waterfall ou autre, les quatre processus répertoriés ci-dessous doivent être exécutés.

1. Processus d'exigences logicielles
2. Processus de conception de logiciels
3. Processus de codage du logiciel
4. Processus d'intégration

Le processus de définition des exigences logicielles commence par la collecte de toutes les exigences des parties prenantes, des organismes de réglementation, des normes, etc. Ces exigences sont organisées en domaines tels que le matériel, les logiciels, la mécanique, la chimie, l'électricité, etc., et deviennent ensuite vos exigences au niveau du système.

Les exigences de haut niveau sont dérivées des exigences système de niveau supérieur. Elles décomposent une exigence système en diverses exigences fonctionnelles et non fonctionnelles de haut niveau. Cette phase de décomposition des exigences aide à la conception architecturale du système en cours de développement.

Les exigences de haut niveau clarifient et aident à définir le comportement attendu ainsi que les tolérances de sécurité, les attentes en matière de sécurité, la fiabilité, les performances, la portabilité, la disponibilité, l'évolutivité, etc. Chaque exigence de haut niveau est liée à l'exigence système qu'elle satisfait. De plus, des cas de test de haut niveau sont créés et liés à chaque exigence de haut niveau à des fins de vérification et de validation. Cela fait partie du processus de conception du logiciel, car chaque exigence de haut niveau est ensuite décomposée en exigences de bas niveau.

Les exigences de bas niveau sont des exigences logicielles dérivées des exigences de haut niveau. Elles décomposent et affinent davantage les spécifications du comportement et de la qualité de service du logiciel. Elles descendent jusqu'à un autre niveau d'abstraction et le mettent en correspondance avec des unités logicielles individuelles. Le processus de codage commence par l'écriture d'unités de code pour faciliter la conception et la mise en œuvre détaillées du logiciel. Les entrées du processus de codage sont les exigences de bas niveau et l'architecture logicielle issues du processus de conception du logiciel, du plan de développement du logiciel et des normes de code du logiciel.

Une fois le processus de codage terminé, le processus d'intégration comprend les éléments suivants :

Les défauts de codage doivent être identifiés et corrigés. Les entrées inadéquates ou incorrectes détectées au cours du processus d'intégration doivent être transmises aux processus logiciels suivants en guise de retour d'information pour clarification ou correction :

• Exigences
• Design
• Codage
• Préproduction

La traçabilité bidirectionnelle établie à partir de chaque exigence de bas niveau jusqu'à son exigence de haut niveau et jusqu'aux tests de bas niveau ou aux cas de tests unitaires qui la vérifient et la valident aide dans cette entreprise.

Niveau d

La traçabilité est essentielle pour la norme DO-178C. La profondeur de la traçabilité varie en fonction du niveau du logiciel. En ce qui concerne la traçabilité requise pour le niveau D de la norme DO-178C, les organisations n'ont pas besoin de se soucier de la manière dont le logiciel a été développé et, par conséquent, il n'est pas nécessaire d'avoir une traçabilité jusqu'aux exigences de bas niveau, au code source ou à l'architecture logicielle. Les équipes doivent simplement retracer les exigences du logiciel système jusqu'aux exigences de haut niveau, puis jusqu'aux cas de test, aux procédures de test et aux résultats de test.

Niveau C et B

Pour les niveaux B et C, la manière dont le code source a été développé devient importante. Les équipes doivent étendre la traçabilité en ajoutant des liens bidirectionnels entre les exigences de haut niveau et les exigences de bas niveau, puis vers le code source.

Niveau A

Pour les projets de niveau A, les exigences sont d'étendre la traçabilité non seulement jusqu'au code source, mais aussi jusqu'au code assembleur/objet. En effet, les compilateurs sont connus pour étendre et traduire les langages de niveau supérieur en code assembleur qui ne renvoie pas au code d'origine.

Parasoft dispose d'une solution de couverture de code assembleur appelée ASMTools qui automatise la couverture de code au niveau du langage assembleur. L'automatisation de cet effort allège considérablement la charge de travail si une couverture de code au niveau de l'assembleur est requise.

Pour la traçabilité des exigences, Parasoft automatise la liaison entre les exigences, les cas de test et jusqu'au fichier source, si nécessaire. Des intégrations avec des outils ALM tels que Jama, Codebeamer et Polarion existent pour aider à atteindre cette traçabilité bidirectionnelle et à créer une matrice de traçabilité pour les exigences de vérification.

Processus de vérification du logiciel, section 6

Le processus de vérification du logiciel a pour objectif de détecter, signaler et supprimer les erreurs qui ont pu être introduites au cours du processus de développement du logiciel. La norme utilise le terme « vérification » au lieu de « test » car les tests seuls ne peuvent pas démontrer l'absence d'erreurs. La vérification est une combinaison d'examens, d'analyses, de cas de test et de procédures de test.

Les tests assurent la cohérence interne et l’exhaustivité des exigences, tandis que les exécutions de tests fournissent une démonstration de la conformité aux exigences.

Processus de vérification du logiciel DO-178C permet les actions suivantes :

• Les exigences système allouées au logiciel doivent être décomposées en exigences de haut niveau qui satisfont aux exigences système.
• Les exigences de haut niveau doivent être développées en architecture logicielle et les exigences de bas niveau doivent satisfaire aux exigences de haut niveau.
• Si un ou plusieurs niveaux d'exigences logicielles sont décomposés en exigences de haut niveau et de bas niveau, chaque niveau de niveau inférieur satisfait ses exigences de niveau supérieur. Si le code est généré directement à partir d'exigences de haut niveau, cela ne s'applique pas.
• L'architecture logicielle et les exigences de bas niveau doivent être développées en code source qui satisfait les exigences de bas niveau et l'architecture logicielle.
• Le code objet exécutable doit satisfaire aux exigences du logiciel et garantir la fonctionnalité prévue.
• Le code objet exécutable doit être robuste et répondre correctement aux entrées et conditions anormales.
  Les moyens utilisés pour effectuer la vérification doivent être techniquement corrects et complets pour chaque niveau de logiciel déterminé.
• Les moyens utilisés pour effectuer la vérification doivent être techniquement corrects et complets pour chaque niveau de logiciel déterminé.

Les tests logiciels démontrent ou « valident » que le logiciel répond à ses exigences et révèlent avec un degré de confiance élevé que les erreurs qui pourraient conduire à des conditions de défaillance inacceptables, telles que déterminées par le processus d'évaluation de la sécurité et de la sûreté du système, ont été supprimées. Le diagramme suivant présente les activités de test logiciel avec des sous-sections.

Pour détailler plus en détail chaque activité de test, la norme fournit un ensemble de tableaux avec des objectifs bien définis et des résultats ou des artefacts nécessaires pour démontrer la conformité. Ces objectifs sont atteints au moyen de tests logiciels et peuvent inclure les éléments suivants :

• Réalisation d'une analyse statique
• Tests unitaires
• Test d'intégration
• Test du système
• Matériel sur la cible
• Couplage des données et du contrôle
• Couverture du code structurel (déclaration, branche, MC/DC, assemblage)

L’intégration du matériel et des logiciels est essentielle pour garantir la sécurité et la fiabilité.

Sachez que toutes ces méthodes de test sont automatisées par la suite d'outils de Parasoft. Vous pouvez avoir un aperçu de notre solution C/C++ en prenant un visite du test Parasoft C/C++.

Les tableaux suivants répertorient l’ensemble des objectifs et des résultats attendus en fonction de chaque niveau d’assurance de conception de logiciel afin de garantir la navigabilité.

Processus de gestion de la configuration logicielle, section 7

La section 7 décrit les objectifs et les activités du processus de gestion de la configuration logicielle. Vous devez être en mesure de définir et de contrôler les configurations du logiciel tout au long de son cycle de vie. Les organisations ou les équipes doivent disposer de bases de référence source, de gestion des versions, de contrôle des modifications, de révision des modifications, de protection contre les modifications non autorisées, de rapports de problèmes et bien plus encore.

Voici les activités du processus de gestion de la configuration logicielle :

1. Identification de la configuration
2. Bases de référence et traçabilité
3. Signalement des problèmes, suivi et mesures correctives
4. Le contrôle des changements
5. Modification de l'avis
6. Comptabilité de l'état de configuration
7. Archivage, récupération et diffusion

Ces activités sont ensuite détaillées sous forme d'objectifs et de résultats. Les objectifs incluent la capacité à contrôler les changements de caractéristiques des articles, à enregistrer et à signaler le traitement du contrôle des changements et à assurer l'état de la mise en œuvre.

Dans le tableau A-8, notez la colonne « Catégorie de contrôle par niveau de logiciel ». La norme DO-178C spécifie les éléments qui doivent être traités comme catégorie de contrôle 1 ou 2 en fonction de la DAL du projet. Les éléments traités comme catégorie de contrôle 1 (CC1) doivent être soumis à des processus complets de signalement des problèmes, à un examen formel des modifications et à des processus de publication. Les éléments CC2 n'ont pas besoin de subir ces processus plus formels, mais ils doivent toujours être conformes aux besoins d'identification et de traçabilité de la configuration, être protégés contre les modifications non autorisées et satisfaire aux exigences de conservation des données applicables. La correspondance entre les données CC1 et CC2 se trouve dans le tableau suivant.

Processus d'assurance qualité des logiciels, section 8

Le processus SQA est intégré dans le plan d'assurance qualité du logiciel, qui est élaboré au cours du processus de planification du logiciel. Les résultats des activités du processus SQA doivent être enregistrés, évalués et suivis. Des audits doivent être effectués et tout écart par rapport aux normes doit être résolu. Le processus implique de fournir l'assurance que :

• Les plans et normes logiciels sont développés, révisés et seront conformes.
• Les artefacts, les rapports et les preuves sont en place avec les approbations.
• Les données sur les produits logiciels et le cycle de vie des logiciels sont conformes aux exigences de certification.

Processus de liaison pour la certification, section 9

La section 9 traite du processus de liaison de certification et de ses objectifs, qui comprennent les éléments suivants :

• Établir une communication et une compréhension entre le demandeur et l’autorité de certification tout au long du cycle de vie du logiciel pour faciliter le processus de certification.
• Obtenir un accord sur les moyens de conformité grâce à l’approbation du Plan pour les aspects logiciels de la certification.
• Fournir une justification de conformité.

Votre organisation devra produire le Plan des aspects logiciels de la certification (PSAC), qui contiendra le processus de liaison de certification. Le PSAC comprendra des plans pour résoudre les problèmes identifiés par l'agent de liaison de certification et obtenir un accord sur le plan. Le tableau ci-dessous répertorie l'ensemble des objectifs et des artefacts de sortie attendus.

Les meilleures pratiques pour obtenir une certification se résument à une étroite collaboration avec votre agent de liaison en matière de certification, mieux connu sous le nom de votre représentant technique désigné (DER), pour évaluer la conformité, agir en votre nom en vue de l'approbation et recommander à la FAA d'approuver votre certification.

Aperçu du processus de certification, section 10

La section 10 est fournie à titre informatif uniquement concernant le processus de certification.

Elle mentionne les types de systèmes et d'équipements auxquels s'applique la certification. Elle précise que les autorités de certification ne certifient pas un logiciel en tant que produit autonome unique. Il doit faire partie du système ou de l'équipement embarqué.

La « certification » s'applique aux aéronefs, aux moteurs ou aux hélices et, pour certaines autorités de certification, aux groupes auxiliaires de puissance. Les autorités de certification considèrent le logiciel comme faisant partie du système ou de l'équipement embarqué installé sur le produit certifié ; autrement dit, les autorités de certification ne certifient pas le logiciel en tant que produit unique et autonome.

L’approbation dépend également d’une démonstration ou d’un examen réussi des produits fabriqués.

Données sur le cycle de vie du logiciel, section 11

La section 11 traite des artefacts tels que les données et la documentation produites au cours du cycle de vie du logiciel. Les données doivent être sans ambiguïté, complètes, vérifiables, cohérentes, modifiables et traçables. Elles doivent également se présenter sous diverses formes, comme électroniques et imprimées. Le tableau de bord Web de génération de rapports automatisés et d'analyse de Parasoft fournit une grande partie des informations nécessaires dans divers artefacts et documents.

Les artefacts à produire au cours du cycle de vie du logiciel comprennent le code source, le code objet, les cas de test, les résultats, les rapports de problèmes et, bien sûr, les plans. Voici la liste complète.

• Planifier les aspects logiciels de la certification
• Code objet exécutable
• Plan de développement logiciel
• Cas et procédures de vérification de logiciels
• Plan de vérification du logiciel
• Résultats de la vérification du logiciel
• Plan de gestion de la configuration logicielle
• Index de configuration de l'environnement du cycle de vie du logiciel
• Plan d'assurance qualité du logiciel
• Normes d'exigences logicielles
• Index de configuration du logiciel
• Normes de conception de logiciels
• Rapports de problèmes
• Normes de code logiciel
• Enregistrements de gestion de la configuration logicielle
• Données sur les exigences logicielles
• Dossiers d'assurance qualité des logiciels
• Descriptif de conception
• Résumé des réalisations du logiciel
• Répertoire de
• Données de suivi
• Fichier d'éléments de données de paramètres

Considérations supplémentaires, section 12

La section 12 fournit des conseils et des considérations supplémentaires sur des sujets qui peuvent avoir un impact sur les objectifs et les activités du cycle de vie du logiciel. Par exemple, l'utilisation ou les modifications de logiciels précédemment développés. La section 12 fournit des éclaircissements supplémentaires et des activités à effectuer pour garantir la sécurité et la recertification. Voici quelques autres considérations à prendre en compte :

Sur la base de cette réflexion, la section 12 fournit des objectifs supplémentaires en matière de gestion de la configuration logicielle, d’assurance qualité logicielle, de qualification des outils de développement, etc.

La section 12 aborde l’importance de la « qualification des outils » et de la nécessité de déterminer si elle est nécessaire. En effet, si un outil est utilisé pour éliminer, réduire ou automatiser des processus, les équipes doivent prendre en compte le fait que l’outil puisse introduire des erreurs dans le cycle de vie.

Les critères suivants doivent être utilisés pour déterminer l’impact de l’outil :

Il existe cinq niveaux de qualification des outils, de TQL-1 à TQL-5, qui sont déterminés par l'utilisation de l'outil et son impact potentiel sur le cycle de vie du logiciel. TQL-1 est le niveau le plus rigoureux. Le niveau de qualification de l'outil doit être coordonné avec l'autorité de certification.

Les objectifs, activités, conseils et données sur le cycle de vie requis pour chaque niveau de qualification d'outil sont décrits dans la norme DO-330, « Considérations relatives à la qualification des outils logiciels ».

Parasoft prend en charge les processus de qualification d'outils conformes aux normes DO-178C et DO-330 avec un kit de qualification d'outils automatisé. Le kit de qualification d'outils automatise le processus de création de la documentation de support requise pour l'utilisation de tests C/C++ pour l'analyse statique, les tests unitaires et les exigences de couverture.

Kit de qualification d'outils de Parasoft réduit le temps nécessaire à la qualification de l'outil et le risque d'erreur humaine en tirant parti de l'automatisation pour guider les utilisateurs tout au long du flux de travail suivant :

1. Spécifiez les cas d’utilisation et les capacités à utiliser sur le projet.
2. Associez rapidement les problèmes connus dans l’outil que vous qualifiez aux fonctionnalités de l’outil que vous utilisez en développement.
3. Planifiez et capturez les résultats des efforts de tests manuels.
4. Exécuter des tests automatisés.
5. Rassemblez toutes les données et générez les documents critiques.