Introduction
Bonjour, habitants de Khabarovsk. J'ai récemment résolu une tâche test pour un poste de QA Lead dans une entreprise fintech. La première tâche consistait à établir un plan de test avec une liste de contrôle complète et des exemples de cas de test pour vérifier une bouilloire électrique, ce qui est triviale :
Il est difficile d'imaginer un meilleur plan de test avec une liste de contrôle complète.
La seconde partie s'est révélée être une question : « Existe-t-il des problèmes communs à tous les testeurs qui empêchent de travailler plus efficacement ? »
La première chose qui m'est venue à l'esprit : énumérer tous les problèmes plus ou moins significatifs que j'ai rencontrés lors des tests, écarter les détails, et généraliser le reste. Mais j'ai vite compris que la méthode inductive répondrait à une question qui ne s'applique pas à "tous", mais au mieux à "la majorité" des testeurs. J'ai donc décidé d'aborder cela d'une manière différente, déductive, et voici le résultat.
Définitions
La première chose que je fais généralement en résolvant une nouvelle tâche est d'essayer de comprendre de quoi il s'agit, et pour cela, je dois comprendre le sens des mots par lesquels elle est formulée. Les mots clés à clarifier sont les suivants :
- problème
- testeur
- travail du testeur
- efficacité du travail du testeur
Considérons Wikipedia et le bon sens :
(du grec ancien πρόβλημα) au sens large — question théorique ou pratique complexe nécessitant étude ou résolution ; en science — situation controversée apparaissant sous la forme de positions opposées dans l'explication de certains phénomènes, objets, processus et nécessitant une théorie adéquate pour sa résolution ; dans la vie, un problème se formule sous la forme compréhensible pour les gens « je sais quoi, je ne sais pas comment », c'est-à-dire qu'il est connu ce qui doit être obtenu, mais il n'est pas clair comment le faire. Cela provient du latin tardif problēma, du grec πρόβλημα « jeté en avant, posé devant » ; de προβάλλω « lancer en avant, présenter devant soi ; accuser ».
Il n'y a pas beaucoup de sens, en réalité, « problème » = « quelque chose avec quoi il faut s'occuper ».
— un spécialiste (nous ne allons pas les diviser par types, puisque nous nous intéressons à tous les testeurs), participant au test d'un composant ou d'un système, dont le résultat de l'activité est :
— un ensemble d'activités liées à la test.
(latin. effectivus) — rapport entre le résultat atteint et les ressources utilisées (:2015).
— conséquence d'une chaîne (série) d'actions (resultat) ou d'événements, exprimés qualitativement ou quantitativement. Les résultats possibles incluent un avantage, un inconvénient, un bénéfice, une perte, une valeur et une victoire.
Comme avec le « problème », le sens est peu. Quelque chose qui s'est produit à l'issue du travail.
— capacité mesurable quantitativement d'effectuer une activité humaine ou de groupes de personnes ; conditions permettant, grâce à certaines transformations, d'obtenir le résultat souhaité. Un testeur — une personne, et conformément à la théorie des ressources vitales, chaque personne possède quatre actifs économiques :
ressources financières (revenu) — ressource renouvelable ;
énergie (force vitale) — ressource partiellement renouvelable ;
temps — ressource fixe et fondamentalement non renouvelable ;
connaissances (information) — ressource renouvelable, partie du capital humain qui peut à la fois croître et se dégrader..
Je voudrais noter que la définition de l'efficacité dans notre cas n'est pas tout à fait correcte, car plus nous utilisons de connaissances, plus l'efficacité semble faible. C'est pourquoi je redéfinirais l'efficacité comme « le rapport entre le résultat atteint et les ressources dépensées ». Alors tout est correct : les connaissances au travail ne s'épuisent pas, mais réduisent les dépenses de la seule ressource fondamentalement non renouvelable du testeur — son temps.
Solution
Ainsi, nous recherchons les problèmes globaux des testeurs qui nuisent à l'efficacité de leur travail.
La ressource la plus significative dépensée par un testeur est son temps (les autres peuvent en quelque sorte y être liés), et pour pouvoir parler d'un calcul correct de l'efficacité, il faut également relier le résultat au temps.
Pour cela, considérons un système dont la viabilité est assurée par le travail du testeur. Un tel système est un projet, dont l'équipe comprend un testeur. Le cycle de vie du projet peut être grossièrement représenté par l'algorithme suivant :
- Travail sur les exigences
- Élaboration du cahier des charges
- Développement
- Test
- Mise en production
- Support (retour au point 1)
Dans ce cadre, l'ensemble du projet peut être récursivement décomposé en sous-projets (fonctionnalités), ayant le même cycle de vie.
Du point de vue du projet, l'efficacité de sa mise en œuvre est d'autant plus grande que le temps qui y est consacré est faible.
Ainsi, nous en arrivons à définir l'efficacité maximale possible d'un testeur du point de vue du projet : c'est l'état du projet lorsque le temps de test est nul. Et le problème général auquel tous les testeurs sont confrontés est l'impossibilité d'atteindre cet état.
Comment aborder cela ?
Les conclusions sont assez évidentes et sont déjà utilisées par beaucoup :
- Le développement et les tests doivent commencer et se terminer presque simultanément (généralement, cela est géré par le département ). L'idéal serait que toutes les fonctionnalités en cours de développement soient couvertes par des tests automatisés au moment où elles sont prêtes, organisées en tests de régression (et, si possible, en tests pré-commit) à l'aide de quelque chose comme .
- Plus il y a de fonctionnalités dans le projet (plus il est complexe), plus le temps consacré à vérifier que la nouvelle fonctionnalité n'a pas cassé l'ancienne sera important. D'où, plus le projet est complexe, plus l'automatisation est nécessaire. .
- Chaque fois que nous laissons passer un bug en production et qu'un utilisateur le découvre, nous devons consacrer du temps supplémentaire à parcourir le cycle de vie du projet à partir du point 1 (Travail sur les exigences, dans ce cas, celles des utilisateurs). Comme les raisons du passage d'un bug sont généralement inconnues, il ne nous reste qu'un moyen d'optimiser : chaque bug trouvé par les utilisateurs doit être inclus dans les tests de régression, afin d'être sûr qu'il ne réapparaîtra pas.
Source : habr.com
