Des vérités non dites sur les tests
L'automatisation des tests est souvent considérée comme une perte de temps. Ce n'est bien sûr pas vrai.
L'automatisation des tests est une perte de temps si elle commence par des tests unitaires non structurés et se termine par un test de système automatisé qui ne peut être réalisé et entretenu que par un expert.
Avec les tests unitaires générés automatiquement, le début est encore sans effort car les développeurs ont encore à leur disposition de nombreux outils familiers.
Les tests sont automatisés sans le temps nécessaire pour la R&D et
les équipes de développement pour assurer le suivi des interfaces nécessaires à l'automatisation.
Au niveau du test du système, l'automatisation n'est alors plus du tout automatisée parce que le degré de complexité semble trop élevé ou parce que les testeurs du système n'ont pas de savoir-faire dans le domaine des principes et des pratiques de développement. De plus, l'automatisation est souvent lancée aux mauvais endroits.
Les conditions préalables au déploiement du système (micrologiciel des appareils, mise du système dans un état initial défini, etc.
Nous serions heureux de vous aider à automatiser correctement les bons tests,
mais aussi de ne pas automatiser les bons tests. Il est important de garder les cadres d'automatisation des tests simples et de les rendre accessibles aux participants au projet qui ne font pas partie de l'équipe de développement principale
comprennent la possibilité de participer efficacement à l'automatisation des tests.
L'automatisation des tests n'est PAS une perte de temps.
Celui qui mesure beaucoup mesure de la merde. C'est exact, bien sûr. Nous vous aidons à définir les bons paramètres et à les argumenter. Ce n'est qu'avec les bons paramètres que le responsable des tests peut juger si la qualité s'améliore constamment ou si elle maintient le niveau souhaité.
Il est important de clarifier les objectifs à atteindre avec les mesures, les données qui doivent être collectées à cette fin et si l'effort de collecte et de configuration est approprié par rapport au gain.
Les métriques
SOUTIENNENT & ENCOURAGENT.
Bien sûr, il y a le danger de produire beaucoup de papier avec des procédés. Surtout lorsque les processus sont rédigés pour leur propre compte. Mais les processus ne remplissent jamais une fin en soi. Nous vous aidons à définir les processus nécessaires avec la portée qu'il faut pour éviter une surréglementation tout en atteignant le degré de normalisation souhaité.
Les processus de test génèrent de la
STRUCTURE.
Bien sûr, la visualisation est un bon moyen de transmettre les questions techniques à la direction. En outre, une visualisation correcte présente également l'avantage de condenser rapidement et facilement plusieurs données, par exemple lors d'un essai, de sorte que les états peuvent être enregistrés rapidement et clairement et que les activités requises peuvent être déduites rapidement. De cette manière, il est possible d'éviter un éventuel arrêt ou un échec complet d'un essai et de réduire les coûts.
Une visualisation correcte vous
aide, vous et votre équipe.
Les nouvelles approches déclenchent toujours en premier lieu une discussion sur leur utilité. C'est tout à fait normal et même une partie importante des processus de changement. Le BDD représente un développement supplémentaire du TDD et la qualité de vos produits s'en trouvera améliorée.
Le BDD améliore manifestement
la qualité
La responsabilité n'est ni délégable ni divisible. Il doit toujours être clair pour tous ceux qui portent le "chapeau de test" et qui sont chargés de l'assurance qualité. Les décisions prises à Scrum par des personnes issues d'autres domaines entraînent une perte de qualité.
Les
différentes
expériences et connaissances doivent être prises en compte individuellement
dans le projet.
Le point le plus important dans les tests de logiciels est l'attitude intérieure. Les tests sont principalement utilisés pour trouver les états d'erreur et les effets des erreurs. Il n'est pas question de prouver qu'un objet test fonctionne.