Êtes-vous prêts à améliorer la qualité de vos logiciels ?
Améliorer votre assurance qualité et vos tests signifie également l’amélioration de votre
processus de développement.
Par
Vincent Siveton, conseiller
stratégique, Centre de tests et d'interopérabilité, CRIM
13 avril 2012
Dans le monde du développement logiciel, l’assurance qualité et les tests demeurent le parent
pauvre. D’un côté, les méthodes agiles progressent constamment en promettant une meilleure qualité
des produits, de l’autre côté, les méthodes traditionnelles comme Waterfall continuent à assurer
une qualité formelle.
Mais comment vraiment améliorer la qualité des logiciels développés par votre entreprise ? En
faisant une rétrospective de vos processus régulièrement.
Problématique
Les processus de développement logiciel ne tiennent pas assez compte de l’assurance qualité et
des tests. Il existe beaucoup de bonnes pratiques en développement, principalement basées sur des
normes. Ces pratiques peuvent être adoptées progressivement et appliquées à presque n’importe quel
projet ou processus, y compris lorsqu’il s’agit d‘approche formelle telle que CMMI ou
Waterfall.
Néanmoins, l’assurance qualité et les tests ne sont généralement pris en compte par les
entreprises que lorsqu’elles n’arrivent plus à satisfaire les besoins de ses clients.
La qualité du logiciel développé touche principalement trois aspects :
- Le système qualité qui touche l’ensemble de l’organisation, des responsabilités, des processus,
des procédures, des moyens et des techniques.
- Le logiciel qui doit répondre aux spécifications définis.
- Le processus de développement du logiciel.
Les entreprises pensent généralement à améliorer la qualité du logiciel en mettant en place des
tests, et plus rarement à se questionner sur les limites de leurs processus de développement : si
le processus actuel fonctionne, pourquoi le changer ?
Solution
Afin d’aider votre entreprise à réussir le développement de logiciels de qualité dans un délai
et à un coût permettant de générer des profits, il faudrait faire une rétrospective de deux
éléments : la partie organisationnelle et la partie technologique dans une optique d’aboutir à
l'objectif final : avoir un produit de qualité. Pour y parvenir, vous pouvez utiliser ou
adapter des normes comme ISO 9000 ou encore les normes élaborées par l’IEEE.
La direction devra fournir les ressources nécessaires à la mise en oeuvre des audits,
notamment avoir recours à un auditeur externe afin d’éviter tout risque de conflits,
interpersonnels ou autres. L’objet de l’audit peut porter sur toutes les activités ayant une
influence directe ou indirecte sur la qualité du logiciel élaboré. Après avoir procédé à l’audit et
l’inspection des documents concernés, entrevues avec les personnes impliquées, évaluation de
l'application des procédures et des instructions mises place, conformités avec les normes et les
exigences internes de l’entreprise, etc., l’équipe chargée de l’audit doit effectuer les activités
suivantes :
- Préparer le rapport de l’audit qui doit identifier les points à améliorer.
- Proposer un plan d’actions correctives à mettre en place échelonnés dans le temps.
L'entreprise devra par la suite exécuter les actions suivant un échéancier défini.
Gain
Les gains apportés par un audit se font à moyen et long terme mais rarement à court terme. Il
est important de se questionner régulièrement pour faire vivre le processus de développement d'un
logiciel avec les besoins des clients et de l'entreprise. Dans les méthodes agiles, cette
rétrospective se fait en fin de sprint et ce, de façon continue au cours du projet.
Ces rétrospectives permettront à l'entreprise :
- Accroître l'efficacité des employés.
- Assurer le savoir-faire tout en s’adaptant aux nouveaux besoins des clients.
- Réduire les coûts de développement et de production.
Alors, êtes-vous prêts à vous améliorer ?
Des commentaires ?
vincent.siveton@crim.ca
Preuve de concept : Pour réduire le risque
Par
Raymond Rivest, conseiller senior,
spécialiste de tests, Centre de tests et d'interopérabilité, CRIM - 15 mars 2012
Problématique :
Quand vient le temps de penser à effectuer des tests de performance afin d’évaluer
l'infrastructure qui sera requise pour la mise en services d’un système, le mot « Automatisation »
vient presque automatiquement à l’esprit. Qui dit « Automatisation » dit « Outils ». Quoi choisir ?
Comment choisir ? Combien ça coûte ? Combien de temps faut-il ? Ce sont les questions courantes qui
viennent à l’esprit dans ce genre de situation.
L’inconvénient principal est le nombre d’inconnus auxquels il faut faire face lorsqu’arrive ce
genre de projet. Le risque de dépassement de coûts devient très élevé si on n’a jamais eu à
effectuer ce genre de projet, ou s’il s’agit d’une toute nouvelle technologie. Difficile de se
lancer dans l’acquisition d’un outil de plusieurs milliers de dollars sans garantie qu’il sera
adéquat pour les besoins et qu’il permettra d’atteindre les objectifs de performance que l’on s’est
fixés.
Solution :
La preuve de concept permet de réduire les risques liés au nombre d’inconnus. Lors d’une preuve
de concept, vous validez :
- le fonctionnement de l’outil face à la technologie,
- les mécanismes de montée en charge*,
- le temps requis à l’automatisation des scénarios,
- l’effort requis à la paramétrisation** des scénarios,
- la structure des données de test qui seront nécessaires pour générer la charge,
- le coût des licences pour le nombre d’usagers virtuels requis,
- le mécanisme de gestion des licences.
Gain :
Les gains qu’apporte une preuve de concept sont énormes tant en termes de réduction du risque
que de précision des estimés de l’effort. De plus, la preuve de concept permet une familiarisation
avec l’outil, une meilleure évaluation de la courbe d’apprentissage mais aussi, de pouvoir mieux
préciser les besoins en termes de modules, licences et composantes requises pour effectuer les
tests de charge.
Le
LaboAgile du CTI offre aux organisations et
développeurs d’utiliser ses infrastructures virtuelles, ainsi que sa vaste gamme d’outils pour
effectuer des preuves de concept dans un milieu neutre, tout en maintenant des environnements de
travail distincts et sécurisés. De plus, le LaboAgile met à la disposition des utilisateurs des
outils à la fine pointe de la technologie, sans les investissements que ceux-ci requièrent, avec
entre autres, des outils d’automatisation de tests fonctionnels. Et bien que l’autonomie des
organisations dans le LaboAgile soit favorisée, elles peuvent aussi compter sur le soutien et l’e
xpertise de l’équipe du CTI pour optimiser leurs processus et leurs méthodes, voire même les
conseiller dans le choix des outils appropriés.
*Montée en charge : Mécanisme par lequel le flot et l’ordre des transactions seront gérés par l’o
util. La définition de la montée en charge devrait normalement représenter une utilisation
réaliste de l’application à tester, afin que les résultats soient représentatifs.
**Paramétrisation : Introduction de variables qui sont remplacées par des données de tests
durant le test de charge.
Des commentaires ?
raymond.rivest@crim.ca
Tests manuels ou tests automatisés ?
Par
Phuong Thao Trinh, analyste, conseillère en
tests, Centre de tests et d'interopérabilité, CRIM
15 février 2012
C’est un fait, les tests manuels nécessitent un temps considérable et mobilisent de façon
accaparante les ressources devant y être dédiées. Ce temps passé à exécuter les tests implique un
coût direct qui ne pourra pas être récupéré. Cependant, c’est une méthode de tests très flexible et
qui demande peu d’habiletés techniques (toutefois, un professionnel trouve les bogues plus
efficacement).
D’un autre côté, l’automatisation des tests apporte un lot séduisant d’avantages : délais d’e
xécution des tests plus courts, meilleure couverture de tests, constance, répétabilité, etc. Par
contre, l’automatisation est plus complexe à mettre en œuvre, est relativement onéreuse au départ,
nécessite une expertise technique et les efforts de maintenance peuvent s’avérer coûteux à la
longue si le tout est mal planifié et mal réalisé.
Il faut se demander alors dans quelles conditions il est préférable de s’orienter vers l’a
utomatisation et dans lesquelles il faut plutôt s’en tenir aux tests manuels. Plusieurs facteurs
peuvent influencer la décision. Souvent, une combinaison intelligente des deux types de tests s’a
vère être une bonne solution.
Automatisation des tests : un investissement initial qui doit rapporter
Automatiser les tests implique un investissement initial non négligeable. L’achat d’un outil d’a
utomatisation de tests, l’acquisition d’une expertise sur cet outil et le temps passé à la création
et la maintenance des scripts de tests génèrent des coûts importants. La question que l’on peut se
poser est la suivante : « Quel est mon retour sur investissement si j’automatise les tests? ».
Un élément clé de la réponse est la réutilisation des scripts de tests. Plus un script est
réutilisé, plus il devient rentable. En effet, un script doit être utilisé un nombre minimal de
fois avant qu’il ne devienne désuet. Si, disons 1 heure est investie dans la conception d’un script
et que ce dernier sauve environ 20 minutes en temps de tests manuels, il faut alors s’assurer d’u
tiliser le script un nombre suffisant de fois, soit au moins 3 fois dans ce cas-ci, pour que son
coût de conception en soit réduit.
D’ailleurs, certaines caractéristiques de l’application favorisent la réutilisabilité des
scripts de tests : la portabilité d’une plateforme à une autre, la disponibilité en plusieurs
langues, un cycle de développement qui se fait de façon incrémentale, un éventail de produits aux
fonctionnalités similaires, une interface et un code relativement stable.
Utiliser l’automatisation dans les tests de non-régression
Les tests de non-régression servent à déterminer si des erreurs ont été introduites dans ce qui
fonctionnait bien lors de l’addition de nouvelles fonctionnalités ou lors de la correction d’e
rreurs précédentes dans l’application. On s’assure que celle-ci n’ait pas « régressée » depuis la
dernière version.
En général, le travail de tests de non-régression augmente sensiblement de version en version
car ce qui était une nouvelle fonctionnalité à tester devient une fonctionnalité courante qui doit
être ajoutée dans la prochaine série de tests de non-régression. Ainsi, après chaque itération, il
y a plus de tests à couvrir. Il faut donc consacrer de plus en plus de temps et de ressources. Le
coût cumulatif peut en conséquence devenir énorme.
Il est donc avantageux d’automatiser ce type de tests avant que la phase de validation ne
devienne d’une envergure telle qu’il est quasi impossible de tout couvrir manuellement par les
ressources en place et dans des délais raisonnables.
Avec l’automatisation des tests de non-régression, les tests manuels, quant à eux, peuvent ainsi
être focalisés sur les nouvelles fonctionnalités.
Les facteurs propices aux tests automatisés versus manuels
Certains tests sont avantageux à automatiser comme les tests sur les fonctionnalités critiques
et centraux. En effet, celles-ci qui sont peu portées au changement.
Il faut aussi privilégier l’automatisation des tests qui sont plus susceptibles à l’erreur
humaine. De ce fait, les résultats de tests ne dépendront plus de la concentration du testeur qui
peut varier selon son humeur du jour.
Les tests fastidieux et répétitifs sont un bon choix pour l’automatisation. Par exemple, ceux
qui ne demandent que de changer la valeur d’un paramètre.
Les applications qui n’ont pas ou peu d’interface utilisateur sont aussi des bonnes candidates à
l’automatisation ou encore celles avec un cycle rapide de sorties de version.
Dans certains cas, il est plutôt préférable de se tourner vers les tests manuels. Par exemple,
un code instable ne maximisera pas la réutilisation des scripts, les tests exploratoires, c’e
st-à-dire lorsque le testeur génère de façon créative de nouveaux cas de tests en naviguant à
travers l’application, ou encore, les tests qui ont besoin de l’œil humain.
La maturité du système est un autre facteur à considérer. Il est en général préférable d’a
utomatiser au milieu du cycle de vie d’un logiciel. Au début, trop d’éléments sont en
effervescence, à la fin, le retour sur investissement est diminué.
Automatiser : oui mais pas n’importe comment
Nous avons vu qu’il est parfois opportun d’automatiser les tests et parfois non. La stratégie à
adopter n’est donc pas de s’investir à 100% dans l’un ou l’autre type de tests, mais de bien
balancer les deux types en considérant tous les facteurs pertinents.
Cependant, mettre en œuvre l’automatisation n’est certes pas une mince affaire. Avoir une bonne
planification, adopter une méthodologie adéquate, choisir les outils appropriés et tenir compte du
temps d’apprentissage de ces outils sont des exemples d’aspects cruciaux à ne pas négliger afin que
l’aventure soit payante. Mais cela est en soi un autre sujet…
Des commentaires ?
ptrinh@crim.ca
Goulots d'étranglement et performances
Publié à partir du Workshop On Performance and Reliability (WOPR-17) qui a eu lieu en
octobre 2011, au « Executive Center » de HP en Californie.
Problématique :
Lorsqu’on parle de goulot d’étranglement (« Bottlenecks » en anglais), on pense bien souvent en
ces termes :
Étrangement, une autre définition s’y rapporte :
En informatique, les goulots d'étranglement requièrent couramment la maîtrise de connaissances
approfondies, que ce soit en programmation, télécommunication, bases de données, systèmes
d'exploitation et même en analyse statistique. Dans chacun des cas, il faut avoir un accès complet
à l'information, ce qui constitue la principale problématique organisationnelle à laquelle nous
devons faire face.
Qu’il s’agisse de processus d’affaires, de hiérarchie d’entreprise ou encore d’accessibilité aux
infrastructures ou code sous test, en général, le goulot se situe à l’un de ces endroits.
Dans un monde idéal, comme c’est le cas chez Facebook, les spécialistes de performance ont un
accès complet à l’ensemble des infrastructures, au code, et à tout ce qui peut leur être utile pour
faire leur travail. L’environnement de test et l’environnement de production sont les mêmes et cela
permet aux spécialistes d’apporter des correctifs de façon instantanée.
Dans la majorité des entreprises, il en va tout autrement. La disponibilité des ressources
humaines constitue en soit un goulot d’étranglement. Des objectifs d’affaires nébuleux n’aident en
rien à prioriser la recherche et l’élimination des goulots.
Solution :
L’un des aspects fondamentaux, auquel se rattachent la recherche et la résolution de goulots d’é
tranglement est le suivant :
La
qualité de service
(QdS)
ou
Quality of service (QoS) est un concept de gestion qui a pour but d’optimiser les
ressources d'un
réseau (en
management du
système d'information) ou d'un
processus (en
logistique) et de garantir de
bonnes performances aux applications critiques pour
l'organisation. La qualité
de service permet d’offrir aux utilisateurs des débits et des temps de réponse différenciés par
applications (ou activités)
selon les protocoles mis en œuvre au niveau de la structure (SLA ou Service Level Agreement).
Pour répondre à ces objectifs, ces derniers doivent être clairement
identifiés et réalisables. Il faut aussi que les personnes responsables
disposent des moyens de répondre à ces objectifs. Le processus organisationnel
doit donc comporter des mécanismes permettant l’accès aux ressources et informations nécessaires à
la réalisation,
dans le respect des objectifs d’affaires de l'organisation.
La recherche et la résolution de goulots informatiques sont essentiellement des processus
itératifs qui doivent disposer d’informations et d’accès aux ressources appropriées, qu’il s’agisse
d’informations, d’outils, de connaissances ou de ressources humaines.
Gain :
L’utilisation de la méthode PRET* avant le déploiement d’une application permet d’avoir une
connaissance accrue des limites particulières d’une technologie face aux conditions de déploiement
sur un réseau étendu, mais aussi, d’éviter les pertes liées au surdimensionnement d’une
infrastructure coûteuse alors que le problème n’est pas là, ainsi que le mécontentement des
utilisateurs à cause de temps de réponses désastreux.
Le
LaboAgile du CTI offre aux organisations et
développeurs d’utiliser la méthode PRET et l'émulateur de réseaux étendus dans un milieu neutre,
tout en maintenant des environnements de travail distincts et sécurisés. De plus, le
LaboAgile met à la disposition des
utilisateurs des outils à la fine pointe de la technologie, sans les investissements que ceux-ci
requièrent, avec entre autres, des outils d’analyse sophistiqués. Et bien que l’autonomie des
organisations dans le LaboAgile soit favorisée, elles peuvent aussi compter sur le soutien et l’e
xpertise de l’équipe du CTI pour optimiser leurs processus et leurs méthodes.
Note :
Les conclusions et publications issus du WOPR17 sont les résultats des efforts collectifs des
participants de ce workshop: AJ Alhait, Scott Barber, Goranka Bjedov, Jeremy Brown, Dan Downing,
Craig Fuget, Dawn Haynes, Doug Hoffman, Paul Holland, Pam Holt, Ed King, Richard Leeke, Yury
Makedonov, Emily Maslyn, Greg McNelly, John Meza, Blaine Morgan, Mimi Niemiller, Eric Proegler,
Raymond Rivest, Bob Sklar, Roland Stens, and Nishi Uppal.
*PRET :(Performant sur Réseau Étendu de Télécommunication).
Tests de performance pour être PRET
Par
Raymond Rivest, conseiller, spécialiste
de tests, Centre de tests et d'interopérabilité, CRIM
12 septembre 2011
Problématique :
Lorsque l’on parle de tests de performance, la première idée qui vient à l’esprit est une
infrastructure lourde, des logiciels couteux et un investissement financier majeur. Les
technologies Web ayant grandement évoluées, la préoccupation de performance se résume souvent à
définir la capacité requise des serveurs, souvent, en surdimensionnant cette même infrastructure
ainsi que la taille des liens au point de service.
Cette approche, bien que logique, apporte souvent son lot de mauvaises surprises :
- Pages lentes à charger ;
- Lenteur de temps réponses ;
- Besoin d’augmentation du parc informatique ;
- Besoin d’augmentation de la taille du lien ;
- Panne de services clés et appels de support de clients mécontents.
Le problème fondamental est souvent une méconnaissance des comportements de l’application face à
des conditions réseaux réelles (latence, perte de paquets, capacité de liens) et l’impact de ces
conditions sur les performances globales de l’application. En télécommunication, la règle
fondamentale suivante s’applique :
L’évolution des technologies vers les plateformes mobiles amènent de nouveaux facteurs de
risques en termes de télécommunications et de performances.
Solution :
Le
CTI dispose depuis plusieurs
années d’outils permettant l’évaluation du comportement de systèmes dans diverses conditions
réseaux. La
méthode PRET (Prêt
sur Réseau Étendu de Télécommunication) permet de valider le comportement applicatif avant le
déploiement en reproduisant des conditions réseaux réelles.
Gains :
Les gains qu’apportent PRET avant le déploiement d’une application sont une connaissance accrue
des limites particulières d’une technologie face aux conditions de déploiement sur un réseau
étendu, mais aussi, d’éviter les pertes liées au surdimensionnement d’une infrastructure coûteuse
alors que le problème n’est pas là, ainsi que le mécontentement des utilisateurs à cause de temps
de réponses désastreux.
Le
LaboAgile du CTI offre aux organisations et
développeurs d’utiliser la
méthode PRET et l’é
mulateur de réseaux étendus dans un milieu neutre, tout en maintenant des environnements de travail
distincts et sécurisés. De plus, le LaboAgile met à la disposition des utilisateurs des outils à la
fine pointe de la technologie, sans les investissements que ceux-ci requièrent, avec entre autres,
des outils d’automatisation de tests fonctionnels. Et bien que l’autonomie des organisations dans
le LaboAgile soit favorisée, elles peuvent aussi compter sur le soutien et l’expertise de l’équipe
du CTI pour optimiser leurs processus et leurs méthodes.
Des commentaires ?
raymond.rivest@crim.ca
Interopérabilité : des environnements partageables
Par
Raymond Rivest, conseiller, spécialiste
de tests, Centre de tests et d'interopérabilité, CRIM
3 juin 2011
Problématique :
Le terme « interopérabilité » préoccupe de plus en plus les entreprises. En effet, elles doivent
s’adapter à un marché régit par des normes spécifiques et des besoins pointus, tout en conservant
leur avantage concurrentiel et surtout leur « recette secrète ».
Le principal défi est de parvenir à développer un environnement commun et neutre qui permet à
chacun des intervenants de garder ses petits secrets, tout en favorisant le regroupement des
ressources et des informations.
Solution :
Les environnements partageables sont maintenant possibles grâce à la virtualisation. Prenons par
exemple le diagramme suivant :
Dans un tel environnement, chaque entreprise gère son propre espace et peut décider de partager
des composantes. Une tierce partie, telle une agence gouvernementale ayant des besoins
d'interopérabilité, ou encore un agent neutre comme le Centre de tests et d’interopérabilité (CTI)
du CRIM, peut gérer l’espace commun, les processus et les outils de normalisation. Qu’il s’agisse
de séquence de tests, données de tests, résultats de tests, les informations peuvent être
accessibles selon qu’elles soient de nature privée ou d’intérêt commun.
Gains :
Les gains qu’apporte la mise en commun des processus, outils et services partageables favorisent
la collaboration, mais aussi une connaissance accrue des objectifs communs. Ce regroupement de
services permet d’éviter le dédoublement des informations et des infrastructures.
Le
LaboAgile du CTI offre aux organisations et aux
développeurs de partager des ressources pour tester l’interopérabilité dans un milieu neutre, tout
en maintenant des environnements de travail distincts et sécurisés. De plus, le
LaboAgile met à la disposition des utilisateurs
des outils à la fine pointe de la technologie, sans les investissements que ceux-ci requièrent,
avec entre autres, la capacité de reproduire des conditions de réseaux étendus réelles. Et bien que
l’autonomie des organisations soit favorisée, les entreprises peuvent aussi compter sur le soutien
et l’expertise de l’équipe du CTI pour optimiser leurs processus et leurs méthodes.
Des commentaires ?
raymond.rivest@crim.ca
La virtualisation : Test de charge rapide pour anomalies
fonctionnelles
Par
Raymond Rivest, conseiller, spécialiste
de tests, Centre de tests et d'interopérabilité, CRIM
11 mai 2011
Problématique :
Dans un cycle de développement où les tests fonctionnels sont automatisés, il n’est pas toujours
possible de reproduire certains types d’anomalies qui ne se retrouvent qu’en production. Ces
anomalies sont souvent liées à des fuites mémoires, blocage de record dans une table sous l’effet
de la concurrence d’accès, gestion des processus d’un service, etc.
L’inconvénient principal est qu’une fois en production, les coûts pour résoudre ces anomalies
sont beaucoup plus élevés : pertes de production, soutien téléphonique, main-d’œuvre pour
reproduire et résoudre l’anomalie, déploiement de la mise à niveau, sans compter que ces anomalies
peuvent nuire à la réputation de l’entreprise.
Solution :
La virtualisation propose une solution simple et peu coûteuse qui permet de détecter certaines
de ces anomalies avant la mise en production. Il suffit d’utiliser des scénarios automatisés qui
représentent généralement les tests d’acceptation, reproduits sur une dizaine de machines
virtuelles qui tournent à vitesse maximale.
Gains :
Sans être aussi élaborée et coûteuse que des tests de charge traditionnels, la virtualisation a
l’avantage de pouvoir s’intégrer facilement dans le cycle de développement, à moindres coûts. Une
session de 2 heures suffit généralement à trouver les anomalies liées à la concurrence de processus
ou de blocage de record. Une session de 24 heures permettra de détecter les fuites de mémoire et la
rétention de processus.
Somme toute, sans l’investissement que représentent les tests de charge poussés, la
virtualisation de scénarios fonctionnels permettra d’augmenter la couverture de test et d’éviter de
mauvaises surprises lors d’une mise en production.
D’ailleurs, le
LaboAgile peut permettre aux organisations et
développeurs de mettre la virtualisation en place rapidement et facilement, à peu de frais, dans un
environnement neutre et flexible.
Des commentaires ?
raymond.rivest@crim.ca
|
