Présentation
Bonjour, résidents de Khabrovsk. Ici, je résolvais une tâche de test pour le poste de responsable QA pour une entreprise de technologie financière. La première tâche, pour é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, est trivialement résolue:
Mais la deuxième partie s'est avérée être une question: «Existe-t-il des problèmes communs à tous les testeurs qui interfèrent avec un travail plus efficace?».
La première chose qui m'est venue à l'esprit était d'énumérer tous les problèmes plus ou moins visibles que j'ai rencontrés lors des tests, d'éliminer les petites choses et de généraliser le reste. Mais il s'est vite rendu compte que la méthode inductive répondrait à une question relative non pas à «tout le monde», mais, au mieux, à la «majorité» des testeurs. J'ai donc décidé d'approcher de l'autre côté, déductif, et c'est ce qui s'est passé.
Définitions
La première chose que je fais habituellement lors de la résolution d'une nouvelle tâche est d'essayer de comprendre de quoi il s'agit, et pour cela, vous devez comprendre le sens des mots qu'elle pose. Les mots clés à comprendre sont les suivants:
- le problème
- testeur
- travail de testeur
- performances du testeur
Tournez-vous vers wikipedia et le bon sens:
Le problème (dr. Grec πρόβλημα) au sens large est une question théorique ou pratique complexe nécessitant étude, résolution; en science - une situation contradictoire, agissant sous la forme de positions opposées dans l'explication de tout phénomène, objet, processus et nécessitant une théorie adéquate pour le résoudre; dans la vie, le problème est formulé d'une manière que les gens comprennent: "Je sais quoi, je ne sais pas comment", c'est-à-dire que nous savons ce qui doit être reçu, mais on ne sait pas comment le faire. Vient de la fin lat problēma, du grec πρόβλημα "projeté en avant, placé devant"; de προβάλλω “jetez en avant, mis devant vous; blâme. "
Il n'y a pas beaucoup de sens, en fait, «problème» = «quoi que ce soit à régler».
Tester est un spécialiste (nous ne nous diviserons pas en types, car nous nous intéressons à tous les testeurs), qui participe au test d'un composant ou d'un système dont le résultat est:
Le travail du testeur est un ensemble d'activités liées aux tests.
Efficience (lat. Effectivus ) - le rapport entre le résultat obtenu et les ressources utilisées ( ISO 9000 : 2015).
Un résultat est la conséquence d'une chaîne (séquence) d'actions (totales) ou d'événements exprimés qualitativement ou quantitativement. Les résultats possibles incluent l'avantage, les inconvénients, le gain, la perte, la valeur et la victoire.
Comme pour le «problème», cela n'a pas de sens: quelque chose qui est survenu à la suite du travail.
Ressource - capacité mesurée quantitativement d'exécuter toute activité d'une ou de plusieurs personnes; conditions permettant d'utiliser certaines transformations pour obtenir le résultat souhaité. Un testeur est une personne, et conformément à la théorie des ressources vitales, chaque personne est propriétaire de quatre actifs économiques:
trésorerie (revenu) - une ressource renouvelable;
énergie (vitalité) - une ressource partiellement renouvelable;
le temps - une ressource fixe et fondamentalement non renouvelable;
connaissance (information) - une ressource renouvelable, elle fait partie du capital humain, qui peut croître et s'effondrer [1] .
Je tiens à noter que la définition de l'efficacité dans notre cas n'est pas entièrement correcte, car plus nous utilisons de connaissances, plus l'efficacité est faible. Par conséquent, je redéfinirais l'efficacité comme «le rapport entre le résultat obtenu et les ressources dépensées». Alors tout est correct: les connaissances au travail ne sont pas gaspillées, mais réduisent le coût de la seule ressource fondamentalement non renouvelable du testeur - son temps.
Solution
Nous recherchons donc des problèmes globaux de testeurs qui aggravent l'efficacité de leur travail.
La ressource la plus importante qui est consacrée au travail du testeur est son temps (le reste peut lui être apporté d'une manière ou d'une autre), et pour que nous puissions parler du calcul correct de l'efficacité, nous devons apporter le résultat à temps.
Pour ce faire, considérons un système dont le testeur assure la viabilité avec son travail. Un tel système est un projet dont l'équipe comprend un testeur. Le cycle de vie du projet peut être approximativement représenté par l'algorithme suivant:
- Travailler avec des exigences
- Formation de spécifications techniques
- Développement
- Test
- Mise en production
- Assistance (allez à p.1)
De plus, l'ensemble du projet peut être récursivement divisé en sous-projets (fonctionnalités), avec 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 l'on y consacre moins de temps.
Ainsi, nous arrivons à la détermination de l'efficacité maximale possible du 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 temps.
Comment y faire face?
Les conclusions sont assez évidentes et ont longtemps été utilisées par beaucoup:
- Le développement et les tests doivent commencer et se terminer presque simultanément (cela est généralement effectué par le service AQ ). L'option idéale est lorsque toutes les fonctionnalités développées au moment où elles sont prêtes sont déjà couvertes par des autotests organisés en tests de régression (et, si possible, de pré-validation) à l'aide de certains CI .
- Plus il y a de fonctionnalités dans le projet (plus c'est compliqué), plus vous devrez passer de temps à vérifier que la nouvelle fonctionnalité n'a pas cassé l'ancienne. Par conséquent, plus le projet est complexe, plus l'automatisation des tests de régression est nécessaire.
- Chaque fois que nous ignorons un bogue en production et que l'utilisateur le trouve, nous devons passer du temps supplémentaire à parcourir le cycle de vie du projet à partir de l'étape 1 (Travailler avec les exigences, dans ce cas, les utilisateurs). Étant donné que les raisons de manquer un bogue sont généralement inconnues, nous n'avons qu'une seule façon d'optimiser - chaque bogue trouvé par les utilisateurs doit être inclus dans les tests de régression pour s'assurer qu'il ne réapparaît pas.