Les séries spéciales de l'EBSE sont divisées en « cinq » chapitres. Cet article est le « deuxième » chapitre de la série. Dans le « chapitre (1) » précédent, les caractéristiques de l'ingénierie logicielle automobile, le processus de test EBSE par étapes conçu avec des méthodes mixtes et des questions ont été soulevées. Ensuite, nous analyserons spécifiquement l'étape 1 de l'EBSE : analyse de cas sur les forces et les défis.
https://blog.csdn.net/NewCarRen/article/details/130137367?spm=1001.2014.3001.55014. EBSE Étape 1 : Analyse de cas sur les forces et les défis
Nous avons mené une étude de cas industrielle pour étudier les points forts et les défis du processus de test de logiciels automobiles et identifier les possibilités d'amélioration, en répondant aux questions RQ1 et RQ2 de cette série de sujets (1) .
4.1. Types de conception d'études de cas
Case est l'une des bases de développement d'une grande organisation automobile suédoise. L'organisation de cas est certifiée ISO. Cependant, l’organisation a eu du mal à atteindre le niveau de SPICE attendu par ses clients. En particulier, différents départements ont obtenu des résultats différents lors de l'évaluation. Il ressort également de cette étude que nous avons constaté qu'il n'existait pas de processus de test uniforme et que tous les projets ne disposaient pas d'un plan de test approprié. Ils se concentrent sur les produits souples et durs dans les domaines de l'Internet des véhicules, de la logistique, de l'électronique, de la mécanique, de la modélisation par simulation et de l'ingénierie système.
Nous rapportons un cas avec plusieurs unités d'analyse dans lequel nous nous concentrons sur le phénomène de test de plusieurs éléments dans une même entreprise. Ce type d'étude de cas permet de comparer les méthodologies de test, les outils et les méthodes utilisés pour différents projets dans l'organisation de cas.
L’unité d’analyse ici sont les différents projets des entreprises étudiées. Choisissez de manière à ce qu'ils présentent la plus grande variation en termes de facteurs tels que les méthodologies utilisées, la taille de l'équipe et les technologies utilisées pour les tests. Les motivations de projet axées sur le changement peuvent susciter un large éventail de défis et d’avantages. Cela facilite également la généralisation, puisque les défis ne sont pas orientés vers des types de projets spécifiques.
4.2. Objet d'analyse
Tous les projets étudiés cette fois-ci étaient sur mesure puisque l'organisation du cas était un fournisseur d'un client spécifique. Tous les projets ici sont initiés en externe et l'organisation ne vend aucun produit/service exclusif. Les projets au sein d'une organisation sont principalement des projets de maintenance ou d'amélioration de produits existants. Dans cette organisation, il est courant qu'un rôle ait plusieurs responsabilités sur plusieurs projets. Le tableau 1 donne un aperçu des éléments étudiés.
Systèmes : la plupart des systèmes sont des applications intégrées (P1, P2, P3, P4, P7 et P8), c'est-à-dire qu'ils impliquent des composants logiciels et matériels tels que des unités de commande, des systèmes hydrauliques, etc. Les applications Windows développées en P2, P5 et P6 ne contrôlent pas le matériel.
Taille de l'équipe : Nous distinguons les petits projets (équipes de moins de 4 personnes) et les grands projets (équipes de 4 personnes ou plus). La plupart des équipes sont de grande taille, comme le montre le tableau 1. Les petites équipes ne disposent pas nécessairement de processus de développement et de test structurés, de rôles et de responsabilités, de méthodologies ou d'outils de test. Trois projets (P3, P6 et P8) n'ont signalé aucun plan de test. Les projets comportant un grand nombre de modules sont développés par de grandes équipes et sont obsolètes par rapport aux projets gérés par de petites équipes. Cela dit, ces systèmes ont considérablement évolué au fil du temps.
Méthodologies de développement : Différentes méthodologies de développement de logiciels sont adoptées au sein des organisations. Cependant, le développement basé sur un modèle est le plus important (P4, P5, P7 et P8) et est utilisé avec le concept de modèle en cascade. Waterfall fait référence à un processus séquentiel impliquant les exigences, la conception, le développement de composants, l'intégration et les tests. Le développement agile utilisant Scrum a été adopté dans un projet (P2). La petite équipe impliquée dans la maintenance a adopté une approche temporaire (P6). Deux projets ont récemment introduit des pratiques agiles pour intégrer le développement itératif (P1 et P5).
Outils : divers outils sont utilisés dans les projets de test, tels que des scénarios de test et des générateurs de données, des outils d'exécution de tests, des outils de détection et de gestion des défauts, des outils de débogage, des outils de suivi des exigences et de gestion de la configuration, ainsi que des outils de modélisation et d'analyse des unités de contrôle électroniques (ECU). de. En plus de ces outils, des outils personnalisés sont utilisés dans certains projets lorsqu'aucun autre outil ne peut répondre à l'objectif spécifique du projet. Ces outils sont souvent utilisés pour l'exécution de tests afin de rapprocher l'environnement de test de l'environnement cible. Les petites équipes (comme P3) ne s'appuient pas sur des outils de test, mais utilisent des feuilles de calcul. Les grandes équipes responsables de plusieurs modules utilisent plusieurs outils pour organiser et gérer les artefacts de test.
Niveau de test : comme le montre le tableau 1, presque tous les projets (sept sur huit) avaient des tests unitaires et des tests d'intégration ont été utilisés dans cinq projets. Les tests unitaires/de base dans un projet sont similaires aux tests de fumée. Cependant, les tests unitaires dans ce contexte n’ont pas de portée clairement définie. La moitié des projets étudiés utilisaient l’automatisation des tests. Cependant, les cas de test toujours plus nombreux ne sont pas toujours mis à jour dans l'architecture d'automatisation. Il ressort des données des entretiens que de nombreuses équipes n'effectuent pas de tests d'intégration de systèmes. Cependant, la plupart des équipes conviennent que les tests d’intégration peuvent remplacer les tests système. Comme le montre le tableau 1, d’autres formes de tests, telles que les tests de régression et exploratoires, sont moins courantes mais ont récemment gagné en importance au sein des entreprises.
4.3. Collecte de données
Les données ont été collectées au moyen d'entretiens et de documentation du processus. Cependant, les données provenant d'autres sources n'ont pas été collectées en raison du manque de disponibilité et de la qualité insuffisante des données (par exemple, données quantitatives). La motivation derrière l’utilisation de plusieurs sources de données (triangulation) est de limiter l’impact d’une seule interprétation et ainsi de renforcer les conclusions.
4.3.1. Choix du répondant
Le processus de sélection des répondants s’est déroulé selon les étapes suivantes :
• Création d'une liste complète des personnes impliquées dans le processus de test, quel que soit leur rôle.
• Nous souhaitons sélectionner au moins 2 personnes pour chaque projet, ce qui n'est pas possible d'un point de vue convivialité. Surtout pour les petits projets, une seule personne a été sélectionnée. Pour les projets plus importants, davantage de personnes sont sélectionnées. De plus, les différents rôles liés au processus de test (y compris les développeurs, les gestionnaires et les testeurs désignés) doivent être couverts. Toutefois, la liste définitive des employés ayant participé aux entrevues était basée sur la disponibilité des plages horaires dans lesquelles les entrevues avaient lieu.
• Les répondants ont reçu un courriel leur expliquant pourquoi ils avaient été retenus pour l'étude. L'e-mail contient également l'objet de la recherche et une invitation à un entretien.
Tableau 1 : Aperçu du projet (unité d'analyse )
Les rôles sélectionnés représentent des postes directement impliqués dans les activités liées aux tests ou affectés par les résultats du processus de test global (voir le tableau 2).
Tableau 2 : Description du rôle
Les rôles de projet et d'organisation hiérarchique des trois divisions Alpha, Beta et Gamma (les noms des divisions ont été renommés pour des raisons de confidentialité) ont été inclus dans notre étude. On peut également constater que certains rôles sont liés au travail de projet et d'autres sont liés aux responsabilités hiérarchiques au sein du département, c'est-à-dire qu'ils soutiennent différents projets au sein du département. Le nombre d'entretiens liés aux départements, aux projets et aux rôles est indiqué dans le tableau 3.
Tableau 3 : Répondants
Dans les divisions Alpha et Beta, un nombre suffisant d'employés étaient disponibles, mais dans Gamma, une seule personne a été interrogée en raison du manque d'effectif dans la division. Cette personne a été choisie parce qu’elle était considérée comme une experte possédant une vaste expérience dans les tests de systèmes automobiles.
4.3.2. Conception de l'entretien
Les entretiens couvraient quatre sujets ; la durée des entretiens était fixée à environ une heure chacun. Tous les entretiens ont été enregistrés sous format audio et des notes ont été prises. Une stratégie d'entretien semi-structuré a été utilisée dans tous les entretiens. Les sujets de l'entretien sont :
1. Échauffement et expériences : questions sur les antécédents, les expériences et les activités actuelles du répondant.
2. Vue d'ensemble du processus de test logiciel : problèmes liés à l'objet de test, aux activités de test et aux informations requises et générées pour effectuer le test.
3. Défis et points forts lors des tests : ce sujet capture les points forts/bonnes pratiques ainsi que les défis/pratiques sous-performantes. Les répondants doivent indiquer quelle pratique ils utilisent, quelle est leur contribution à la valeur et où elle se situe dans le processus de test.
4. Possibilité d'amélioration du processus de test : ce sujet comprend la collecte de questions sur les raisons pour lesquelles les défis doivent être éliminés et sur la manière dont le processus de test peut être amélioré.
4.3.3. Traiter les documents
Les documents de processus tels que les documents de processus de développement logiciel, les documents de description des tests logiciels, les documents de planification des tests logiciels et les rapports de test sont étudiés pour obtenir un aperçu des activités de test. De plus, des documents relatifs à l'organisation et à la description du processus de l'ensemble du processus de développement ont été étudiés afin de vous familiariser avec la terminologie utilisée par l'entreprise. Cela facilite à son tour la compréhension et l’analyse des données des entretiens.
4.4. Analyse des données
Afin de comprendre les défis et les avantages du processus d'essais automobiles, nous avons effectué une analyse approfondie des différentes unités d'analyse en utilisant une approche codée. Cinq transcriptions d'entretiens ont été codées manuellement pour créer un premier ensemble de codes. Ces codes sont regroupés en différentes catégories principales, prédéfinies en fonction de nos questions de recherche (Niveau 1), de la littérature (Niveau 2) et du codage ouvert (Niveau 3 et Niveau 4), voir Tableau 4. À partir de là, un guide de codage a été élaboré. Nous avons utilisé du codage ouvert pour les transcriptions des entretiens, qui sont en constante évolution. Par exemple, si nous trouvons une nouvelle déclaration qui ne rentre pas dans un code déjà identifié, nous en créons une nouvelle, comme l'interaction et la communication. Lorsque nous trouvons une autre instruction appartenant au code existant, nous lions cette instruction à ce code. Après avoir codé le texte, nous avons examiné chaque groupe, identifié des déclarations très similaires et les avons reformulées pour représenter un seul défi/force. Une fois terminé, nous avons examiné les clusters et fourni une description générale de chaque cluster. Pour valider les lignes directrices de codage, un employé de l'organisation de cas a codé manuellement les transcriptions des entretiens, comparé les résultats du codage avec les interprétations des chercheurs et apporté les révisions nécessaires. Les directives de codage sont continuellement affinées tout au long de la phase d’extraction des données.
4.5. Résultats
Les résultats comprennent une description du processus de test ainsi que des forces et des défis associés à ce processus.
4.5.1. Processus de test
La majorité des répondants (9 répondants) ont indiqué qu'il manque un processus de test clair pouvant être appliqué à n'importe quel cycle de vie d'un projet. Sur les 8 projets étudiés, seuls 3 avaient un processus de tests clairement défini. Il a été observé que chaque projet a suivi un processus très similaire à celui illustré à la figure 2, même si tous les projets n'ont pas suivi toutes les activités décrites dans ce processus.
La stratégie de test d'une organisation décrit les types de tests requis et la manière dont ils sont utilisés pour les projets de développement présentant le moins de risques. La stratégie de test utilisée par la société est principalement axée sur les tests en boîte noire, seule une petite partie des tests étant effectuée en boîte blanche. Il existe au sein de l'organisation un manuel du testeur qui décrit le processus, la méthodologie et les outils de test. Cependant, cette recherche montre que la plupart des équipes ne l'implémentent/ne l'utilisent pas. Les principales activités réalisées sont : la planification des tests, l'analyse et la conception des tests, la configuration des tests, l'exécution des tests et le reporting. Parmi eux, le plan de test a été réalisé plus tôt que prévu par cinq projets (trois grandes équipes représentées par P1, P2 et P4 et deux petites équipes représentées par P5 et P7). La plupart des petites équipes n'ont pas de plan de test logiciel, bien qu'elles aient une stratégie/approche de test très flexible.
Ces étapes sont décrites plus en détail ci-dessous :
Plan de test : cette activité explique ce qu'il faut tester et pourquoi. Le critère d'entrée pour cette activité est de préparer les exigences prioritaires à publier en tant qu'entrée dans le plan de test. Cette phase fournit le plan de test logiciel, y compris l'estimation et la planification des ressources requises, les artefacts de test à créer, ainsi que les techniques, outils et environnement de test requis. Les rôles impliqués dans cette étape de test sont les clients, les chefs de projet et les responsables de test. Si le projet ne dispose pas de responsable de test, les développeurs participent eux-mêmes aux activités de planification des tests. Le critère d'exportation du plan de test est l'approbation du plan de test par le client et la direction du projet.
Tableau 4 : Analyse par encodage
Analyse et conception des tests : cette activité de test vise à déterminer comment les tests seront effectués (en définissant les données de test, les cas de test et la progression du processus ou du système testé), ce qui est documenté dans la description du test logiciel. Une description de test logiciel définit également quels tests (c'est-à-dire les techniques de test) seront effectués pendant l'exécution du test. Les autres livrables de cette phase sont la matrice de traçabilité des exigences, les cas de test et la conception de scripts de test pour mettre en œuvre les cas de test. Les cas de test sont rédigés et gérés à l'aide de l'outil de gestion des cas de test utilisé dans tous les projets. Le critère pour accéder à cette étape est que le plan de test du logiciel soit approuvé par le client et la direction du projet. Le plan de test établi lors de la phase précédente est mis à jour avec tous les calendriers détaillés pour chaque activité de test. Le rôle impliqué dans cette phase est celui du responsable de test ou du coordinateur de test qui est responsable de la conception, de la sélection, de la priorisation et de l'examen des cas de test. Étant donné que les testeurs partagent les responsabilités entre les projets et qu'il n'est pas toujours possible d'effectuer des tâches de test, dans la plupart des projets, les développeurs sont responsables de l'écriture des cas de test pour leur propre code. Le chef de projet est responsable de la supervision des activités de tests.
Configuration des tests : dans les tests de logiciels automobiles, la configuration des tests est la partie la plus importante du processus de test car elle implique la création d'un environnement de test qui décrit l'environnement cible. Le résultat de ce niveau est de disposer du matériel et d'être capable de le visualiser comme un environnement réel, y compris les scripts de test et toutes les autres données de test. Étant donné que l'organisation du cas fonctionne avec le moteur de contrôle et l'unité de contrôle électronique (ECU) de la plupart des projets, des outils de modélisation tels que Simulink et MATLAB sont utilisés pour visualiser l'environnement cible. La plupart des testeurs ou développeurs participent à cette activité. Les chefs de projet sont chargés de fournir des ressources, telles que des périphériques matériels. Le chef de l’équipe de test supervise l’activité.
Exécution des tests et reporting : La dernière étape du processus de test consiste à exécuter les tests et à communiquer les résultats au client. Afin d'exécuter les tests, le responsable des tests ou le chef de projet choisira la bonne personne pour exécuter les scripts de test. Une fois les tests terminés, les résultats sont enregistrés dans le système de gestion des défauts. Le résultat de cette phase est un rapport de test logiciel qui décrit l'ensemble des tests effectués et leurs conclusions. Les résultats sont également analysés et évalués ultérieurement pour voir s'il existe des écarts par rapport à la version précédente du rapport de test. Si des erreurs critiques surviennent, elles sont corrigées et le test est répété. Le chef de projet est chargé de déterminer les critères d’arrêt de l’exécution des tests.
4.5.2. Avantages et expérience
Les avantages du processus de test de découverte dépendent de la taille de l'équipe. La plupart des pratiques considérées comme des points forts dans les petites équipes ne le sont pas dans les grandes équipes, et vice versa. Cela dit, il ressort clairement des entretiens que les points forts varient en fonction de la taille de l’équipe.
Travailler dans une petite équipe agile : les activités de test sont flexibles sans générer de rapports de test détaillés. Les grandes équipes ne le font que pour les petites versions. Les grandes équipes ont une approche des tests très structurée et axée sur un plan. Les petites équipes se concentrent sur l'intégration continue et le développement itératif (par exemple, P2 utilise Scrum avec intégration continue et planification de sprint). Les pratiques de tests agiles leur permettent de planifier plus facilement des tests pour chaque itération compatibles avec la spécification des exigences. Cela permet à son tour d'aligner correctement les tests avec d'autres activités telles que les exigences, la conception, etc. Par rapport aux petites équipes, les grandes équipes se concentrent la plupart du temps davantage sur la réutilisation des cas de test, ce qui les rend plus efficaces.
Figure 2 : Processus de test
Communication : les avantages de la communication peuvent être trouvés dans les projets dotés de pratiques agiles, telles que les réunions debout, la collaboration régulière des parties prenantes et la collaboration dans des espaces de bureau ouverts. Chaque activité implique un testeur, ce qui indique des efforts de test parallèles tout au long du cycle de vie du développement. En dehors de cela, les méthodologies agiles renforcent l’esprit d’équipe, conduisent à une interaction efficace entre les membres de l’équipe et forment des équipes interfonctionnelles. D'autres projets utilisent des réunions hebdomadaires et d'autres services électroniques tels que le courrier électronique et la messagerie au sein des projets.
Rôles et responsabilités partagés : les petites équipes considèrent comme un avantage qu'une seule personne assume les rôles de testeur et de développeur, car cela ne retarde pas le processus d'attente que quelqu'un teste le logiciel. Puisque le testeur est la même personne que le développeur, il n'y a aucun retard dans le reporting. Ainsi, si un développeur/testeur trouve un bug, il sait d'où le bug a été introduit, au lieu de blâmer quelqu'un d'autre, le développeur sera plus prudent lors de l'écriture du code". Cependant, les grandes équipes ne voient pas cela comme un avantage ; la plupart de ces équipes ne disposent pas de testeurs dédiés (à l'exception d'une grande équipe qui dispose d'une équipe de tests dédiée).
Techniques, outils et environnements de test : nous jetons ici un regard différent sur l'échelle du projet. Dans les petites équipes, utilisez moins d’outils et de méthodes de test pour éviter plus de documentation. Ces équipes ont généralement moins de modules de projet que les équipes plus grandes. Dans ce cas, le système est bien connu du testeur/développeur (le développement et les tests sont effectués par une seule personne dans une petite équipe), ce qui facilite le test avec un nombre minimum d'outils et de méthodes. Les petites équipes (telles que les projets P3 et P6) effectuent généralement des tests de fumée ou des tests unitaires d'abord pour tester les fonctions de base du système, puis effectuent des tests d'intégration. Un employé explique l'objectif des tests unitaires/de base en disant : « Je considère les tests unitaires comme un point fort. Cela permet d'entrer dans les détails et de s'assurer que chaque sous-système fonctionne comme prévu ». Les outils de test utilisés ici ont été développés par l'équipe pour répondre aux besoins du projet. Cependant, ces outils personnalisés développés pour leur équipe spécifique ne sont pas partagés entre les équipes. La principale préoccupation des petites équipes est de disposer d’un environnement de test avec le même matériel et les mêmes interfaces que l’environnement cible. Cela rend la maintenance des tests dans le projet efficace.
Outils de test de code recommandés
Contrairement aux petites équipes, les grandes équipes effectuent des tests en utilisant plusieurs méthodes et outils pour effectuer plusieurs activités. L’un des atouts les plus évidents des grandes équipes réside dans les tests basés sur l’expérience (tels que des projets tels que P1, P2, P4 et P8). Étant donné que les mêmes membres de l’équipe travaillent sur le même projet depuis des années, il leur est facile d’utiliser leurs connaissances fondées sur l’expérience dans le développement et les tests de produits. Un employé responsable du coordinateur qualité dans une grande équipe a déclaré : « Les mesures utilisées pour les tests n'ont pas beaucoup aidé notre équipe car les tests étaient davantage basés sur notre expérience, que nous avons utilisée pour décider quel type de cas de test devait être exécuté. "Un autre avantage perçu est la gestion des tests exploratoires/basés sur les sessions appliquée dans les projets P1 et P2. Un employé a souligné que "la charte permet d'effectuer des tests basés sur des sessions (c'est-à-dire des tests exploratoires) et nous avons trouvé des bugs critiques à un niveau de détail plus fin". Le Hardware-in-the-loop (HIL) est également considéré comme l’un des points forts des grandes équipes car il détecte la plupart des défauts lors des tests d’intégration. HIL pour l'intégration et les tests au niveau du système est considéré comme un avantage car il peut détecter les défauts les plus critiques tels que les problèmes de synchronisation et d'autres problèmes en temps réel dans les systèmes vastes et complexes. Les révisions informelles de code sont considérées comme un avantage pour les grandes équipes, même si elles sont également utilisées pour les petites équipes. La révision informelle du code évite les biais dans les tests car elle est effectuée par une personne autre que la personne responsable du codage.
En parlant d'outils, les outils de gestion des cas de test ont été cités comme un avantage pour les grandes équipes (telles que P4), comme l'a souligné un employé : « Je pense que la gestion des cas de test consiste à stocker les cas de test, à choisir les tests à exécuter et à donner des commentaires. des testeurs. bonne idée". D'autres outils considérés comme utiles sont les outils de gestion des défauts (par exemple, les projets). Un environnement de test dans une grande équipe est idéal pour les tests car il décrit l'environnement réel.
4.5.3. Défis
Les défis se répartissent en plusieurs domaines. Pour chaque domaine de défi, nous indiquons également le nombre de projets qui ont abordé le défi dans le domaine de défi, ainsi que les domaines de processus sur lesquels le domaine de défi se concentre (voir tableau 5), et rapportons un ensemble de questions connexes pour chaque domaine.
Tableau 5 : Aperçu des domaines de défis
C01 : Organisation des tests et ses enjeux liés au processus : Les problèmes organisationnels concernent des pratiques mal exécutées liées à l'organisation et à son processus de test, comme la gestion du changement, l'absence d'un processus de test structuré, etc. Les problèmes organisationnels incluent également les attitudes des parties prenantes à l’égard des tests (si les tests ne reçoivent qu’une faible priorité).
C01_1 : Pas de processus de test unifié : les projets varient en termes de méthodologies de test et d'utilisation des outils, et en raison de la fonctionnalité fragmentée et de la complexité évolutive du matériel et des logiciels, trouver un processus unifié qui s'adapte à tous les projets est considéré comme un défi. Bien qu’il existe un manuel de test qui permettrait d’obtenir un processus plus uniforme, il n’est pas utilisé parce que les équipes n’en sont pas conscientes ou parce que les gens estiment qu’il ne correspond pas aux caractéristiques de leur projet. Un processus non structuré et mal organisé convient aux petits projets mais pas aux grands projets car il affecte la qualité. Comme l'ont souligné les personnes interrogées, « le processus de test semble non structuré et toujours désorganisé. Il fonctionne bien pour les petits projets, mais pas pour les grands ».
C01_2 : Les tests ont été précipités et mal planifiés : la date de livraison n'a pas été prolongée car plus de temps était nécessaire, ce qui a eu pour conséquence que les tests ont été affectés et précipités. De plus, le client n'a pas livré le matériel de test à temps et de bonne qualité, de sorte que les tests n'ont pas pu être terminés plus tôt que prévu, ce qui a entraîné un non-respect généralisé des délais de test.
C01_3 : Attitudes des parties prenantes à l'égard des tests : les efforts d'amélioration passés se sont concentrés sur la mise en œuvre et non sur les tests. De ce fait, les nouvelles méthodes de tests reçoivent peu de soutien de la part de la direction, ce qui conduit parfois les équipes à développer leurs propres méthodes et outils, ce qui demande beaucoup d'efforts.
C01_4 : Activités de test asynchrones : les tests ne sont pas synchronisés avec d'autres activités liées au fournisseur ; les artefacts de test doivent être restructurés pour être synchronisés avec les artefacts fournis par le fournisseur. Cela conduit à retravailler du côté des tests.
C02 : Contraintes de temps et de coût pour les tests : les problèmes liés aux contraintes de temps et de coût peuvent être dus au manque de temps consacré aux exigences, aux activités de test ou aux processus de test.
C02_1 : Manque de temps et de budget pour spécifier les exigences de vérification : les exigences de vérification sont des exigences qui sont vérifiées lors des tests (par exemple, en spécifiant les conditions environnementales dans lesquelles le système doit être testé). Le temps et l'argent économisés en ne rédigeant pas les exigences de validation ont entraîné beaucoup de retouches et de temps dans d'autres parties du processus, en particulier les tests.
Comme l'a souligné une personne interrogée : "Réécrire les spécifications des clients dans nos propres exigences ? Ce n'est pas possible aujourd'hui parce que les clients ne paieront pas pour cela et que nous n'avons pas de budget interne." Dans l'ensemble, l'absence d'exigences de vérification entraîne un manque de d’objectifs et une portée claire des tests.
C02_2 : L'équipement de test est disponible à temps : L'équipement de test n'est pas disponible à temps et la qualité n'est pas suffisamment bonne pour rendre impossible les tests unitaires.
C03 : Problèmes liés aux exigences : des exigences de test insuffisantes, des exigences de haut niveau difficiles à comprendre et la volatilité des exigences sont des défis qui empêchent des tests appropriés pour atteindre une qualité élevée. Ces problèmes surviennent généralement lorsque le client ne précise pas correctement ses exigences par manque de temps ou de connaissances, ce qui signifie que les exigences sont mal gérées.
C03_1 : Manque d'exigences explicites : trop peu d'efforts sont investis dans la compréhension et la documentation des exigences explicites, ce qui entraîne trop d'efforts réinterprétés à des étapes ultérieures (par exemple, tests). Comme l'a souligné l'un des employés : "Je pense que nous ferions mieux de commencer à consacrer plus d'efforts à la gestion des exigences et d'éviter que les clients ne se plaignent d'une mauvaise interprétation de leurs exigences spécifiées, afin que vous vous retrouviez avec moins de problèmes et que vous évitiez de répéter les modifications et de tester tout le temps consacré au contenu. ".
C03_2 : Les critères de finalisation de la conception des tests et de démarrage/arrêt des tests ne sont pas clairs : selon les entretiens, une fois les exigences stabilisées, la définition du processus de test sera effectuée. Les personnes interrogées ont lié la volatilité de la demande aux critères de démarrage et d’arrêt. La volatilité des exigences nécessite de redéfinir l’ensemble du plan de tests. Cela agit comme une barrière lorsque les tests proprement dits commencent. Dans les cas où les organisations utilisent des scripts de test pour effectuer des tests, elles ont du mal à définir quand arrêter les scripts et démarrer/arrêter les tests en fonction des demandes. Les critères déterminant quand arrêter les tests sont principalement liés au budget et au temps, et non à la couverture des tests.
C03_3 : Problème de gestion de la traçabilité des exigences : La traçabilité entre les exigences et les tests peut être améliorée pour identifier facilement les cas de test qui doivent être mis à jour lorsque les exigences changent. De plus, le manque de traçabilité rend plus difficile la définition de la couverture des tests. La raison du manque de traçabilité est que les exigences sont parfois trop abstraites pour les relier à des fonctions concrètes et à leurs cas de tests.
C04 : Contraintes de ressources pour les tests : Ces défis sont liés à la disponibilité de testeurs qualifiés et à leurs connaissances.
C04_1 : Manque de testeurs dédiés : tous les projets n'ont pas de testeurs dédiés, mais des développeurs qui interprètent les exigences, implémentent les logiciels et rédigent les tests. Le manque de vérification et de validation indépendantes (différentes personnes écrivant des logiciels et testant des logiciels) conduit à des biais dans les tests.
C04_2 : Les testeurs ne sont pas disponibles : Compte tenu de la complexité du système, il faut du temps pour accumuler des connaissances pour devenir un bon testeur. Si des testeurs expérimentés alternent entre les projets, il peut être difficile de trouver quelqu'un capable d'accomplir la tâche à accomplir. Une personne interrogée responsable des tests a déclaré : "Il est difficile de trouver des personnes ayant la même expérience, et il leur faut beaucoup de temps pour apprendre et comprendre le produit en raison de la complexité du produit. Par conséquent, les mêmes connaissances sont requis avant les tests.
C05 : Questions de test liées à la gestion des connaissances : Les questions liées à la gestion des connaissances identifiées dans cette étude de cas comprennent :
C05_1 : Dans le domaine des tests, questions de transfert systématique et de partage des connaissances : les nouvelles techniques de tests utilisées par les entreprises (tests exploratoires) nécessitent une grande quantité de connaissances qui ne sont pas disponibles car les testeurs sont en constante évolution et la recherche vers les nouveaux testeurs embauchés par l'entreprise, ces connaissances ne sont pas disponibles pour entrer dans le projet. Malgré la nécessité d’atteindre un état où un projet ne dépend plus d’une seule personne, il n’existe pas suffisamment d’informations et de matériel de formation sur la manière de réaliser les tests. Nous avons également constaté lors des entretiens que le défi du transfert de connaissances était amplifié par l'accent mis sur l'ingénierie de contrôle, la mécatronique et l'électrotechnique, en plus des logiciels.
C05_2 : Manque de connaissances de base en matière de tests : comme les testeurs manquent de connaissances de base en matière de tests, les tests reçoivent une faible priorité. Dans ce contexte, une personne interrogée impliquée dans les activités de gestion du cycle de vie a déclaré : "Je pense qu'il y a un manque d'informations sur la base des tests. Certains d'entre nous ne savent pas quand commencer les tests et quand les terminer, et j'ai l'impression que Une zone grise qui n’est clairement définie nulle part. »
C06 : Interaction dans les tests, questions liées à la communication : questions pratiques liées à la communication entre les différentes parties prenantes dans les tests. Comprend également les formes de communication inappropriées telles que le manque de réunions régulières en face à face, le manque de communication entre les clients et les testeurs.
C06_1 : Manque d'interaction régulière avec les clients sur les exigences : Au début du projet, les interactions avec les clients sont plus fréquentes, et en termes d'exigences de vérification lors des tests, il y a trop peu d'interactions avec les clients. Le client ne dispose pas des personnes compétentes pour communiquer les exigences en matière de tests.
C06_2 : Manque d'interaction avec d'autres rôles dans le projet pendant les tests : Manque de communication avec les anciens membres de l'équipe qui ont déménagé vers un autre projet, même s'ils sont nécessaires (par exemple, pour vérifier et corriger les bugs identifiés). Une personne interrogée a raconté l'incident de la manière suivante : « J'ai affecté une personne à notre équipe et ensuite elle doit communiquer avec nous, mais il est parfois difficile pour cette personne de retrouver cette personne car elle fait maintenant partie d'une autre équipe de travail ».
C06_3 : Communication informelle avec les clients : Dans l'ensemble, il existe un manque de communication face à face et informelle avec les clients, où les clients communiquent en fournissant des descriptions vagues qui ne sont pas clarifiées. Un responsable ajoute : « Je pense que le plus important est de maintenir la relation (la relation informelle avec le client) et de demander au client que nous ne pouvons pas commencer à travailler tant que vous ne nous dites pas ce que vous voulez ».
C07 : Questions liées aux techniques, outils et environnements de test : Questions liées à l'utilisation des techniques, environnements et outils de test actuels.
C07_1 : Le manque d'automatisation conduit à des retouches : L'automatisation des tests unitaires et des tests de régression n'est pas effectuée efficacement. Une personne interrogée a noté que « tant qu'il n'y a pas d'automatisation en place, les tests sont une refonte ». Générer et automatiser efficacement des tests était considéré comme un défi en raison du manque de support d'outils, conduisant à des retouches lorsque l'on souhaitait réexécuter les tests.
C07_2 : Il n'existe pas d'outil unifié pour l'ensemble de l'activité de test : Un responsable de test a souligné la nécessité d'un outil unifié pouvant être utilisé pour les tests "Nous disposons de nombreux outils disponibles pour les tests, mais il est difficile de décider quel outil utiliser " Parce que chaque outil a des inconvénients et des avantages. Parfois, nous sommes obligés de développer des outils personnalisés parce que nous ne pouvons obtenir du marché aucun outil qui fasse tout pour nous. " Un seul outil pour toutes les activités de test dans le domaine automobile peut être facilement utilisé au lieu de gérer et d'organiser la multitude d'outils actuellement utilisés.
C07_3 : Mauvaise maintenance de l'équipement de test : plusieurs environnements de test doivent être entretenus, le manque de maintenance entraîne des retouches, de longs délais avant le début des tests réels. Une personne interrogée l'a bien résumé : « Nous avons plusieurs environnements de test et étapes de test qui doivent être maintenus. Ils n'ont pas toujours besoin d'être maintenus, et il faut beaucoup de temps pour démarrer les tests proprement dits ».
C08 : Problèmes liés aux aspects qualité : Problèmes liés à l'inclusion d'attributs de qualité des tests tels que la fiabilité, la maintenabilité, l'exactitude, l'efficience, l'efficacité, la testabilité, la flexibilité, la réutilisabilité, etc. Implique des compromis entre la qualité et d’autres activités.
C08_1 : Problèmes de fiabilité : Le système n'est pas aussi fiable qu'il devrait l'être. La qualité est difficile à intégrer en raison du manque de processus de test et de la défaillance des composants matériels. Comme l'a souligné une personne interrogée, "il est difficile de répondre à plusieurs critères requis par un système, tels que des heures de travail plus longues, moins de ressources gourmandes, la capacité de travailler sur différentes plates-formes, etc.".
C08_2 : Les attributs de qualité ne sont pas bien spécifiés dès le début du projet : les exigences de qualité ne sont pas bien spécifiées, ce qui entraîne des problèmes de qualité des systèmes complexes sur le marché des produits existants.
C08_3 : Aucune mesure/évaluation de la qualité : Il n'existe aucune mesure de la qualité, mais leur nécessité est reconnue pour améliorer la capacité d'évaluer les résultats des tests, un employé déclarant : "Bien que nos clients soient satisfaits, la courbe de qualité doit être meilleure. I C'est pensait que les mesures de qualité devraient être enregistrées pour faciliter une meilleure analyse des résultats des tests".
C09 : Problèmes de détection des défauts : problèmes liés aux pratiques qui empêchent les testeurs de retracer les défauts, ou les causes profondes des défauts, et incluent également les problèmes liés à la prévention des défauts.
C09_1 : Les tests tardifs dans le processus rendent la réparation des défauts coûteuse : en raison de la complexité du système et des tests tardifs, le nombre de défauts dans un système augmente à mesure que le système se développe et évolue. En raison de l'absence de nombreux bogues dans les versions précédentes, les clients ont signalé un grand nombre de bogues qui devaient être corrigés dans les versions suivantes, ce qui rendait la correction des bogues coûteuse.
C09_2 : Difficulté à suivre les défauts non corrigés dans les versions précédentes : pour le développement de pièces complexes (c'est-à-dire impliquant des problèmes de temps de traitement et d'autres problèmes critiques), les différences de comportement du système entre deux versions différentes doivent être les mêmes. Mais cela n'arrive pas toujours car dans la version actuelle, un bug qui n'a pas été corrigé dans la version précédente est déclenché. En effet, lorsque ces bogues sont intraçables dans un système aussi vaste, ils peuvent devenir graves dans la prochaine version.
C10 : Problèmes liés à la documentation : les pratiques mal exécutées liées à la documentation des tests, telles qu'une documentation insuffisante, aucune documentation ou une documentation excessive, qui ne fournissent pas un support approprié pour maintenir la qualité dans le processus de test, font l'objet de ce domaine de défi.
C10_1 : La documentation sur les artefacts de test n'est pas tenue à jour : les personnes interrogées ont souligné que la documentation fournie (telle que les scénarios de test et autres artefacts de test) n'est pas suffisante pour les tests et n'est pas fiable ; un répondant a ajouté : « La documentation des tests n'est pas tenue à jour. à ce jour, nous les avons donc trouvés peu fiables". L'une des raisons mentionnées était que des modifications mineures ont été apportées aux artefacts de test, mais ces modifications n'ont pas mis à jour la documentation de test en conséquence. Le fait de ne pas mettre à jour la documentation entraîne des retouches.
C10_2 : Absence de manuels détaillés sur certaines méthodes et outils de test spécifiques : Une autre observation à cet égard est le manque de documentation sur le fonctionnement des outils et des méthodes. Une personne interrogée l'a bien résumé : « Il existe un support pour les outils, mais nous ne trouvons tout simplement pas de personnes capables de résoudre les problèmes avec eux. Je pense que cela pourrait être mieux documenté ». Cependant, il a été observé qu'il existe certains manuels au sein de l'organisation qui servent cet objectif. Mais pour certains outils ou méthodes spécifiques (tels que les outils personnalisés), cela ne fonctionne pas. Ce problème survient lorsque les personnes effectuant les tests ne comprennent pas les termes contenus dans les manuels ou ne connaissent pas les manuels.
Pour plus de contenu, veuillez prêter attention à « Analyse du processus de test EBSE automobile (3) : EBSE Étape 2, Déterminer les améliorations grâce à une revue systématique de la littérature », suivez Niuka.com et apprenez-en plus sur la technologie automobile.