Pour commencer, parmi les gens, tous les ingénieurs d'assurance qualité («à notre manière», les ingénieurs du service qualité) sont appelés testeurs. Ce n'est pas tout à fait correct, en réalité, les tests ne sont qu'une partie des tâches d'AQ, mais qui s'en soucierait. Par conséquent, allons dans la tendance générale et nous utiliserons le lecteur habituel pour tous.
Alors, qu'est-ce qui détermine un bon testeur? Nous ne nous pencherons pas sur les platitudes et dirons: attention, persévérance, patience, curiosité, talent, tout rompre et autres bêtises. C'est tout, bien sûr, important, mais pas l'essentiel. Tout d'abord, une personne doit avoir le sens commun et la responsabilité.
Par exemple, disent-ils, l'essentiel est d'avoir le talent pour tout casser. Souvent, vous pouvez entendre, ils disent qu'il ne ramassera pas, cassera tout. Bien sûr, cela est louable, mais le travail du testeur n'est pas la chose principale pour casser quelque chose. Ici, une définition viendra à notre aide, ce qui n'est pas difficile à trouver sur Wikipédia.
Le test de logiciel est le processus de recherche, de test d'un produit logiciel, dans le but de vérifier la correspondance entre le comportement réel du programme et son comportement attendu sur un ensemble fini de tests sélectionnés d'une certaine manière.
Cela montre qu'il existe des exigences spécifiques pour le logiciel et qu'il est nécessaire qu'elles soient respectées. Si le testeur a interrompu le programme au lieu de vérifier s'il remplit les fonctions qui lui sont attribuées, il peut en conséquence obtenir des ordures stables, mais pas nécessaires, pour le client.
Je comprends que tout le monde aime les histoires, comment quelqu'un a foiré, je les ai. Pour mon travail, j'ai travaillé dans différents endroits et sur différents projets, j'ai donc été témoin moi-même ou j'ai entendu de nombreuses histoires de mes collègues. Certains d'entre eux sont prêts à le dire. Eh bien et oui, le mantra nécessaire: toutes les coïncidences sont aléatoires, et les noms sont inventés.
Tests et plus
Commençons dans l'ordre. Comme je l'ai dit au début, le testeur ne fait pas que tester. Comment aimez-vous un tel jeu de mots? Dans les grandes entreprises réputées, ils essaient de connecter l'équipe de test au projet à un stade précoce, c'est-à-dire au stade de la collecte des exigences, mais cela ne se fait pas partout et pas toujours.
Une fois pendant le test d'acceptation, l'utilisateur a commencé un bogue critique, car l'une des conditions n'était pas remplie. L'essence de la réclamation était que l'utilisateur à l'écran n'a pas trouvé l'attribut dont il avait besoin (pour ceux dans le réservoir - un champ avec une valeur). Le testeur, bien sûr, est entré dans la spécification, a vérifié que cet attribut était présent dans l'application et a couru joyeusement pour dire à l'utilisateur que tout allait bien.
Vous comprenez déjà que l'histoire ne s'arrête pas là.
Le testeur a tenté d'expliquer à l'utilisateur dans quoi il s'était trompé, après avoir rencontré une part de négativité et d'indignation. L'utilisateur l'a assis et a découvert les exigences sur la base desquelles les spécifications ont été écrites. L'une de ces exigences se lit presque littéralement comme suit: "L'attribut doit être affiché sur chaque écran." Une phrase, mais quel sens! Puis il a ouvert l'application et a commencé à naviguer au hasard sur différents écrans en disant: "Et où est cet attribut?" Il est clair que l'utilisateur s'est ouvertement moqué, mais formellement il avait le droit de le faire. Le problème est que l'escalade s'est poursuivie et de plus en plus de personnes ont participé à la discussion du problème. À la fin de l'utilisateur, outre le testeur lui-même, plusieurs PM et une foule d'analystes l'ont convaincu, et il était catégorique et exigeait l'impossible.
En conséquence, un compromis a été trouvé et, dans la demande, une liste des écrans nécessaires sur lesquels l'attribut devait se trouver est apparue, mais cela a nécessité de grandes modifications dans le code du programme.Par conséquent, tout le cycle de développement a dû être réexécuté, mais à un rythme accéléré. L'entreprise a dépensé de l'argent supplémentaire, sans parler des coûts de réputation, pour le stress et le traitement des employés. Tout cela aurait pu être évité si le testeur avait été connecté au début du projet et qu'il pouvait voir les exigences d'ambiguïté - au moins, ou plus tard, pour vérifier la conformité des spécifications avec les exigences. Et oui, les testeurs travaillent souvent directement avec de vrais utilisateurs, ce qui les oblige à gérer la réduction du stress, la psychanalyse et la perception extrasensorielle.
Pas de fanatisme
On va plus loin, très ironiquement, le processus de test lui-même est caractérisé par une anecdote barbue:
Une fois que le testeur entre dans la barre.
Coure dans le bar.
Se glisse dans le bar.
Dansant, pénètre le bar.
Se faufiler dans un bar.
Pénètre dans le bar.
Saute à la barre.
Commandes:
une chope de bière
2 verres de bière
0 verres de bière
999999999 chopes de bière,
lézard dans un verre
-1 tasse de bière
chopes à bière qwerty.
Le premier vrai client entre dans le bar et demande où sont les toilettes. Le bar s'enflamme, tout le monde meurt.
Tout le monde ne comprend pas que vous pouvez tester sans fin. L'idéal est inaccessible et les projets ont des délais très précis dans lesquels s'insérer. Donc, il y avait un testeur qui, en passant le test, échoue constamment. Le temps a passé, le projet avait déjà commencé à se terminer et le développeur a surmonté tous les problèmes rencontrés. Et ici, le testeur déclare que la fonctionnalité de base nécessaire ne fonctionne pas. Tout le monde comprend: cela ne fonctionnera pas pour le réparer à temps.
Au cours de la procédure, il s'avère: lors des tests, le script n'a jamais été complètement achevé jusqu'au moment malheureux. Le testeur a trouvé une faille au début du processus, qui a testé, commencé un ticket et jeté à mi-chemin. Dans le même temps, il a été possible de poursuivre les tests, car Toutes les erreurs trouvées ne l'ont pas bloqué. Par la suite, toute l'équipe a un stress et un traitement traditionnels.
Soit dit en passant, certains utilisateurs le commettent lors des tests d'acceptation, déclarent le bogue critique et quittent le travail. Cela complique grandement le travail, car dans le flux général de problèmes, qui ne sont généralement pas un problème, des bogues vraiment critiques sont perdus.
La morale est la suivante: un bon testeur n'arrêtera jamais de trouver le premier bug rencontré. Il parcourra l'intégralité du script du début à la fin, enregistrant simultanément tous les bogues trouvés, et s'il rencontre une erreur bloquant le passage, il recherchera une solution de contournement, c'est-à-dire solution de contournement. Et lorsqu'il est convaincu qu'il n'y a pas de solution de contournement, il s'arrête.
Il y a une mise en garde. Le plus souvent, les projets sont réalisés dans des délais serrés, ou pas très serrés, mais assez spécifiques. Il arrive qu'une personne soit pulvérisée sur des tests sans fin d'un champ, y introduisant toutes les variantes de valeurs possibles et impossibles. En même temps, selon les exigences du client, il est nécessaire de vérifier la fonction effectuée par l'application, bien qu'en utilisant la valeur de ce champ. En conséquence, il court le risque de perdre du temps et de ne pas vérifier l'essentiel. Le testeur doit être en mesure d'évaluer correctement ses points forts et les endroits critiques de l'application. Pas besoin de tester les endroits qui ne nécessitent pas de test. L'essentiel est que l'application doit remplir la fonction qui lui est assignée. Vous devez d'abord réaliser l'exécution d'un scénario direct, puis améliorer la qualité de l'exécution au niveau souhaité.
Ma langue est mon ennemie
De plus ... Les problèmes de documentation peuvent être non seulement pour les analystes, mais aussi pour les testeurs. Il a été noté à plusieurs reprises que non seulement les développeurs ne sont pas en mesure de décrire clairement le contenu du ticket dans son champ correspondant, mais que les testeurs eux-mêmes ne peuvent pas écrire correctement l'ordre des actions qui provoquent l'erreur. C'est un gros problème. Quelqu'un ne comprend tout simplement pas pourquoi l'erreur se produit et ne prend pas la peine de comprendre les étapes. Quelqu'un a des problèmes d'alphabétisation.
Qu'est-ce que tout cela implique? Ici, la réponse et le hérisson sont compréhensibles, mais avec les exemples, bien sûr, plus intéressants.
Il y a une cohorte de testeurs qui, voyant une erreur devant eux, enregistrent simplement ce million d'étapes, y compris la jonque qui a conduit au bug. Ils ne reproduisent pas l'erreur et ne savent pas exactement ce qui est causé. En même temps, ils peuvent noter un ensemble d'étapes qui ne sont pas du tout associées à cette erreur. Le développeur va essayer de se reproduire, à un moment donné sa tête va bouillir, et il ira traiter personnellement avec le testeur. Ils comprendront ensemble et passeront beaucoup de temps sur les communications inutiles. Heureusement, tout cela est rapidement traité par le temps et l'expérience, bien qu'il existe des cas cliniques.
L'alphabétisation devient plus difficile. Dans ma pratique, il y avait un cas où le responsable QA devait corriger la description de plusieurs dizaines de billets, car ils auraient dû être envoyés au client dans un rapport d'avancement. Cela s'est produit parce que la plupart de l'équipe n'a pas pu formuler correctement leurs pensées en anglais.
Mais il y a aussi des problèmes avec les Russes, Dieu merci, moins souvent. Tout est pareil ici, une description mal écrite conduit au fait que le ticket, comme un ballon de foot, commence à galoper entre les gens sans entrer dans le but. C'est bien si l'équipe est dans la même pièce et peut simplement parler sans se lever du moniteur. Plus difficile - si l'équipe est répartie. Très mauvais, si multilingue. La pire chose qui puisse arriver à la fin est que le ticket sera mal fait en raison d'un malentendu et sera rouvert mille fois. Et même pour le client s'envolera dans l'une des versions à logique inversée.
Espace personnel
Un autre problème concerne les bancs d'essai et les données d'essai. Dans différentes entreprises, cela se produit de différentes manières, mais il arrive souvent qu'un employé se voie octroyer des droits sur le serveur de travail d'un client ou reçoive sa base de données pour les tests. Il semblerait que ce qui pourrait mal tourner?
Mais dofiga de quoi ... Si quelqu'un a accès au serveur du client, d'une part c'est pratique, vous pouvez regarder les problèmes dès le premier rang et ne pas vous tromper sur la photo. Mais il existe un risque de détérioration des données du client, ce qui peut entraîner de graves conséquences. Je suis déjà silencieux sur les cas où un tel accès est généralement interdit par la loi.
Il y a eu un cas où un client est tombé d'un serveur pendant 3 jours. Le développeur pendant tout ce temps n'a pas pu comprendre pourquoi cela s'est produit et a recherché frénétiquement une erreur, et l'entreprise a subi des pertes. En conséquence, il s'est avéré: la société a engagé des Indiens pour externaliser, où le peuple, sans plus tarder, a donné tous les droits d'administrateur. Pour tout le monde - cela signifie même cette fille qui travaille depuis 3 jours dans l'entreprise, et il n'y avait pas d'ordinateur dans son village, donc ils ont une période de rencontre plus courte. Mais la fille s'est avérée terriblement talentueuse, elle a réussi à trouver l'essence de base dans le panneau d'administration et a changé de type, après quoi tout est tombé naturellement et a cessé de fonctionner. Il est facile de deviner comment elle a décroché l'échelle de carrière après cela.
Le même non-sens et avec les données du client. Encore une fois, je ne parle pas de cas où cela est interdit par la loi. S'il est possible de travailler sur des données réelles, c'est bien, mais il faut être prudent avec cela. Tout le monde a probablement entendu des histoires sur l'envoi aléatoire de lettres ou de messages d'un serveur de test à de vrais utilisateurs. Ce ne sont donc pas des blagues. Cela arrive vraiment, et assez souvent. Eh bien, si ces messages sont autorisés en tant que messages de test et ont un contenu sain, mais il arrive que les gens gonflent et écrivent ce que toute l'équipe de développement d'applications regrette.
Moments d'organisation
J'ai déjà commencé à m'ennuyer avec une abondance de texte, donc le dernier. Le testeur doit constamment fournir à son patron des informations à jour sur son travail. Selon de tels rapports, s'ils sont faits correctement, le chef tire une conclusion sur l'état du projet dans son ensemble. Non seulement sur le travail d'un testeur ou de toute l'équipe de test, mais aussi sur le travail de l'équipe de développement et de l'étape à laquelle le projet en est. De plus, ces rapports permettent de planifier l'analyse pour les versions futures, etc., etc.
Il existe de nombreux exemples où ce travail n'a pas été effectué ou a été effectué de manière inappropriée, d'où les autorités ont eu un sentiment d'incertitude avec toutes les conséquences qui en ont résulté. Je vais te dire le plus brillant.
Une fois le testeur mis sur un nouveau projet. Comme il ne le connaissait pas bien, il a été chargé de trier et d'enregistrer les observations. Comme c'était quelque chose d'informel, nous avons convenu que nous écririons dans Googledock. L'homme a commencé à effectuer la tâche, une semaine plus tard, cette tâche a été vérifiée, le testeur a été tapoté sur l'épaule et il a continué à travailler. Des mois ont passé, les autorités ont commencé à se demander pourquoi il n'y avait pas de tickets dans le bugtracker et rien n'est fait sur le projet. Nous avons commencé à comprendre, il s'est avéré qu'une personne continue d'écrire dans ce même Googledock. Personne n'a dit «Potty, ne cuisine pas» et n'a pas arrêté le testeur, et il a régulièrement continué à comprendre et à enregistrer les observations, sans se le faire savoir. Il y a des bogues, et il les a trouvés, mais il n'en a parlé à personne, mais il les a seulement écrits dans un fichier, que tout le monde a oublié une semaine plus tard.
En fait, on s'attendait à ce qu'une personne continue de travailler déjà de manière formelle, c'est-à-dire dans le bug tracker, donnant aux développeurs des tickets avec leurs tickets, mais cela ne s'est pas produit. Il semblait que l'homme n'a rien fait, bien qu'il ait travaillé. Il est clair que le problème n'était pas seulement de la part du testeur, mais s'il faisait un rapport régulier sur ses activités, les malentendus pourraient être évités.
Souvent, le manque d'informations crée le sentiment de mauvais tests de produit, que telle ou telle partie de la fonctionnalité n'a pas été testée. Pour éviter que cela ne se produise, vous devez créer des rapports détaillés, ce qui est particulièrement important pour les grands projets.
Conclusion
Vous devez comprendre que QA est en fait l'avocat de l'utilisateur. Dans toute situation incompréhensible liée à l'application, le testeur doit se mettre à sa place. Si, à travers cette simple manipulation de la conscience, il s'avère que l'application n'est pas satisfaite de quelque chose, alors vous devez commencer un ticket. Et cela peut être un bouton au mauvais endroit ou une autre bagatelle du point de vue du développeur, mais il arrive souvent que pour un utilisateur, cette bagatelle puisse devenir un enfer et un point d'irritation. À titre d'exemple, vous pouvez prendre un nombre sauvage de fenêtres contextuelles dans l'application. Oui, le programme remplit sa fonction, mais il est difficile de l'utiliser, car l'exécution de cette fonction prend beaucoup de temps et d'efforts à un utilisateur qui est obligé d'appuyer sur un tas de fenêtres supplémentaires avec des téléchargements et plus, au lieu de faire tout le travail sur un seul écran.
Et si une personne responsable et de bon sens s'approche de son travail, alors elle pourra éviter la plupart des problèmes sur son chemin, pas seulement dans la profession d'AQ.