Je veux commencer à implémenter l'automatisation. Je ne sais pas si ce serait une bonne utilisation des ressources. L'application connaît une croissance exponentielle mais je ne sais pas à quel point l'automatisation est bénéfique pour les tests.Quand l'automatisation devrait-elle commencer?
Pouvez-vous me donner des raisons pour automatiser même si vous avez des testeurs manuels?
Je pense que cela dépend des gens qui travaillent dans l'entreprise . Certaines personnes aiment l'automatisation, d'autres l'aiment moins. Si votre entreprise ne l'a pas déjà essayé de le mettre en œuvre, cela pourrait être difficile.
Je préfère l'automatisation, à cause des heures (déjà mentionnées) et parce que pour la plupart, vous savez ce que vous allez en tirer.
Vous devriez avoir les deux, mais pour aller sans automatisation et tester deviendra très difficile à mesure que le produit se développe.
Il a répondu quand je devrais automatisé. Tout le monde m'a donné une bonne raison d'utiliser l'automatisation. – onesith
Rendre les tests plus efficaces - même si vous avez des testeurs manuels, s'ils (ou vous) peuvent implémenter des tests automatisés, alors beaucoup plus de cas peuvent être explorés. Écrire vos propres tests automatisés peut également vous donner un aperçu de votre propre code.
Vous automatisez parce qu'appuyer sur "aller" et attendre 10min pour les résultats signifie que votre testeur peut faire un autre travail utile pendant ces 10 minutes au lieu de baby-sitting l'application. N'oubliez pas qu'un test automatisé peut être effectué tous les soirs pendant votre sommeil. Vos testeurs peuvent alors utiliser leurs heures de travail pour écrire de nouveaux tests utiles au lieu d'exécuter les mêmes anciens tests encore et encore. La plus grande raison est que lorsque vous avez changé quelque chose peu de temps avant l'expédition, avec des tests automatisés, vous n'hésiterez pas à exécuter les tests même si "le changement était simple et ne devrait rien avoir cassé" - et vous respirer un soupir de soulagement lorsque les tests automatisés attraper le bug que vous aviez introduit et étaient sur le point d'expédier.
L'automatisation est presque toujours un bon moyen de tester. Le test manuel est toujours important, mais il est beaucoup plus sujet aux erreurs et si votre processus de test manuel commence à prendre des jours ou des semaines, il devient difficile de déployer les mises à jour rapidement. Il est généralement plus facile de configurer l'automatisation au début d'un projet, car vous aurez moins de choses à automatiser, et une fois que vous aurez mis en place votre infrastructure d'automatisation, il sera facile de l'étendre au fur et à mesure de la croissance de votre projet.
Essayer d'automatiser les tests sur un projet déjà entièrement implémenté nécessitera probablement plus de travail que d'automatiser depuis le début, donc je vous recommande de plonger dès que possible.
La répétition de tests est douloureuse et sujette aux erreurs lors de tests manuels, et si l'application est modifiée, les tests doivent être répétés.
test automatique peut également référence et identifier les problèmes avec l'interface utilisateur ... qui pourrait même être pas manuellement cliqué thaaat rapide :)
Imaginez que la taille du programme et le nombre de tests augmente de façon linéaire avec temps, et que vous voulez effectuer des tests d'intégration et de régression continus (quotidiens). Dans ce cas, le premier jour, vous testerez une chose, le deuxième jour vous en testerez deux, le troisième jour vous en testerez trois, etc.
L'effort total d'essai pour les tests manuels augmente avec le carré de la taille du programme: en raison de retesting et re-retesting.
Si vous n'automatisez pas, vous n'effectuerez pas de tests de régression complets et réguliers.
La raison de l'automatisation des tests est que cela signifie que je peux obtenir des retours cohérents, répétables et opportuns que ce que je viens de faire est correct.
Le test manuel a aussi sa place, mais il est difficile d'être aussi convaincu qu'il couvre tout correctement, et certainement pas aussi rapidement que les tests automatisés.Par exemple, une partie d'un de mes projets est un algorithme d'optimisation qui utilise des heuristiques pour contourner l'espace de recherche à la recherche de bonnes solutions. Il y a maintenant environ 40 heuristiques différentes qui peuvent être utilisées individuellement ou dans diverses combinaisons, et chaque rencontre avec un client semble impliquer l'ajout d'une nouvelle heuristique ou l'extension d'une heuristique existante. Je dois être absolument certain que rien de ce travail pour un client ne provoquera une régression pour un autre client, ce qui implique d'exécuter l'algorithme sur quelques centaines de cas différents et de vérifier que la sortie est (pas pire que). Il ne serait pas pratique de demander à un testeur manuel d'exécuter tous ces tests en chargeant l'interface graphique, en ouvrant le fichier d'entrée et en cliquant sur "Exécuter", au moins pas assez souvent pour être un mécanisme de retour utile. Les tests sont généralement effectués des dizaines de fois par jour pour les tests courts et tous les soirs pour les tests les plus lourds. Avec un processus manuel, un retour d'information complet prendrait probablement quelques jours, et réparer un bug introduit il y a quelques jours est beaucoup plus difficile que de corriger un bug introduit dans la dernière demi-heure.
Il serait également très difficile de s'assurer que tous les contrôles «oculaires» des résultats sont aussi bons qu'ils l'étaient auparavant, de sorte que les vérifications des résultats doivent être automatisées. Mais si vous voulez automatiser cela, vous pouvez tout aussi bien automatiser le tout. C'est pas difficile. Un autre avantage des tests automatisés, de l'expérience de travailler avec un projet qui n'en avait pas, est que si vous avez des tests manuels qui ne sont pas documentés, alors quand le projet est dormant (en mode maintenance apparemment) Pendant un an, puis redémarre le développement actif, personne ne se souvient très bien de la façon de faire les tests ou des résultats attendus, et vous finissez par introduire toute une pile de régressions idiotes qui mettent du temps à se fixer. D'un autre côté, si vous documentez suffisamment vos tests pour qu'ils puissent être récupérés un an plus tard, vous les avez essentiellement automatisés: il suffit de rendre la documentation exécutable.
Dans mon expérience, vous devez commencer à tester environ 2 heures avant le moment où vous réalisez soudainement que vous avez commencé à tester :) il y a 2 heures
Pouvez-vous me donner des raisons pour automatiser même si vous avez des testeurs manuels?
J'automatiserais tout ce qui peut être automatisé. Quelle est la valeur ajoutée de l'utilisation d'un cerveau humain pour quelque chose qui peut être fait par une machine d'une manière répétable? Et qu'en est-il du développement personnel? Je préfère utiliser un cerveau humain pour quelque chose qu'ils peuvent faire mieux que des machines: penser.
Vous devriez automatiser dès que possible. De nombreuses études ont montré que plus le défaut est tardif dans le cycle de développement, plus il est coûteux à réparer. L'automatisation permet généralement de détecter les défauts le plus tôt possible (en supposant que vous exécutez ces tests automatisés le plus rapidement possible).
Le plus tôt vous commencez à écrire des tests automatisés, plus vite vos développeurs peuvent commencer à courir les tests automatisés et/ou ils peuvent être exécutés dans un environnement d'intégration continue. Et une fois que cela se produit, vous trouvez plus tôt des défauts qui économisent l'argent de l'entreprise et rendent les développeurs heureux parce que cela leur permet de produire un code de meilleure qualité. Cela leur donne également la confiance de faire des changements parce qu'ils peuvent rapidement voir si cela entraîne une régression.
De plus, il rend vos ingénieurs de qualité beaucoup plus une partie du processus global plutôt que de se sentir comme leur effort est quelque chose clouée à la fin après que la plupart des travaux a déjà été fait.
Il y a quelques règles de base avant de commencer l'automatisation comme vous assurer que votre application est assez stable, essayez d'autre part à partir d'automatisation avec par exemple créer un script de test de fumée, qui ne touche que les parties majeures (seulement les parties critiques de la fonctionnalité). Par exemple, s'il s'agit d'une application bancaire, il suffit de l'automatiser si l'utilisateur est en mesure de se connecter et de vérifier le solde de son compte, etc. et rien de plus ou de moins. De cette façon, essayez d'augmenter le dépôt de script lorsque l'application devient plus stable avec le temps. Mais le plus important est de vous demander quel est exactement le but que vous voulez résoudre avec l'automatisation.
lien ci-dessous peut également aider:
son comme vous essayez de trouver un cadre de tests qui permettent d'automatiser ce que vos testeurs QA font (test GUI). Avez-vous déjà des tests de niveau inférieur (unité/intégration)? Il est important d'avoir ceux avant d'avoir l'automatisation de l'interface graphique. –
Merci à tous pour vos réponses. Ils étaient tous très utiles. En ce moment je regarde Selenium et Ruby. Je suis sûr que vous me verrez poster plus de questions bientôt. – onesith
Après avoir regardé ma dernière question, j'ai foiré. Cela devrait être "Quand" au lieu de pourquoi. merci encore. – onesith