Nous avons préparé pour vous une traduction d'un article de Dmitry Yarygin, Ingénieur QA avec une expérience dans les grands projets du monde depuis plus de 8 ans, professeur du cours Mobile QA Engineer à OTUS. Est-il intéressant de se développer dans cette direction? Nous vous invitons à prendre gratuitement deux jours intensifs "Introduction à l'automatisation des tests d'applications mobiles sur Sélénium et Appium . "

Test de qualité. Qui en est responsable? Pendant de nombreuses années, la seule réponse à cette question était dans ma tête. Bien sûr, un ingénieur QA! Après tout, j'appartiens moi-même aux ingénieurs QA.

Je sais à quel point il est important de tester la qualité d'un produit logiciel dont la mise sur le marché est prévue. Cependant, j'ai remarqué certains modèles qui se produisent lors des tests. Ils m'ont fait réfléchir sur le processus de test dans son ensemble et comment il pourrait être amélioré.

Les développeurs devraient-ils tester leur code?

Merci d'avoir demandé. Si vous êtes développeur, vous connaissez toutes les subtilités et les pièges de votre code, ou du moins vous en savez plus sur votre code qu'un ingénieur QA. Vous connaissez votre code au loin et comprenez où le problème peut survenir.

Si vous savez où se situe le problème, informez-en l'ingénieur QA. Oui, il le trouvera lui-même à un moment précis, mais vous connaissez toujours mieux l'architecture de l'application. Les testeurs vous seront reconnaissants si vous leur dites où s'attendre à des problèmes.

Nous sommes des ingénieurs QA, nous allons nous concentrer sur cela et le couvrir de tests pour que vous soyez moins inquiet. Toute information supplémentaire que les développeurs peuvent fournir est clairement bénéfique.

Les tests unitaires sont certainement quelque chose que les développeurs devraient faire, c'est leur domaine de responsabilité. Les tests unitaires aideront à éviter les erreurs inutiles et les rapports inutiles à leur sujet. Mieux vaut éviter l'erreur avant que le code ne parvienne à l'équipe de testeurs, non?

Quelques mots sur le test de votre propre code. Je crois que les développeurs devraient au moins faire des tests de fumée de leur code. Aucun test approfondi n'est nécessaire. Vérifiez simplement que le code fonctionne sur certains ensembles de données d'entrée et donnez-le à l'équipe de testeurs afin qu'ils travaillent déjà dessus.

Si le code ne fonctionne pas déjà à ce stade, alors pourquoi le donner à QA? Vous obtiendrez des dizaines de messages d'erreur malgré le fait que vous savez déjà qu'il y a des problèmes - cela ne fera que ralentir le processus de développement.

Nous avons raté le bug. Les testeurs sont-ils à blâmer?

Oui et non. Chaque fois qu'une erreur est détectée, en particulier dans la production, vous et votre équipe avez quelque chose à discuter. Il y a plusieurs raisons pour lesquelles l'erreur n'est apparue qu'à ce stade:

1. L'endroit où l'erreur est apparue n'a jamais été une priorité pour les testeurs. Très souvent, personne n'a pensé à l'erreur qui est apparue sur la production. Ceci est le résultat d'un manque de communication entre les développeurs et les testeurs. La compréhension mutuelle n'a pas été atteinte sur la question de l'importance de vérifier un domaine. Des exemples classiques de cette négligence sont les problèmes de performances et de sécurité. Si vous savez que ces domaines sont essentiels pour votre application, informez-en l'équipe.
2. QA ne possède pas les connaissances nécessaires dans le domaine testé. C'est également un problème courant. Les développeurs ont écrit la fonction et ont automatiquement supposé que QA comprenait comment cela fonctionne de et vers. Eh bien, faire des hypothèses n'a jamais été une bonne stratégie pour analyser la qualité d'un projet sérieux. Si vous voyez un aspect important, assurez-vous que l'ingénieur principal en AQ et son équipe le voient et le comprennent également. Il n'y a aucun moyen de contourner cette étape.
3. Les développeurs ne s'en soucient pas vraiment. Nous sommes tous humains. Et nous avons tous une vie en dehors du travail. Certains développeurs travaillent d'arrache-pied pour créer un produit de haute qualité, ils parlent avec des testeurs, les informent sur d'éventuels problèmes et autres. Et il y a des développeurs qui s'en moquent. Ils n'utilisent pas ce produit tous les jours et ne comprennent pas son importance. Pour eux, ce n'est qu'une tâche secondaire qui doit être accomplie et oubliée. Autrement dit, ils ne se soucient pas que le produit final soit de qualité insuffisante.
4. Les ingénieurs QA s'en moquent. Voici le revers de la médaille. Tous les testeurs ne se soucient pas du projet. Certains ont juste besoin de terminer les tests, de faire un beau rapport et de l'oublier. Une couverture de test de haute qualité ne les dérange pas, ils ne veulent pas communiquer avec les développeurs. Vous pouvez discuter des bogues, mais ces testeurs peuvent tout simplement ne pas les trouver importants ou même s'enregistrer.
5. Les testeurs ne sont pas suffisamment qualifiés. Un autre problème peut résider dans le fait que les testeurs ne sont tout simplement pas suffisamment qualifiés pour tester votre application. Par exemple, vous devez effectuer des tests de pénétration, et tout ce qui est à votre disposition est une équipe de testeurs qui ne peut effectuer que des tests manuels. Dans ce cas, ils ne sauront tout simplement pas comment l'approcher. Ici, vous devez soit compter sur les développeurs, soit sélectionner plus
   Des ingénieurs QA qualifiés qui sauront exactement comment tester ce domaine particulier.
6. Manque de recherche sur les utilisateurs. Les développeurs savent comment créer une application et les ingénieurs QA comment la casser. Et les utilisateurs? Les utilisateurs sont de vraies personnes qui utiliseront votre application dans le monde réel. Ils ne vont pas le casser. C'est juste qu'ils sont tous différents et ont des objectifs différents, mais ils veulent tous les atteindre en utilisant votre application. Les ingénieurs d'assurance qualité peuvent s'habituer à l'erreur et se rendre compte qu'elle se produit rarement, par conséquent, cela n'a pas beaucoup d'importance. L'utilisateur ne tolérera pas cela. Si votre application se bloque, l'étape suivante consiste à la supprimer, puis à rechercher une alternative. Telle est la réalité. Rechercher un public d'utilisateurs et / ou avoir un groupe d'utilisateurs de test sont deux choses stratégiquement importantes.
7. Mauvaise organisation du processus de communication. Idéalement, vous avez besoin d'un processus de tri de bogues simple qui vous permettrait d'évaluer les erreurs de QA (ou au moins de les classer correctement) et de les transmettre aux développeurs afin qu'ils comprennent leur charge de travail. En cas de malentendu, le testeur et le développeur doivent toujours pouvoir s'approcher et résoudre ce problème en quelques minutes ou quelques heures. Si ce processus n'est pas établi et que les deux parties ne sont pas pressées de rechercher la cause du malentendu, il n'en résultera rien de bon. Les deux parties imiteront les activités, mais en fait, elles seront toutes les deux dans une impasse et attendront une troisième personne qui pourra venir résoudre la situation comme par magie. C'est fondamentalement la mauvaise approche.
8. Pas assez de testeurs. Une application peut être complexe et nécessiter des tests sur plusieurs plates-formes et navigateurs. Quelques ingénieurs QA pour cette tâche peuvent ne pas suffire. Envisagez d'embaucher plus de personnes ou de redistribuer les ressources dont vous disposez de manière à mettre davantage l'accent sur les tests.
9. Les développeurs sont surchargés. Autour de vous, vous pouvez être des spécialistes idéaux et hautement qualifiés, mais ils travaillent dans un stress constant et personne ne peut les aider. Oui, ils sont sous pression, et ils n'ont tout simplement pas le temps de parler à l'équipe QA. Il s'agit d'un problème très courant et c'est l'une des principales raisons pour lesquelles le logiciel est de mauvaise qualité.
10. La qualité n'est pas à l'honneur. Considérez également ce scénario. Ici et là, il y avait quelques bugs mineurs. Aucun d'eux n'est critique. Cependant, les utilisateurs n'aiment pas l'application. Les avis sont mauvais. UX est inférieur à la moyenne. Et pourquoi? Oui, car personne n'a pensé à créer un produit de qualité. Les développeurs ont fait leur travail, les testeurs ont fait le leur, mais personne n'a suivi le processus de contrôle de la qualité lui-même. Le développement d'applications doit combiner des équipes, en les formant ensemble. Si le collectif n'a pas une telle humeur, alors personne ne se soucie de la qualité.

Conclusion

Aujourd'hui, les applications deviennent de plus en plus difficiles. Si vous voulez trouver qui est à blâmer pour l'échec du projet, c'est facile. Le blâme peut être les ingénieurs QA, les développeurs et les cadres. Ou tous ensemble. La question principale est pourquoi devrions-nous chercher ceux à blâmer au lieu de prendre la responsabilité de la qualité du projet? Quiconque n'a pas réalisé l'importance de tester une fonction spécifique peut être à la place du coupable.

La seule question devrait être: "Faisons-nous un très bon produit?" . Si la réponse à cette question est oui, il ne fait aucun doute que toutes les équipes font une grande chose.

Personne ne sera à blâmer et tout le monde sera content, car l'assurance qualité est une tâche courante!