Get best of the week

Évaluation des tests: comment calculer le temps exact pour tester le système ou "Quand les tests seront-ils prêts?!"

image

Bonne journée à tous! Je m'appelle Denis, je suis le chef du service d'essais du Groupe BARS. Ceci est mon premier post sur Habré.

Après avoir lu beaucoup d'articles intéressants et obtenu de nombreuses informations utiles à partir de là, je voulais donner quelque chose en retour. Puis j'ai commencé à analyser les sujets: certains étaient déjà exprimés, d'autres étaient trop simples ("comment entrer dans l'informatique?"). PS je ne voulais pas blesser les sentiments de personne :)

Comment calculer le temps pour les tests - problème et solution


En tant que responsable du service, je tombe constamment sur une question des managers: "Quand sera-t-elle prête?" ou "Combien de temps faut-il pour tester?" Il semblerait que cela soit compliqué, faites une évaluation du projet précédent et plus ou moins la même chose ... mais non. J'ai réalisé que la tâche n'est pas anodine et nécessite une étude détaillée. Et je veux partager sa décision.

Notre entreprise dispose de nombreux centres d'affaires et chacun a sa propre approche de développement - principalement Kanban et Scrum. Par conséquent, des équipes de testeurs automatisés ont été choisies, qui sont synchronisées avec l'équipe de développement avec leur méthodologie.

En raison des différentes approches de la gestion du développement, des difficultés surgissent dans l'uniformité de la formation et de la planification des tâches. L'utilisation de Kanban et Scrum dans sa forme pure n'a pas donné de réponse sur le temps qu'il faudrait pour tester. Dans les décisions de conception, il faut à chaque fois évaluer la nouvelle fonctionnalité et la couvrir de tests. Il m'a fallu beaucoup de temps pour calculer. Par conséquent, j'ai décidé de prendre comme base les méthodes d'estimation des coûts de temps pour le développement de logiciels (pour tester l'automatisation) et de les adapter à mes réalités. Le principe de l'évaluation moyenne pondérée et du calcul basé sur la dactylographie a constitué la base. Les estimations seront des indicateurs temporaires pour l'automatisation des éléments typiques du système, et le niveau de formation spécialisée sera utilisé comme pondération. Lors de la formation des valeurs des poids, j'ai choisi la précision de l'évaluation lors de l'exécution de la tâche, c'est-à-dire que plus le spécialiste est expérimenté,plus l'erreur d'estimation est faible. Les valeurs suivantes ont été obtenues:

  • "Senior" - précision de 95%, facteur 1,05
  • "Moyen +" - 80% de précision, facteur 1,2
  • "Moyen" - précision de 70%, coefficient 1,3
  • "Junior +" - précision de 60%, coefficient 1,4
  • Junior - précision de 50%, facteur 1,5

Ensuite, nous devrons multiplier l'estimation temporelle t n par le coefficient correspondant W n . Notre méthode de calcul est effectuée selon la formule, où la somme des poids n'est pas égale à 1 (100%).

image

W moy = (w 1 * t 1 + w 2 * t 2 ... + w n * t n ) / (w 1 + w 2 + ... + w n )

Pour le calcul, j'ai pris deux tests - test fonctionnel et test d'interface utilisateur, car ils totalisent environ 85%.

Pour obtenir le résultat final, nous devons collecter une note moyenne pondérée pour chaque élément dans un objet plus grand pour les calculs - une catégorie.

Test de l'interface utilisateur


Lors du test de l'interface utilisateur, vous devez émuler le travail de l'utilisateur via le framework Selenium.Webdriver. Lorsque vous utilisez cette approche, il est difficile de construire des éléments sur des formulaires: onglets, documents avec modification en ligne, énormes grilles avec des lignes, une arborescence, etc. En plus de ces éléments, il existe également des facteurs qui affectent le temps de développement du test:

  • Structure des formulaires (constructeur typique ou personnalisé)
  • Demandes AJAX (leur nombre)

Sur cette base, 3 catégories de formulaires UI ont été distinguées par leur difficulté à mettre en œuvre les tests:

1 catégorie



2 catégorie



3 catégorie



En conséquence, j'ai reçu les résultats suivants, qui sont présentés dans le tableau:



Test fonctionel


Pour les tests fonctionnels, la situation est similaire à l'interface utilisateur - les catégories de systématisation des cas sont mises en évidence. En plus des services REST, il convient de mentionner le SOAP, il sera similaire aux 3 catégories de REST.

Les tests d'intégration impliquent de tester plusieurs méthodes dans un service, pour une évaluation approximative, nous avons pris la présence de 5 méthodes pour 1 service.

1 catégorie



2 catégorie



3 catégorie



Similaire au tableau de l'interface utilisateur: les



tests d'intégration vérifient le fonctionnement des services basés sur REST et SOAP. Lors de la conception d'un service, le nombre de méthodes utilisées à l'intérieur peut varier. Pour les calculs, nous avons pris en moyenne 5 méthodes.



Avec ce calcul du temps passé sur le projet, le pourcentage d'entrer dans cette estimation était de 81.

Au lieu d'une conclusion


Il a fallu une semaine de dur labeur pour compter la première fois. Par conséquent, j'ai fait l'évaluation après le test, puis j'ai comparé les résultats avec les coûts en temps réel.

Il suffit de faire le travail principal une fois, puis de le considérer selon la «formule» toute faite. Mais vous devez prendre en compte le fait que le niveau d'employés augmente, vous devez donc comprendre le poids de chaque employé afin de savoir s'il faut recalculer les indicateurs.
Tout ce qui précède est mon expérience et ne prétend pas être vrai.

More articles:


All Articles