Bonjour à tous!

Il se trouve que je fais partie de ce même service de contrôle de la qualité. Notre équipe a récemment écrit un gros reportage. Après avoir réfléchi un peu, j'ai décidé de créer une telle feuille de triche pour le front-end. Il vous rappellera à quoi vous devez faire attention avant de transférer la tâche vers le test.

Lorsque vous soumettez la version finale du produit au service de contrôle qualité, vous devez vous attendre à ce que le contrôle ne révèle aucun problème. Il serait extrêmement peu professionnel de passer un code sciemment défectueux au contrôle de la qualité. Et quel code est évidemment défectueux? Quiconque dont vous n'êtes pas sûr!

^{«Un programmeur idéal. Comment devenir un professionnel du développement logiciel »
Robert S. Martin}

Par où commencer?

Mise en page sur prototypes .

Il se trouve que les concepteurs sont de beaux elfes d'une haute tour et "ils voient les choses de cette façon". Et parfois, il est plus facile de le faire à sa façon que de suivre le prototype. Mais généralement, ces gars-là sont de notre côté, et tout en dessinant, ils tiennent à la tête (ou sur papier) quelques arguments pour expliquer pourquoi cela a été fait de cette manière. Et s'il semble que quelque chose d'étrange soit dessiné, vous pouvez toujours en discuter.

Si quelque chose est impossible (lire très cher) à faire - c'est ce que je dois dire. Très, très, très stupide de voir de nouveaux prototypes qui ne convergent pas avec la nouvelle tâche.


Trouvez N différences. Prototype à gauche.

Remplir et afficher des données

Tout va bien lorsque les informations du site sont statiques et inchangées. Vous pouvez voir dans une paire de navigateurs et plusieurs résolutions. Cela trouvera immédiatement des problèmes évidents et les corrigera avant le test.

Mais tout change quand ils sont - entrée .

Il est extrêmement nécessaire d'y entrer tout:

• Beaucoup de texte.
• Texte différent: lettres, chiffres, caractères spéciaux, etc.
• Petit texte. Puis-je saisir rien et à quoi ressemblera-t-il alors?
• Texte au mauvais format ou texte invalide.
• Pour le dessert: grandes lignes sans aucun espace.
• Lacunes: en tête et en queue.

À propos des espaces de début et de fin.

Ils ne sont pas nécessaires dans 99% des cas, sauf peut-être uniquement pour les mots de passe, mais cela est inexact. J'ai eu de l'expérience lorsque l'application s'est écrasée en raison d'un espace à la fin de la connexion. Il est resté après avoir copié la ligne du courrier. Alors: coupez les espaces !

La saisie de valeurs n'est que la moitié de l'histoire. En plus d'économiser, vous devez regarder l'écran. Par conséquent, nous vérifions l'apparence des données entrées précédemment: styles, décorations, mise en forme, etc. Tout peut aller.

Vérifiez tout de même:

• Grands textes, avec ou sans espaces.
• Textes avec sauts de ligne, paragraphes. Parfois j'insère des poèmes pour ça.
• L'ensemble de données minimum. Tout reste en place quand rien ou presque rien?
• L'affichage de tous les champs d'une entité complexe. Ils peuvent être vides.

Il y a quelques exemples vivants sous cat.

Validations

Parfois, vous ne pouvez pas simplement saisir et saisir ce que vous voulez - les validations fonctionnent.

Que faire

Nous regardons la liste des validations et pour chacune d'elles nous vérifions qu'elle jure. C'est-à-dire restrictions de longueur, caractères interdits, masque de saisie - tout cela doit être vérifié et assurez-vous que cela fonctionne.

Astuce: le texte peut également être saisi en copiant.

IE

Je comprends que la première réaction en est une.



Vous avez de la chance si vous avez peu d'utilisateurs de ce merveilleux navigateur. Mais sinon, hélas. Vous devrez regarder votre travail à travers le prisme de la perception alternative.

Mesures

C'est presque comme avec IE, mais ça ne fait pas de mal.

Si aucune mesure personnalisée n'est collectée sur votre projet, tout va bien. Sinon, vous devez faire deux choses:

• Accrochez toutes les métriques sur les actions requises. D'après mon expérience, les informations sur les métriques provenaient soit de l'analyse, soit des fournisseurs frontaux eux-mêmes au courant.
• Vérifiez que les bonnes mesures avec les bonnes données sont envoyées aux actions. Au moins sortie sur la console en mode dev.

Au lieu d'une conclusion

J'ai brièvement parlé de ce à quoi vous devez faire attention lorsque vous travaillez avec le front. Ces quelques vérifications vous permettront d'obtenir un produit nettement meilleur en sortie.

Je voudrais noter que l'article sera utile si vous n'avez pas du tout de testeur. Par conséquent, à la fin encore une fois un bref résumé:

• Mise en page sur prototypes.
• Entrez une variété de données: beaucoup, un peu, en un mot, n'entrez pas.
• Coupez les espaces.
• Vérifiez les validations.
• IE
• N'oubliez pas les métriques.

FAQ

Q: Les testeurs trouveront tout!
R: Pas tous. Les testeurs ne sont pas un filtre HEPA pour vous, mais des gens. Et si au stade du développement, quelqu'un n'a pas fait sa part de travail, il ne va nulle part, mais passe simplement à quelqu'un d'autre.

Rattrapé, mais n'a pas regardé? Ainsi, d'autres personnes travailleront avec cela, passeront non seulement du temps, mais aussi leurs forces. Une personne se fatigue, l'œil est emporté, la fatigue s'accumule. Et au-delà de l'arbre de ces problèmes, des choses plus graves peuvent être manquées.

N'oubliez pas non plus que tout jeu avec des tâches de ping-pong n'impose que des coûts de temps supplémentaires. Il faut encore terminer normalement. Mais la détection précoce des problèmes accélère l'ensemble du processus de développement.

Merci de votre attention.