introduction
Bonjour, habitants de Khabrovsk. Je viens de résoudre une tâche de test pour un poste vacant de responsable assurance qualité pour une entreprise de technologie financière. La première tâche, créer un plan de test avec une liste de contrôle complète et des exemples de cas de test pour tester une bouilloire électrique, peut être résolue de manière triviale :
Il est difficile d’imaginer un meilleur plan de test avec une liste de contrôle complète.
Mais la deuxième partie s'est avérée être une question : « Y a-t-il des problèmes communs à tous les testeurs qui les empêchent de travailler plus efficacement ?
La première chose qui m'est venue à l'esprit a été de lister tous les problèmes plus ou moins visibles que j'ai rencontrés lors des tests, d'éliminer les petites choses et de résumer le reste. Mais j’ai vite compris que la méthode inductive répondrait à une question qui ne s’appliquait pas à « tous », mais, au mieux, seulement à « la majorité » des testeurs. J’ai donc décidé de l’aborder de l’autre côté, de manière déductive, et c’est ce qui s’est passé.
définir
La première chose que je fais habituellement lorsque je résout un nouveau problème est d’essayer de comprendre de quoi il s’agit, et pour ce faire, je dois comprendre le sens des mots qui le posent. Les mots clés à comprendre sont les suivants :
- problème
- testeur
- travail de testeur
- efficacité du testeur
Tournons-nous vers Wikipédia et le bon sens :
(grec ancien πρόβλημα) au sens large - une question théorique ou pratique complexe qui nécessite une étude et une résolution ; en science - une situation contradictoire qui apparaît sous la forme de positions opposées dans l'explication de tout phénomène, objet, processus et nécessite une théorie adéquate pour la résoudre ; dans la vie, le problème est formulé sous une forme compréhensible pour les gens : « Je sais quoi, je ne sais pas comment », c'est-à-dire qu'on sait ce qu'il faut obtenir, mais on ne sait pas comment le faire . Vient tard. lat. problème, du grec. πρόβλημα « jeté en avant, placé devant » ; de προβάλλω « jetez en avant, mettez devant vous ; blâmer".
Cela n’a pas beaucoup de sens, en fait, « problème » = « tout ce qui doit être réglé ».
- un spécialiste (nous ne le diviserons pas en types, puisque nous nous intéressons à tous les testeurs) qui participe au test d'un composant ou d'un système dont le résultat est :
— un ensemble d'activités liées aux tests.
(lat. effectivus) - la relation entre le résultat obtenu et les ressources utilisées (: 2015).
- une conséquence d'une chaîne (série) d'actions (résultat) ou d'événements, exprimée qualitativement ou quantitativement. Les résultats possibles incluent l’avantage, le désavantage, le gain, la perte, la valeur et la victoire.
Comme pour le « problème », il n’a que peu de sens : quelque chose qui est né du travail.
- la possibilité quantitativement mesurable d'exercer toute activité d'une ou plusieurs personnes ; conditions qui permettent d'utiliser certaines transformations pour obtenir le résultat souhaité. Le testeur est une personne, et conformément à la théorie des ressources vitales, chaque personne est propriétaire de quatre actifs économiques :
l'argent liquide (le revenu) est une ressource renouvelable ;
l'énergie (force vitale) est une ressource partiellement renouvelable ;
le temps est une ressource fixe et fondamentalement non renouvelable ;
la connaissance (information) est une ressource renouvelable, elle fait partie du capital humain qui peut croître et être détruite.
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é est faible. Par conséquent, je redéfinirais l’efficacité comme « le rapport entre les résultats obtenus et les ressources dépensées ». Alors tout est correct : les connaissances ne sont pas gaspillées pendant le travail, mais cela réduit les coûts de la seule ressource fondamentalement non renouvelable du testeur : son temps.
décision
Nous recherchons donc des problèmes globaux de testeurs qui nuisent à l'efficacité de leur travail.
La ressource la plus importante consacrée au travail d'un testeur est son temps (le reste peut y être réduit d'une manière ou d'une autre), et pour que nous puissions parler du calcul correct de l'efficacité, le résultat doit également être réduit au temps .
Pour ce faire, considérons un système dont le testeur assure la viabilité par son travail. 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 :
- Travailler avec des exigences
- Formation des spécifications techniques
- Développement
- Test
- Mise en production
- Assistance (aller au point 1)
Dans ce cas, l’ensemble du projet peut être divisé de manière récursive en sous-projets (fonctionnalités), avec le même cycle de vie.
Du point de vue du projet, moins on y consacre de temps, plus sa mise en œuvre est efficace.
Ainsi, nous arrivons à la définition de 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. Un problème commun à tous les testeurs est l’incapacité à atteindre ce délai.
Comment gérer cela?
Les conclusions sont assez évidentes et sont utilisées par beaucoup depuis longtemps :
- Le développement et les tests doivent commencer et se terminer presque simultanément (cela est généralement effectué par le département). ). L'option idéale est lorsque toutes les fonctionnalités en cours de développement sont déjà couvertes par des autotests au moment où elles sont prêtes, organisées en tests de régression (et, si possible, de pré-validation) utilisant une sorte de .
- Plus un projet possède de fonctionnalités (plus il est complexe), plus il faudra passer du temps à vérifier que la nouvelle fonctionnalité ne casse pas l'ancienne. Par conséquent, plus le projet est complexe, plus l’automatisation est nécessaire. .
- Chaque fois que nous manquons un bug en production et qu'un utilisateur le trouve, nous devons consacrer plus de temps à parcourir le cycle de vie du projet à partir du point 1 (Travailler avec les exigences, dans ce cas, les utilisateurs). Étant donné que les raisons pour lesquelles un bug manque sont généralement inconnues, il ne nous reste qu'une seule voie d'optimisation : chaque bug trouvé par les utilisateurs doit être inclus dans les tests de régression pour être sûr qu'il n'apparaîtra plus.
Source: habr.com