Test & Validation web

Cas d'usage

• Auditer une application SaaS avant une mise en production
• Effectuer une revue qualité complète d'un site client
• Documenter les bugs et observations d'un sprint de test
• Générer un rapport QA structuré avec preuves et priorités

# Kalinotes – Test & Validation d'application web

Effectue un audit qualité complet d'un site web ou d'une application SaaS : navigue entre les pages, teste les fonctionnalités et crée des notes Kalinotes structurées pour chaque observation.

## Prérequis MCP

Ce skill utilise les outils MCP suivants : `list_projects`, `create_project`, `list_categories`, `create_category`, `create_note`, `create_comment`.

## Phase 1 — Initialisation

### 1.1 Collecte du contexte
Demande à l'utilisateur :
- **URL de base** de l'application à tester (ex: `https://app.exemple.com`)
- **Credentials** de test si l'app requiert une authentification (email, mot de passe)
- **Scope** : pages spécifiques à auditer ou audit complet
- **Projet Kalinotes** existant à utiliser, ou créer un nouveau ?
- **Profil de test** : rapide (pages principales), standard (flux complets) ou exhaustif

### 1.2 Création du projet
Si aucun projet n'est désigné, appelle `create_project` :
```
name: "QA – [Nom du site] – JJ/MM/AAAA"
description: "Audit de [URL] — [scope]"
```

### 1.3 Création des catégories
Appelle `list_categories` pour vérifier les catégories existantes. Crée celles qui manquent avec `create_category` :

| Catégorie | Couleur suggérée | Usage |
|---|---|---|
| 🐛 Bug | #DC2626 | Dysfonctionnements, erreurs, crashes |
| 🎨 UX / Interface | #7C3AED | Problèmes d'ergonomie, design, wording |
| ⚡ Performance | #D97706 | Lenteurs, timeouts, chargements |
| 🔒 Sécurité | #B91C1C | Failles potentielles, données exposées |
| ♿ Accessibilité | #059669 | Contraste, navigation clavier, ARIA |
| 💡 Suggestion | #2563EB | Améliorations, bonnes pratiques |
| ✅ Conforme | #16A34A | Fonctionnalités validées, positif |

## Phase 2 — Découverte

### 2.1 Analyse de la page d'accueil
Utilise `WebFetch` pour charger l'URL de base. Analyse :
- Structure de navigation (menu, liens principaux)
- Pages et sections identifiées
- Technologies détectées (framework, CMS…)
- Construis une liste des URLs à tester

### 2.2 Cartographie des flux
Identifie les flux critiques à tester :
- **Authentification** : inscription, connexion, déconnexion, mot de passe oublié
- **CRUD principal** : création, lecture, modification, suppression de l'entité centrale
- **Paiement / onboarding** (si applicable)
- **Profil / paramètres** utilisateur
- **Pages publiques** : accueil, landing, tarifs, contact

## Phase 3 — Tests page par page

Pour chaque page ou fonctionnalité, effectue ces vérifications avec `WebFetch` :

### Checks fonctionnels
- [ ] La page se charge sans erreur (pas de 404, 500, timeout)
- [ ] Tous les liens internes fonctionnent
- [ ] Les formulaires ont des labels, validations et messages d'erreur clairs
- [ ] Les actions CRUD (si présentes) fonctionnent correctement
- [ ] Les cas limites sont gérés (champ vide, valeur trop longue, caractères spéciaux)

### Checks UX / Interface
- [ ] Titre de page cohérent avec le contenu
- [ ] Messages d'erreur compréhensibles par un non-technicien
- [ ] Responsive / mobile (si applicable)
- [ ] Cohérence visuelle avec le reste de l'application
- [ ] Wording clair et sans fautes

### Checks performance
- [ ] Temps de chargement acceptable (< 3s en conditions normales)
- [ ] Pas de ressources bloquantes identifiables
- [ ] Images optimisées (pas de formats non compressés)

### Checks sécurité basiques
- [ ] Pas de données sensibles dans les URLs (tokens, passwords)
- [ ] Headers de sécurité présents (HTTPS, pas de mixed content)
- [ ] Pages protégées inaccessibles sans auth

### Checks accessibilité
- [ ] Contraste de texte suffisant
- [ ] Images avec attribut `alt`
- [ ] Navigation logique sans JavaScript

## Phase 4 — Création des notes

Pour **chaque observation** (bug, problème UX, amélioration), appelle `create_note` :

```
project_id: [ID du projet QA]
url:        [URL de la page concernée — OBLIGATOIRE]
title:      "[Catégorie] – [Description courte du problème en 6-8 mots]"
context:    "[Résumé en 1-2 phrases de l'observation]"
comment:    [Description détaillée en markdown — voir format ci-dessous]
category_id: [ID de la catégorie appropriée]
state:      NEW (pour bugs et blocants), TODO (pour améliorations)
priority:   URGENT (blocant), IMPORTANT (majeur), NORMAL (mineur), LOW (cosmétique)
```

### Format du commentaire de note

```markdown
## Observation
[Description précise de ce qui a été observé]

## Étapes pour reproduire (si bug)
1. Aller sur [URL]
2. [Action 1]
3. [Action 2]
→ Résultat : [ce qui se passe]
→ Attendu : [ce qui devrait se passer]

## Impact utilisateur
[Impact concret sur l'expérience ou l'activité]

## Suggestion de correction
[Recommandation si applicable]
```

### Utilise `create_comment` pour
- Ajouter des variantes ou cas limites découverts après la note principale
- Documenter le contexte navigateur/OS si pertinent
- Préciser les conditions d'apparition d'un bug intermittent

## Phase 5 — Rapport de synthèse

À la fin de l'audit, crée une note de synthèse :

```
title:   "QA – Synthèse de l'audit – [Nom du site]"
category: [créer une catégorie "📊 Résumé" si nécessaire]
state:   DONE
```

```markdown
# Synthèse de l'audit QA — [Nom du site]

**Date :** JJ/MM/AAAA
**Scope :** [pages testées]
**Durée :** [temps d'audit estimé]

## Résumé par catégorie

| Catégorie | Nombre |
|---|---|
| 🐛 Bugs | N |
| 🎨 UX / Interface | N |
| ⚡ Performance | N |
| 🔒 Sécurité | N |
| ♿ Accessibilité | N |
| 💡 Suggestions | N |
| ✅ Conformes | N |

## Points critiques (URGENT / IMPORTANT)
- [Note ID] [Titre du problème majeur]
- ...

## Points positifs
- [Ce qui fonctionne bien]

## Recommandations prioritaires
1. [Action prioritaire 1]
2. [Action prioritaire 2]
3. [Action prioritaire 3]

## Couverture des tests
[Pages testées vs pages identifiées, fonctionnalités couvertes]
```