Test d'erreur
Les tests d'erreur vérifient si un site Web ou une application fonctionne comme annoncé dans des scénarios réels. Le spécialiste ne se limite pas aux clics aléatoires : il prépare les conditions, parcourt les étapes de l’utilisateur, compare le résultat réel avec celui attendu et dresse un rapport de bug reproductible. Cette approche aide le développeur à trouver rapidement la cause et le client comprend quels défauts bloquent le paiement, l'inscription, l'envoi de formulaires ou d'autres actions critiques.
La vérification est utile avant la publication, après une mise à jour majeure, lors d'un transfert vers un autre serveur ou avant de diffuser une publicité. La portée doit être déterminée à l'avance : quels rôles, appareils, navigateurs, langues, méthodes de paiement et intégrations sont inclus dans le travail. Sans une matrice de test convenue, un projet peut facilement se transformer en une recherche sans fin de détails, tandis que des scénarios critiques peuvent rester sans réponse.
Quelles tâches peuvent être commandées
Pour le service Error Testing, le périmètre doit être décrit en termes de résultat attendu et de scénario testé. La tâche peut inclure des tests fonctionnels du site et de l'application, la vérification de l'enregistrement, la récupération de la connexion et de l'accès, le test des formulaires, des commandes et des paiements, les tests multi-navigateurs et adaptatifs et les tests des applications mobiles sur les appareils. Il est préférable de séparer chaque partie obligatoire des améliorations complémentaires, d'indiquer l'état initial et les critères de réalisation. Ensuite, le spécialiste évaluera la complexité sans hypothèses cachées et le client pourra accepter le travail sur la base du résultat réel et non de l'impression générale.
- tests fonctionnels du site et de l'application
- vérification de l'inscription, de la connexion et de la restauration de l'accès
- tester les formulaires, les commandes et les paiements
- Vérification multi-navigateurs et adaptative
- tester des applications mobiles sur des appareils
- vérifier les API et les intégrations
- test de régression après modifications
- préparer des rapports de bogues et des listes de contrôle
Ce qui est inclus dans le résultat
Le résultat du service « Test d'erreur » devrait être utile non seulement à l'interprète actuel, mais également au prochain membre de l'équipe. Par conséquent, nous avons besoin de statuts clairs, de preuves, de restrictions et d’un moyen de revérifier. Le tableau ci-dessous présente les points de contrôle. Si une partie du résultat dépend d'un service externe, d'une décision du client ou d'un équipement indisponible, une telle dépendance doit être notée à part, et non masquée dans un statut général.
| Scène | Résultat | Examen |
|---|---|---|
| Planification | Matrice de fonctions et d'environnements | Couverture convenue |
| Fumée | Vérification des fonctions clés | Aucun problème d'environnement bloquant |
| Essai | Rapports de bogues et preuves | Les défauts sont reproduits |
| Retester | État du correctif | Nouvelle version testée |
| Régression | Rapport final et risques | Scénarios critiques répétés |
Ce qu'il faut inclure dans les spécifications techniques
Les termes de référence pour les « tests de bogues » doivent inclure une référence à l'environnement de test et au numéro de build, des descriptions des rôles et des comptes de test, les scénarios d'utilisation attendus, les navigateurs, appareils et systèmes d'exploitation pris en charge, ainsi que les informations et restrictions de facturation des tests. Plus les données initiales sont précises, moins la correspondance et le rediagnostic prendront du temps. Les mots de passe, jetons, codes bancaires et autres secrets ne sont pas publiés dans la description ouverte. Une fois que vous avez sélectionné un spécialiste, il est plus sûr d'utiliser des comptes temporaires avec des droits minimaux et de les révoquer une fois le travail terminé.
- lien vers l'environnement de test et le numéro de build
- description des rôles et des comptes de test
- scénarios d'utilisation attendus
- navigateurs, appareils et systèmes d'exploitation pris en charge
- tester les données et les restrictions de paiement
- description de l'API et des intégrations externes
- problèmes connus et changements récents
- règles pour travailler avec des tests et des données personnelles
Ce qui est vérifié avant de commencer
Avant les actions actives, un spécialiste du service Error Testing vérifie les scénarios critiques et les points de défaillance, l'exactitude des droits des différents rôles, la validation des valeurs obligatoires et limites, les erreurs du réseau, du serveur et des API externes, ainsi que le comportement lors de la nouvelle demande ou de la mise à jour d'une page. L'enregistrement de l'état initial permet de distinguer un problème préexistant des conséquences des travaux et fournit une base de comparaison. Pour les données et systèmes critiques, la copie de sauvegarde, l'environnement de test, la fenêtre de modification acceptable et l'ordre de restauration sont convenus à l'avance. Sans cela, même une action technique appropriée peut créer des risques opérationnels inutiles.
- scénarios critiques et points de défaillance
- justesse des droits des différents rôles
- validation des valeurs obligatoires et limites
- erreurs de réseau, de serveur et d'API externe
- comportement lors de la nouvelle requête ou de l'actualisation d'une page
- stockage des données et état de la session
- afficher sur différents écrans et navigateurs
- logs, requêtes console et réseau en cas de défaut
Comment se passe le travail ?
Il est pratique de diviser le travail sur le service « Error Testing » en étapes successives. Tout d'abord, les exigences et les critères sont clarifiés, puis les données sont collectées, des tests ou ajustements de base sont effectués, les résultats sont enregistrés et une nouvelle inspection est effectuée. Après chaque étape importante, il est utile de sauvegarder une version du rapport, de l'assemblage ou de la configuration. Cela permet de détecter à temps une hypothèse erronée et de ne pas la reporter aux étapes suivantes.
- se mettre d’accord sur l’objectif, la portée et les critères d’acceptation
- préparer l’accès et un environnement de test sécurisé
- réparer l'état initial
- effectuer des diagnostics ou des contrôles de base
- formaliser les résultats et les priorités
- vérifier les modifications ou répéter le script
- transférer les matériaux et fermer les accès temporaires
Méthodes et exigences techniques
Un service de test d'erreurs de haute qualité n'utilise pas un ensemble aléatoire d'actions, mais des méthodes appropriées : scénarios positifs et négatifs, classes équivalentes et valeurs limites, vérification des états et des transitions, matrice multi-navigateurs et tests API par statut et schéma de réponse. La méthodologie doit prendre en compte les rôles, les appareils, les données, les intégrations et les contraintes du projet. Les résultats critiques sont basés sur un scénario reproductible, une mesure, un journal ou une exigence documentée. Une liste de contrôle universelle est utile comme base, mais ne remplace pas l’analyse du produit lui-même et de son public.
- scénarios positifs et négatifs
- classes équivalentes et valeurs limites
- vérifier les états et les transitions
- matrice multi-navigateurs
- Tests d'API par statuts et schéma de réponse
- vérifier l'idempotence des paiements et des opérations
- listes de contrôle reproductibles pour la régression
- séparation du défaut, de la demande de changement et du problème des exigences
Ce qui est transféré au client
Après avoir effectué des « tests d'erreur », le client reçoit un plan de test ou une liste de contrôle convenue, une matrice de navigateurs, d'appareils et de rôles, des rapports de bugs avec des étapes de reproduction, des résultats attendus et réels et des captures d'écran, des vidéos, des journaux ou HAR. Le format du résultat est convenu à l'avance : document, tableau, backlog, vidéo, fichiers sources ou une combinaison de formats. Il est nécessaire de déterminer quels éléments peuvent être transférés à des tiers et quelles données doivent être anonymisées. Le résultat ne doit pas dépendre du compte personnel de l’entrepreneur ni laisser un accès permanent caché au système du client.
- plan de test ou liste de contrôle convenue
- matrice de navigateurs, d'appareils et de rôles
- rapports de bogues avec étapes de repro
- résultat attendu et réel
- captures d'écran, vidéos, journaux ou HAR
- priorité et gravité du défaut
- état de la revérification du correctif
- rapport final sur la couverture et les risques restants
De quoi dépend le coût ?
Le coût du service Error Testing dépend de facteurs tels que le nombre de fonctions, de rôles et d'intégrations, le nombre de navigateurs, d'appareils et de versions de système d'exploitation, la complexité du paiement et des services externes, la disponibilité de la documentation de test et le volume de régression après corrections. Pour une évaluation précise, il est préférable de séparer le volume obligatoire des options supplémentaires. L'urgence, les sections privées, le nombre de rôles, les langues, les appareils et les recyclages ont souvent plus d'impact sur le budget que le nombre de pages publiques. L'entrepreneur doit indiquer ce qui est inclus dans le prix et comment la prolongation de la tâche initiale est payée.
- nombre de fonctions, de rôles et d'intégrations
- nombre de navigateurs, d'appareils et de versions de système d'exploitation
- complexité du paiement et des services externes
- disponibilité de la documentation de test
- volume de régression après corrections
- le besoin d'API et de contrôles de charge
- urgence de la version et nombre de cycles de retest
Comment choisir un spécialiste
Lors du choix d'un spécialiste pour le service « Bug Testing », évaluez l'expérience avec des produits d'un type similaire, la capacité à rédiger des rapports de bugs reproductibles, la connaissance des DevTools, des journaux et des requêtes réseau, la compréhension des parties client et serveur et la présence d'appareils réels ou d'une ferme cloud. Une évaluation globale du profil est importante, mais une expérience pertinente, des exemples de résultats et des questions préalables au démarrage montrent la compétence avec plus de précision. Un entrepreneur fiable ne promet pas l'impossible, explique les limites, répertorie à l'avance les données nécessaires et ne demande pas de droits d'accès excessifs sans raison technique.
- expérience avec des produits similaires
- capacité à rédiger des rapports de bogues reproductibles
- connaissance des DevTools, des logs et des requêtes réseau
- compréhension des parties client et serveur
- disponibilité d'appareils réels ou d'une ferme cloud
- capacité à évaluer la gravité sans surestimer
- Volonté de respecter la confidentialité et de tester les règles relatives aux données
Comment accepter le résultat
L'acceptation du service « Bug Testing » doit être effectuée selon une liste convenue : chaque bug est reproduit selon les étapes spécifiées, l'environnement et le numéro de build sont indiqués, le résultat attendu est basé sur l'exigence ou la logique convenue, les preuves ne contiennent pas de données personnelles inutiles et les doublons sont combinés et liés. La vérification est effectuée sur la version correcte, sous le rôle correct et dans le même script que celui spécifié dans la tâche. Les commentaires doivent faire référence à un résultat précis, et non à de nouveaux souhaits qui manquaient dans le périmètre initial. Des idées supplémentaires peuvent être complétées dans une étape distincte.
- chaque bug est reproduit selon les étapes spécifiées
- l'environnement et le numéro de build sont indiqués
- le résultat attendu est basé sur une exigence ou une logique convenue
- les preuves ne contiennent pas de données personnelles inutiles
- doublons fusionnés et liés
- les correctifs ont été testés sur la nouvelle version
- les scénarios critiques ont été régressés
- les risques restants sont clairement répertoriés
Limites et responsabilité
Les tests réduisent le risque de détection de défauts, mais ne prouvent pas l'absence absolue d'erreurs. Le nombre de combinaisons de données, d’appareils et de conditions environnementales est presque infini. Il est important que le client identifie les scénarios critiques et que le testeur enregistre la couverture, les limites environnementales et les zones non testées. Les tests de charge, les audits de sécurité et les tests de conformité sont convenus séparément.
Comment publier un devoir sur DitWork
Incluez le type de produit, le numéro de build, les scénarios critiques, les rôles, les navigateurs, les appareils et la date de sortie. Joignez les exigences ou la liste de contrôle, le cas échéant. Sur DitWork, vous pouvez sélectionner un testeur, convenir du format des rapports de bogues et déterminer à l'avance combien de cycles de tests de correctifs sont inclus dans le travail.
