Validation de logiciel

1. Validation de logiciel

2. Sommaire • Pourquoi et comment valider un logiciel • Déroulement d’une campagne de test • Typologies de validation • Cycle de vie d’une anomalie • Outils pour la validation Exemples

3. Pourquoi valider un logiciel • Vérifier le bon fonctionnement • Avant livraison au client (coté MOE) • Avant mise en production (coté MOA) • Connaître techniquement le logiciel • Combien d’utilisateurs simultanés ? • Quel temps de réponse ? • Sur quelle configuration l’installer ?

4. Du cahier des charges aux anomalies Cahier des charges Analyse du cahier des charges v3 v1 a a a a Exigencesfonctionnelles& techniques Cas de tests b b b b c c c c Spec. générales d d d d e e e e f f f f Spec. détaillées h h h h i i i i Stratégie detests Campagne detest #1 Anomalies Campagne detest Campagnes detest #3

5. Du cahier des charges à la validation Ce que l’architecte à conçu Ce que le client a expliqué Ce que l’analyste à spécifié

6. Ce que le client va recetter Ce que le développeur a fait Ce que le testeur va valider

7. Responsabilité • Le développeur est responsable du • développement • de la correction des anomalies • Le validateur est responsable • du bon fonctionnement du logiciel • de la vérification de la correction des anomalies • C'est le valideur qui est en faute si le logiciel livré ne fonctionne pas • Il doit préciser pour chaque version testée • La liste des fonctionnalités non testées • La liste des anomalies connues et non corrigées • L'infrastructure matérielle et système utilisée pour les tests

8. Démarches de projets Cycle en V Cycle en itérarif

9. Exigences • Définir les exigences à partir du cahier des charges • Identifier chaque exigence avec un numéro unique. • Exemple : • Format “<categorie>_<numero>” • Exemple de catégories: • IHM Interface Home Machine; FON Fonctionel • PER Performance; DES Design; CU Casd’Utilisation • IMP Implementation; LIV Livraison; ORG Organisationprojet • Les exigences doivent être MUST (Mesurable, Utile, Simple, Traçable)

10. Exemple d'exigences • [IMP_33210]Le logiciel doit être performant • Cette éxigencen'est pas assezclaire : Que veux dire performant ? • quel temps de réponse pour quelle fonctionnalité du logiciel ? • Avec combien d'utilisateurs et de transactions simultanées ? • Sur quelles machines serveur, client, et quelle bande passante réseau ? • [FON_33220]L'IHM du logiciel doit être en anglais et en francais • Plusieurs exigences en une, à remplacer par : • [FON_33221] L'IHM du logiciel doit être disponible en anglais • [FON_33222] L'IHM du logiciel doit être disponible en français • [FON_33223] L'utilisateur peut changer de langue dans l'IHM, par défaut la langue fournie par le navigateur web est utilisée

11. Description d’un cas de test • Titre du test • Moyens nécessaires aux tests • Compte utilisateur/mot de passe, • données en base • Systèmes externes, • Bouchons ou simulateur • Machines, réseaux/proxy • Etapes du test :

12. Organisation des cas de tests • Au moins un cas de test par exigence • Cas nominal (normal) • Cas particulier • Cas aux limites • Rattacher chaque cas de test à au moins une exigences • Suivre le modèle de description des cas de test ci-avant • Ajouter des étapes pour faciliter le déroulement de cas de test complexes

13. Préparer une validation • Définir une stratégie de validation dans le cadre du projet • Moyens mis en oeuvre (humain, outils, normes), • Planning de développement du logiciel • Définir le nombre de campagnes de test avec pour chacune d’elles • l’objectif de la campagne de test • la version testée et son périmètre fonctionnel • Identifier les moyens nécessaires aux tests • Equipe de validation, de développement, • Environnements, • Jeux de données, • Simulateurs

14. Déroulement d’une campagne de tests • Préparation • Définir la liste des cas de tests • Ordonner les cas de tests : priorités, dépendances • Préparer l'environnement : serveur, jeux de données, simulateur • Répartir des cas de tests entre testeurs : validation croisée • Bilan quotidien • Nouvelles anomalies trouvées : priorisation, • Nouvelle version avec correctifs apportés • Finir la campagne de tests • Liste des cas de tests OK/KO/non passés • Liste des anomalies non corrigées • Décision de fin de campagne de tests

15. Déroulement d’un projet Importance de la gestion de configuration 2 itérations : V1 et V2 2 équipes : dev. & valid. Exigences V2_rc1 V1_rc1 Bugfix v1 / Dev. v2 Bugfix v2 Dev. v1 v1 a a a V1_rc2 V2_rc2 b b b bug bug c c Valid. v1 d d Prepa.valid. v1 Valid. v2 Prepa.valid. v2 e e e f f h h i i

16. Environnements d’un projet MOE • Développement(s) • Intégration • Validation MOA • Recette fonctionnelle • Pré-Production • Production

17. Description d’une anomalie Versions • Bloquante : pas de livraison sans correction • Majeure : fonctionnalité secondaire ou solution de contournement • Mineure : autres anomalies

18. Cycle de vie d’une anomalie

19. Typologies de validation • Tests unitaires • Plus une anomalie est découverte tard plus elle coute cher • Validation fonctionnelle • Vérification de chaque exigence du cahier des charges • Ne revalider manuellement que les fonctions impactées par une nouvelle version • Tests automatiques • Permet l’amélioration continue sans craindre les régressions • Exploitabilité • Arrêt, redémarrage, surveillance, sauvegarde • Robustesse : purge, mode dégradé • Sécurité : durcissement, intégrité, confidentialité • Performances : nombre utilisateur maxi vs processeur/mémoire • Migrations de données • Bascule de système

20. Outils pour la validation • de gestion des tests • QualityCenter, SquashTM, Excel, Selenium, • de gestion des anomalies • JIRA, BugZilla, Mantis,QualityCenter, Trac, Redmine, • de gestion de configuration • Git, SubVersion, CVS, SourceSafe • de campagne de performance • JMeter, the Grinder, commande linux: top, ps, etc. • d’analyse de code • qualité : PMD, Qa-C • exécution : TPTP

21. Questions ?