Guide d'assurance qualité logicielle

Assurance qualité

L'assurance qualité (communément appelée QA) est le moyen par lequel un produit en développement est vérifié pour s'assurer qu'il fonctionne comme prévu. Les méthodes réelles utilisées dans les processus d'assurance qualité varient énormément en fonction de la taille et de la nature du produit.

Pour un projet personnel, vous allez probablement simplement tester au fur et à mesure, en demandant aux autres de fournir des commentaires aux étapes appropriées. En revanche, une application bancaire doit avoir tous les aspects de chaque fonctionnalité vérifiés et documentés de manière exhaustive pour s'assurer qu'elle est à la fois fonctionnelle et sûre.

Indépendamment du degré de formalité ou de détail d'un processus d'assurance qualité, son objectif est d'identifier les bogues afin qu'ils puissent être résolus avant la sortie du produit.

Méthodologies

Agile

Dans une approche Agile du développement, l'objectif est que chaque cycle de travail («sprint») produise un logiciel de travail qui peut être ajouté et amélioré de manière itérative. Cela fait des processus d'assurance qualité une partie intrinsèque du cycle de développement.

En testant les composants logiciels à chaque étape de leur production, vous réduisez le risque de présence de bogues à la sortie.

Terminologie

Test d'automatisation

Tests réalisés avec des scripts pré-écrits conçus pour contrôler l'exécution des tests.

Boîte noire

Ces tests ne regardent pas à l'intérieur du système testé, mais le traitent comme «fermé» de la même manière que l'utilisateur final en fera l'expérience.

Défaut

Tout écart par rapport aux spécifications d'une application; souvent appelé «bug».

Essais exploratoires

Une approche non scénarisée des tests, qui s'appuie sur la créativité unique du testeur dans un effort pour trouver des bogues inconnus et identifier les régressions.

Test d'intégration

Tester des composants / modules individuels ensemble pour s'assurer qu'ils se connectent et interagissent bien les uns avec les autres.

Test de chemin négatif

Un scénario de test conçu pour produire un état d'erreur dans une fonctionnalité / application et vérifier que l'erreur est gérée correctement. Un exemple de ceci est la saisie d'une série de chiffres dans le champ de courrier électronique dans un formulaire d'inscription d'utilisateur et la vérification pour s'assurer que l'enregistrement n'est pas accepté tant qu'une adresse électronique réelle n'est pas fournie.

Les tests de régression

Test effectué sur une nouvelle version pour s'assurer que la nouvelle fonctionnalité n'a pas accidentellement interrompu la fonctionnalité testée précédemment.

Tests de fumée

Une approche minimaliste des tests destinée à garantir que les fonctionnalités de base fonctionnent avant que des tests plus approfondis aient lieu. Se produit généralement au début du processus de test.

Cas de test

Conditions préalables, étapes et résultats attendus spécifiés auxquels un testeur / ingénieur QA fait référence pour déterminer si une fonction exécute sa tâche comme prévu.

Boîte blanche

Fait référence aux tests effectués au niveau structurel, dans la base de code. Les programmeurs vérifiant que les entrées et les sorties de fonctions ou de composants spécifiques seraient des tests en boîte blanche.

Aussi connu sous le nom de «Glass Box», «Clear Box», «Transparent Box» car le testeur peut «voir à l'intérieur» du système testé.

Les principales catégories sont

  • Tests unitaires (des unités de code individuelles font ce qu'elles devraient)
  • Tests d'intégration (les unités / composants interagissent correctement les uns avec les autres)
  • Tests de régression (réappliquer les tests à des stades ultérieurs de développement pour s'assurer qu'ils fonctionnent toujours)

Il existe trois techniques principales:

  • Partitionnement d'équivalence (les valeurs d'entrée testées sont représentatives d'ensembles de données d'entrée plus grands)
  • Analyse de la valeur limite (le système est testé avec des entrées choisies où le comportement et donc la sortie devraient changer)
  • Représentation graphique cause-effet (les tests sont conçus à partir d'une visualisation des relations entrée-sortie)

Autres ressources

  • Comment rédiger une documentation d'assurance qualité qui fonctionne réellement
  • Développement piloté par les tests
  • Tests unitaires