Testeur en contexte Agile

L’Agile c’est quoi ?    

La méthode Agile n’est plus vraiment à présenter, cette méthodologie basée sur des cycles itératifs a su s’imposer dans de nombreux projets de développements.

Pour rappel, les 4 valeurs fondamentales de la méthode Agile sont :

  • L’ équipe : « Les individus et leurs interactions, plus que les processus et les outils »
  • L’ application : « Des logiciels opérationnels plus qu’une documentation exhaustive »
  • La collaboration : « La collaboration avec les clients, plus que la négociation contractuelle »
  • L’ acceptation du changement : « L’ adaptation au changement, plus que le suivi d’un plan »

Et le testeur dans ce contexte ?

Le métier du test est en constante évolution de par l’évolution des technologies, des outils de tests automatisés et des méthodes de gestion de projet.

Dans un contexte Agile, le testeur a une place prépondérante pour le succès du projet.

ISTQB en a d’ailleurs fait un syllabus que vous pouvez retrouver ici.

Comment se positionner ? Quels types de tests réaliser ? Avec qui interagir ?

Nous vous donnons quelques clés du succès qui feront de vous un bon testeur Agile dans cette vidéo :

Vous êtes certifié ISTQB fondation ? vous souhaitez être certifié ISTQB testeur Agile ? Contactez nous !!

Vous aimerez peut-être…

5 graphiques Jira pour mieux communiquer sur les anomalies

Réunion de clôture : un jeu pour finir en beauté !

Respectons le sens des valeurs agiles (blog d’Atlas Management)

 

World Quality Report 2017-2018 : focus sur l’agilité, les tests mobiles et l’automatisation

Une étude annuelle sur le monde du test logiciel

Le premier World Quality Report (en bon français, rapport mondial sur l’assurance qualité) a été publié en 2009 par Capgemini. D’année en année, l’étude s’est étoffée, a gagné en moyens et en notoriété. En 2017, le World Quality Report, c’est :

  • 1660 seniors de l’IT interrogés
  • 32 pays représentés (dont la France, avec 150 personnes interrogées)
  • Une photographie à l’instant T de l’assurance qualité dans les organisations publiques et privées de plus de 1000 employés
  • Des focus par thème, mais aussi par type d’entreprise
  • Des recommandations pour faire face aux problématiques actuelles du métier

Bref, un panorama intéressant à décoder, en gardant tout de même à l’esprit que cette année l’étude a été commanditée par la Sogeti et Capgemini, en partenariat avec l’éditeur Microfocus. Ce pure-player a notamment développé Silk Test et, plus dernièrement, racheté un large portefeuille de logiciels d’Hewlett-Packard Enterprise, dont Loadrunner. Ce qui n’est pas neutre

Notre article fait le point sur trois sujets brûlants dans le domaine du test logiciel : les transformations du métier induites par l’émergence de l’agilité, le défi encore peu exploré des tests mobiles et les challenges liés à l’automatisation des tests.

Le boom du test agile

Les chiffres du test agile

En développement comme en test, le World Quality Report révèle que l’agilité a le vent en poupe. 95% des répondants affirment mettre en oeuvre des pratiques de test agile, au moins sur une partie de leurs projets. 37% des entreprises pratiquent le test exploratoire.

Les pratiques devOps aussi sont également en expansion, et sont désormais représentées dans 88% des entreprises interrogées. Cependant, elles ne touchent jamais la totalité des projets, et concernent moins de 20% des projets dans 47% de l’ensemble des entreprises.

De nouvelles contraintes

Face à cette transformation, les forces vives du test tendent à se décentraliser, et affrontent notamment trois problématiques :

  • La création d’environnements de test idoines et de jeux de données réalistes, qui notamment respectent les lois en vigueur (« QA teams need to help their organizations comply with new data laws such as the EU’s General Data Protection Regulation », ce qui nous rappelle une fois de plus l’aspect juridique du métier de testeur). Cette problématique rend également difficile l’automatisation des tests et les tests mobiles.
  • La réutilisation et la répétition des tests au fil des itérations
  • Le manque de méthodologie de test agile

Même si la décentralisation du test présente de nombreux avantages, le WQR conseille aux grandes organisations de conserver un organe central (un « TEC » ou « Test Excellence Center ») afin d’harmoniser les pratiques, de capitaliser sur les réussites et de réaliser des POCs.

Automatisation des tests : un horizon impossible ?

Les chiffres de l’automatisation des tests

Le World Quality Report de 2017 révèle que presque la moitié des entreprises (48%, et jusqu’à 57% des entreprises spécialisées dans les télécoms, les médias et les divertissements), se trouvent trop dépendantes des tests manuels. Et effectivement, le chiffre peut étonner : seuls 16% des cas de test fonctionnels sont automatisés !

Parmi les difficultés le plus fréquemment rencontrées, on retrouve :

Autant de challenges qui freinent l’avancement des projets d’automatisation, et augmentent année après année le manque à gagner.

Des pistes pour mieux automatiser les tests

Face à ce constat, le World Quality Report conseille de s’armer de patience. Le rapport indique que parmi les entreprises ayant mis en oeuvre une stratégie d’automatisation des tests, celles dont la démarche a été la plus fructueuse ont commencé par des projets-pilotes autonomes (à l’inverse d’une approche « big bang »).

Il est aussi conseillé de prendre au sérieux la formation en automatisation des tests des équipes qualité, où d’importantes lacunes sont constatées.

Enfin, la présence d’une réelle stratégie et la transparence des reportings des tests automatisés sont cités comme des critères de réussite majeurs.

Tests mobiles : ça pourrait bouger plus

C’est ce qui ressemble à la cinquième roue du carrosse : 52% des répondants n’ont pas assez de temps pour mener des tests mobiles. 47% pointent un manque de méthodologie dans le domaine, 46% ne disposent pas d’équipements adéquats. 5% des organisations interrogées ne font même aucun test mobile.

Ces chiffres sont étonnants, à l’heure où des solutions open-source telles qu’Appium, ou des IDE performants et gratuits comme Katalon, permettent de mettre en oeuvre à moindre coût des stratégies de test mobile, y compris en externalisant la gestion des hardwares (avec par exemple AWS Device Farm, Xamarin Test Cloud ou Kobiton).

Un point intéressant à relever est que les tests non-fonctionnels sont bien représentés dans le domaine du test mobile :

  • 53% des stratégies incluent des tests de performance
  • 43%, des tests de sécurité
  • 39%, des tests de compatibilité
  • 38%, des tests de portabilité,

Contre 48% pour les tests d’interface utilisateur.

Plongée dans le passé : quoi de neuf depuis 2009 ?

L’automatisation des tests était déjà source d’embarras

Certaines choses ne changent pas : en 2009, les entreprises étaient déjà frustrées par leur taux d’automatisation des tests. Le World Quality Report indiquait en effet que 50% des entreprises n’avaient pas atteint leurs objectifs d’automatisation 3 ans après avoir acquis les outils ad hoc. En cause : le manque de plannification, de stratégie sur le long terme et de formation des testeurs. A l’époque, des solutions d’automatisation existaient déjà depuis une quinzaine d’année.

… mais la vision de l’automatisation a mûri

Il existait à l’époque un aspect qui peut maintenant nous étonner : dans l’édition de 2009, la majorité des personnes interrogées pensaient que l’automatisation des tests pourrait aider à réduire la taille de l’équipe de test. Une corrélation qui de nos jours paraît naïve, et qui a d’ailleurs totalement disparu dans l’édition de cette année.

On est sortis de la crise…

Dans le WQR de 2009 transparaît un sentiment d’inquiétude lié à la crise. L’agilité est directement assimilée à un gain pécuniaire, les robots de test semblent voués à remplacer les humains… Il est réjouissant de constater qu’en 2017, ce biais a disparu (au profit d’autres que nous n’identifierons sans doute, hélas, qu’en 2025).

… et on a découvert tant d’autres choses

Pour faire bref, voici quelques mots que l’on ne trouvait pas encore dans la première édition du World Quality Report :

  • Mobile
  • API
  • Load testing
  • DevOps (et pour cause, le mot a été inventé deux mois après la parution du WQR de 2009 !)

La sécurité applicative, la performance et le cloud sont brièvement évoqués, mais on ne les retrouve pas plus loin que dans l’introduction. Bref, depuis la première édition du WQR, le métier du test n’a eu de cesse de s’étoffer. Multidisciplinaire en pratique, il l’est devenu de plein droit au fil des années.

Conclusion

Certes, il n’est pas toujours facile de comprendre comment sont générés les chiffres du World Quality Report. « Nous ne pratiquons pas le test agile » : ils étaient 2% à l’affirmer en 2015, contre 31% en 2016 (!) et maintenant 5% en 2017… Mais malgré ce genre de bizarreries que l’on retrouve tout du long, ainsi que quelques partis pris qui s’expliquent par les commanditaires de l’étude (par exemple l’évocation de TMap, mais pas d’ISTQB) le WQR reste un document utile pour prendre la température du monde du test et comprendre les problématiques auxquelles font face aujourd’hui les grandes organisations. Une analyse qui s’avère encore plus intéressante lorsqu’on la met en parallèle avec les éditions précédentes. Alors bonne lecture !

Ressources

World Quality Report de 2009 (pdf)

World Quality Report de 2017 (formulaire de téléchargement)

Vous aimerez peut-être…

Chiffres sur l’accessibilité du web calédonien

9 points juridiques que chaque QA devrait maîtriser

Le test logiciel est une protection contre les bugs, mais aussi contre les litiges. Vous avez un doute ? Cet article est fait pour vous.

La loi relative à l’informatique, aux fichiers et aux libertés, indique :

Constitue une donnée à caractère personnel toute information relative à une personne physique identifiée ou qui peut être identifiée, directement ou indirectement, par référence à un numéro d’identification ou à un ou plusieurs éléments qui lui sont propres.

Sous peine de sanctions, ce type de données doit faire l’objet d’un traitement particulier. Toute personne travaillant dans la qualité logicielle devrait valider que les données personnelles sont manipulées de manière légale.

1) Il est obligatoire d’assurer la sécurité des données personnelles

Comme le dit l’article 34 de la loi,

Le responsable du traitement est tenu de prendre toutes précautions utiles, au regard de la nature des données et des risques présentés par le traitement, pour préserver la sécurité des données et, notamment, empêcher qu’elles soient déformées, endommagées, ou que des tiers non autorisés y aient accès.

La loi est sans équivoque : la sécurité des données personnelles relève de la responsabilité de celui qui les traite. En cas d’attaque informatique, l’entreprise victime de l’attaque peut être poursuivie en justice par ses internautes. Double effet kiss cool.

Les QA, connaissant cette problématique, doivent veiller à ce qu’elle soit soulevée au plus tôt, et si possible renforcer la sécurité des informations en pratiquant des tests de sécurité.

2) Le traitement des données doit être transparent

Les utilisateurs doivent être informés de leurs droits. Pouvoir consulter les mentions légales (dont le contenu est également réglementé) est obligatoire.

3) La localisation des données est réglementée

Transférer des données personnelles en-dehors de l’UE a des implications juridiques. Il est important de savoir vers quels pays les données personnelles peuvent être transférées. A titre d’exemple, en mars 2017, il est possible de transférer des données personnelles en Argentine, mais pas en Australie.

4) Envoyer un mail peut être un délit

Envoyer un mail ne coûte rien… mais ce n’est pas toujours autorisé. Il est interdit d’envoyer des mails commerciaux à des adresses trouvées dans des espaces considérés comme publics : pages web sans authentification, forums de discussion, annuaires.

Le cas échéant, si un internaute donne volontairement son adresse e-mail, il faut impérativement lui dire qu’il est susceptible de recevoir des offres commerciales.

Tout courrier commercial doit proposer un lien de désinscription.

Dans les formulaires, les cases à cocher proposant l’envoi de mails publicitaires doivent être décochées par défaut.

Plus d’informations ici.

5) Ne pas crypter les mots de passe peut coûter cher

Il est interdit de conserver en base de données des mots de passe non cryptés, comme Optical Center qui, en 2014, en a fait les frais. 50 000 euros d’amende ont dû être déboursés. Un coût financier mais aussi réputationnel… A cet effet, la CNIL donne des éléments pour mettre les mots de passe en sécurité.

6) Stocker certaines données est interdit

Une donnée sensible, au sens CNIL, concerne un ou plusieurs des aspects suivants de l’internaute :

  • ses origines raciales ou ethniques,
  • ses opinions politiques, philosophiques ou religieuses,
  • ses appartenances syndicales,
  • sa santé ou son orientation sexuelle,
  • ses données génétiques ou biométriques,
  • son passé judiciaire,
  • son numéro de sécurité sociale.

Attention, certaines données sont sensibles sans en avoir l’air. Vous demandez à vos utilisateurs s’ils sont végétariens, végans, au régime sans gluten, sans oeufs, sans porc, sans lactose ? Sans le savoir, vous êtes sur le point de stocker une donnée sensible dans votre base de données. Demandez-vous si le risque en vaut la peine.

Le traitement des données sensibles est en principe interdit. Si ces informations sont vraiment nécessaires, leur recueil doit être justifié et nécessite le consentement exprès de la personne. Par prudence, il est conseillé de demander un avis sur les données sensibles à la CNIL, voire une demande d’autorisation (obligatoire par exemple pour le numéro de sécurité sociale). Attention, la réponse peut prendre quelques mois avant d’arriver.

Toutes les données sensibles sont concernées : celles déclarées par les utilisateurs sur le site, celles recueillies « IRL » et informatisées ensuite, et même si ces informations sont prévues pour être utilisées strictement en interne. La CNIL donne une définition précise de la donnée sensible.

7) Il est interdit de placer un cookie sans autorisation

Il est obligatoire de :

  • communiquer aux internautes la finalité des cookies
  • demander leur consentement (dont la durée maximale de validité est de 13 mois)
  • leur fournir un moyen de refuser les cookies.

Et tout cela, avant de générer le cookie.

En savoir plus sur les cookies

Respecter la propriété intellectuelle

8) Les contenus textuels et multimédias doivent être contrôlés

Des questions de bon sens sont de rigueur :

  • Les contenus affichés par le système à tester appartiennent-ils à sa société éditrice ? Si non, les autorisations idoines ont-elle été produites ?
  • Les crédits sont-ils correctement mentionnés ?
  • Le droit de courte citation est-il correctement appliqué ? Le contenu est-il exempt de plagiat ?
  • Les personnes dont les photos apparaissent ont-elle donné une autorisation explicite ?

Quelques vérifications bien utiles, qui prendront peu de temps à l’équipe de test et pourront éviter litiges et bad buzz.

9) Les briques open-source peuvent imposer des contraintes qu’il faut respecter

Si le produit comprend des briques issues de programmes open-source, il est essentiel de respecter la licence qui leur est associée. Attention, certains logiciels open-source obligent à partager leurs versions modifiées (par exemple avec la licence GNU GPL).

Conclusion

Certes, les QA ne sont pas des juristes. Dans une vision 360° de la qualité, nous devons pourtant être capables de porter un regard critique sur les aspects juridiques du système à tester. Les champs d’étude sont extrêmement vastes : il faudrait encore parler du droit à l’oubli, des lois propres aux sites de e-commerce… Nous ne saurions assez vous conseiller d’investiguer afin de comprendre jusqu’où les tests peuvent aller.

Bonus

Performance, charge, stress… quelle différence ?

Vocabulaire ISTQB : on fait le point !

Dans le domaine du test comme ailleurs, il est important de bien nommer les choses afin de partager un langage commun avec ses interlocuteurs.

Quelle est donc la différence entre un test de charge et un test de performance ? S’agit-il de la même chose que d’un test de stress ? De robustesse ?… Sans avoir connaissance des définitions précises de ces termes, il est facile de s’emmêler les pinceaux.

Or, il arrive que des sons de cloche ne s’accordent pas, et par exemple que des sites se contredisent entre eux. Pourquoi ? D’une part, parce que les tests se ressemblent et mettent parfois en jeu les mêmes outils. D’autre part, parce que les termes évoquent des choses similaires ; dans la vie de tous les jours, on peut dire qu’une équipe performante est capable de tenir une grosse charge de travail en gérant bien son stress.

Il est donc important de se baser sur une source qui fasse autorité et permette de trancher ! Ici, nous nous réfèrerons au glossaire officiel de l’ISTQB, un « must-have » et un « must-read » pour les testeurs.  Plongeons-nous donc dans les définitions de ces termes !

Qu’est-ce qu’un test de performance ?

Test de performance : le processus de test pour déterminer les performances d‘un produit logiciel.

Performance : degré en fonction duquel le système ou composant accomplit les fonctions qui lui sont affectées dans le respect de contraintes données en ce qui concerne son temps d‘exécution et taux de débit. [d‘après IEEE 610]

Le but du test de performance est de fournir des métriques sur la rapidité de l’application. On veut déterminer si elle est capable d’exécuter ses fonctionnalités en un temps acceptable. La priorité n’est pas de connaître les performances de l’application dans un contexte particulier. Pour cela, un autre type de test peut être distingué : le test de rendement.

Le test de performance répond à la question : l’application est-elle suffisamment rapide ?

Des APIs permettent de diagnostiquer rapidement les problèmes de performances d’une page web. La plus utilisée est certainement PageSpeed, développée par Google. Elle founit un score sur 100, ainsi que des pistes pour améliorer la vitesse de chargement de la page.

Amusez-vous à utiliser cette ressource pour évaluer la performance de votre site web !

Voici par exemple les résultats du calcul des performances du site Testeum :

Qu’est-ce qu’un test de rendement ?

Test de rendement : le processus de test pour déterminer le rendement d‘un produit logiciel.

Rendement : la capacité du produit logiciel à fournir des performances appropriées, relatives au niveau de ressources utilisées dans des conditions spécifiées. [ISO 9126]

Le test de rendement introduit la notion de « conditions ». Le test de rendement permet d’établir un rapport entre performances et ressources utilisées dans un contexte réaliste (ex : plusieurs utilisateurs connectés en même temps, réalisant des requêtes consommant plus ou moins de ressources).

Le test de rendement répond à la question : l’application est-elle suffisamment rapide dans un contexte donné ?

Qu’est-ce qu’un test de charge ?

Test de charge : un type de test concerné par la mesure du comportement d‘un composant ou système avec une charge croissante, p.ex. nombre d‘utilisateurs et/ou nombre de transactions en parallèle pour déterminer quelle charge peut être gérée par le composant ou système

Le test de charge recherche la limite des capacités de l’application. En augmentant graduellement la charge à laquelle est soumise l’application, il est possible d’identifier des paliers. On peut considérer le test de charge comme un pré-requis au test de stress.

Le test de charge répond à la question : quelle est la charge maximale supportée par l’application ?

Qu’est-ce qu’un test de stress ?

Test de stress : Un type de test de performance mené pour évaluer un système ou composant à ou au-delà des limites de sa charge de travail anticipées ou spécifiées, ou avec une disponibilité réduites de ressources telles que l‘accès mémoire ou serveurs [d‘après IEEE 610].

Le test de stress permet d’anticiper les performances d’une application en contexte exceptionnel (afflux non anticipé d’utilisateurs, panne). Un cas d’école : l’explosion des visites sur un site de e-commerce le premier jour des soldes. On peut considérer le test de stress comme une catégorie de test de robustesse.

Le test de stress répond à la question : comment réagit l’application lorsqu’elle est soumise à sa charge maximale ?

Qu’est-ce qu’un test de robustesse ?

Test de robustesse : test concernant le degré pour lequel un composant ou système peut fonctionner correctement en présence de données d‘entrée invalides ou de conditions environnementales stressantes.

Le test de robustesse permet de vérifier qu’une application reste opérationnelle en contexte exceptionnel. Les menaces testées viennent aussi bien d’une charge importante (comme le test de stress) que de comportements non souhaités (flux d’informations incorrectes, de fichiers corrompus…)

Le test de robustesse répond à la question : comment réagit l’application lorsqu’elle est soumise à des inputs ou un contexte exceptionnels ?

Autant de tests non-fonctionnels…

Malgré leur synonymie apparente, les différents termes que nous venons de présenter donnent donc lieu à des tests spécifiques, que nous ne devrions pas confondre afin de maintenir une communication claire.

Envie de passer une certification ISTQB ?

Si vous souhaitez approfondir vos connaissances en test, nous organisons à la demande des accompagnements à la maîtrise d’ISTQB à Nouméa. Hightest est organisme de certification accrédité par le GASQ depuis 2015 et est habilité à organiser des examens ISTQB. Pour plus d’informations, veuillez prendre contact avec nous !

Et pour vos révisions, jetez un oeil à notre article Les 7 principes généraux du test en illustrations et à nos différents quiz en ligne !

3 maladies de l’automatisation des tests

Le testeur chargé de l’automatisation des tests est vulnérable à des troubles qui lui sont propres. Il est important de les connaître pour mieux s’en protéger.

La logopathie – Trouble cognitif

Symptôme

Le patient est le seul de son équipe à pouvoir lire les logs produits par ses tests automatisés. Souffrant d’une apparente dissonnance cognitive, il énonce des propos déroutants tels que « Tous ceux-ci ne passent pas mais c’est normal ».

Cause

Trop absorbé par le développement de ses automates, le patient a négligé la qualité du reporting, un élément pourtant nécessaire à la compréhension des résultats des tests.

Complications possibles

  • L’équipe devient dépendante de son testeur automaticien. Par conséquent, s’il est absent, il est impossible d’analyser les résultats des tests automatisés.
  • Analyser les logs devient si compliqué que, par manque de temps, on ne lance plus les tests automatisés. Tout le temps consacré à ce travail est désormais perdu.
  • Dans le pire des cas, on finit par abandonner l’automatisation des tests.

Mesures préventives

  • Utiliser un framework de test BDD : Gebish, Cucumber… qui prendra en charge nativement un reporting d’une clarté satisfaisante.
  • A défaut, anticiper cette problématique dès le début du projet d’automatisation. Pour chaque étape du test automatisé, générer un log en bon français. Il est également important de faire savoir où se trouvent les reportings, afin que les personnes concernées puissent les trouver en toute autonomie.

Remèdes possibles

Allouer du temps à cette problématique en communiquant sur son importance. Chiffrer les gains de temps possibles en analyse.

Si vous utilisez Selenium, une petite virée sur notre article dédié à la qualité des logs Selenium vous redonnera des couleurs.

Troubles associés

Le documutisme (trouble de la communication). Le patient n’a pas conscience de la complexité de son projet et/ou ressent une aversion envers les tâches documentaires. Il en résulte une aura de mystère autour des travaux d’automatisation des tests. Seuls quelques proches du patient ont été instruits de bouche à oreille et sont en mesure de comprendre, de loin en loin, ce dont il est question.

L’automatite – Trouble de l’identité

Symptôme

Le patient agit davantage en « automaticien » qu’en testeur. Il enchaîne les scénarios et automatise au kilomètre.

Cause

Le testeur chargé de l’automatisation des tests est soumis à une forte exposition à des problématiques purement techniques. Comment cliquer sur le premier bouton visible en ignorant les boutons cachés qui le précèdent ? Comment naviguer entre 2 popups ou plus ? Comment autoriser ou interdire la géolocalisation sur tel ou tel navigateur ? Cette charge cognitive peut le mener à oublier le pourquoi au profit du comment. Le patient devrait, en temps normal, être en mesure de conserver un œil critique sur les scénarios qu’il doit automatiser.

Complications possibles

  • Faute de recul, le patient perd un temps précieux à automatiser des scénarios à faible valeur ajoutée.
  • Le patient passe à côté de bugs qu’il aurait pu trouver.
  • Les reportings perdent en pertinence.

Mesures préventives

Dès le début du projet, prévoir des rôles hybrides. La dichotomie entre le testeur manuel et le testeur automaticien, décriée par certains, pourrait être néfaste au métabolisme de l’équipe de test.

Vu sur https://mrslavchev.com

Remèdes possibles

Redonner une vision d’ensemble de la qualité du produit en introduisant des phases de test manuel et de rédaction de cas de test dans l’emploi du temps du patient.

Troubles associés

Chez le testeur dit manuel, la checklistopathie paralyse les mêmes neurones que l’automatite. Les deux types de malades ont besoin, pour recouvrer la santé, de raviver leur curiosité et leur passion pour le fouinage logiciel.

La scalophobie – Trouble de la motricité

Symptôme

Le patient se trouve face à un projet d’automatisation des tests dont il n’a pas suffisamment étudié la scalabilité. L’architecture est brouillonne et difficile à maintenir. Le patient évolue avec difficulté au sein d’un écosystème qu’il a lui-même créé.

Cause

Avide d’avancer rapidement dans l’automatisation des scénarios, le patient a consacré un temps insuffisant à la conception de l’architecture de son projet d’automatisation.

Complications possibles

  • Importantes pertes de temps en maintenance.
  • Difficulté à intégrer de nouveaux collaborateurs dans le projet.
  • Risques accrus de contracter la logopathie

Mesures préventives

En début de projet, dédier une plage de temps suffisante à la conception de l’architecture du projet. Communiquer sur l’importance de cette phase. S’appuyer sur des design patterns éprouvés, tels que le Page Object (dont nous donnions dernièrement un exemple avec Protractor).

Remèdes possibles

Une bonne refactothérapie !

Troubles associés

La scalophobie de type documentaire, qui affecte les testeurs en charge de la rédaction des cas de test.

Conclusion

Il est essentiel de maintenir une bonne hygiène de vie afin d’éviter les maladies que nous venons de lister. Garder le cap sur les objectifs de l’automatisation, communiquer avec son entourage et conserver un recul sur ses activités permettra au testeur de rallonger l’espérance de vie de ses automates et de booster leur tonus au quotidien.

Bon courage !

Vous aimerez peut-être aussi…

Ce n’est pas un bug, c’est un poème

Les 7 principes généraux du test en illustrations

Le kit de secours métaphorique du testeur agile

Vous avez à coeur de respecter les bonnes pratiques de tests automatisés ? Cette page mémo pourrait vous être utile !

Saga de l’audiovisuel – Et l’automatisation alors ?

Saga de l’audiovisuel

Pourquoi automatiser ?

Bienvenue à nouveau dans le monde de l’audiovisuel. Nous avons évoqué les enjeux du test en télévision numérique, ainsi que les différents types de test et leur protocoles. Abordons maintenant le sujet de l’automatisation.

Les pauvres testeurs ! On trouvait ça cool nous, d’être payé à regarder la télé derrière son bureau, mais en fait c’est dur comme boulot !

Exactement, c’est pas tous les jours facile la vie de testeur dans l’audiovisuel, beaucoup de tâches répétitives, j’appuie sur la touche menu, j’observe, je mesure, et à la longue, la concentration diminue, et le risque d’erreur, de passer à côté d’une anomalie augmente.

D’autre part, durant les longues phases de test d’endurance, le testeur connaît l’état de son décodeur au lancement du test, puis à l’issue du test, mais comment savoir s’il n’y a pas eu d’erreur pendant le test, un redémarrage imprévu après lequel la set top box s’est remise sur pied d’elle même, des problèmes de qualité audio/video, un message d’erreur temporaire,…

Certains problèmes, comme un redémarrage du décodeur, peuvent-être détectés en « instrumentant » un décodeur en test, c’est-à-dire, en récupérant les logs ou traces de l’application, mais cette solution a le défaut d’influer sur les performance du décodeur, et ne reproduit pas fidèlement le comportement d’un décodeur sur le terrain qui eux sont configurés pour ne plus produire de logs.

Robots de test

Oyez, testeurs, vous n’êtes pas seuls. Quelques sociétés du secteur informatique et télécommunication, Sopra, S3 TV Technology (racheté par Accenture), ou encore Witbe on mis au point des solutions d’automatisation des test pour la télévision numérique.

Le rôle de ces équipements, ou robots de test, est de reproduire les actions d’un utilisateur réel et d’analyser les comportements du matériel testé.

Pour ce faire, un robot possède des « mains », ou plutôt un émetteur infrarouge (ou bluetooth ou RF) contrôlable avec lequel il peut envoyer des commande au décodeur. Il possède également des « yeux », une carte d’acquisition vidéo lui permettant de visualiser la sortie vidéo du décodeur, des « oreilles », une carte d’acquisition audio pour récupérer la sortie audio, et pour gérer tout ça, un cerveau rapide et puissant, composé d’un processeur, de beaucoup de mémoire vive et d’algorithmes complexes lui permettant par exemple :

  • De reconnaître des images spécifiques : message d’erreur, mogo de démarrage, bannière information, ou toute autre image fixe pouvant être vue par un humain
  • De reconnaître des caractères (OCR) : numéro de chaîne, nom du programme en cours
  • De mesurer le volume audio et inversement de détecter une absence de son ou un niveau anormal
  • De détecter une image figée non prévue
  • De détecter un écran noir

Voici un schéma explicatif d’un environnement de test automatisé au moyen d’un robot de test :

 

La combinaison de toutes les fonctionnalités décrites ci-dessus, offre aux robot de test, la possibilité d’effectuer des tâches répétives et complexes de navigation, de reconnaissance des menus affichés, des mesures précises des temps de zapping ou encore de démarrage.

Les robots n’ont pas besoin de sommeil, ainsi, il peuvent observer, détecter et enregistrer toutes les anomalies survenant jour et nuit ce qui, comme nous l’avons vu précédemment peut s’avérer très utile lors des tests d’endurance.

Les robots possèdent également des capacités d’analyse de la qualité audio/vidéo (QoE pour Quality of Experience). Ils sont notamment capables de détecter des « artefacts », qui sont des défauts de qualité comme la présence de courts écrans noirs, ou encore de macroblocs (présence de carrés anormaux sur l’image, comme quand vous regardez un film en streaming et que soudain, votre débit internet diminue, vous entendez alors des bruits étranges, les glitchs audio, et votre image se dégrade, devient, rouge, verte, violette avec pleins de carrés, comme si l’image se pixelisait.

Enfin, les capacités de reconnaissance d’image des robots permettent également de faire de la supervision afin de connaitre en temps réel la disponibilité des services vidéo (QoS pour Quality of Services) délivrés. Ce sujet s’écarte de la pure problématique qualité d’un décodeur numérique, et touche à la diffusion des programme vidéos (broadcasting). Nous y reviendrons sûrement dans un autre article.

Hommes de test

Ah on est rassurés, on ne leur demande pas d’appuyer 100 000 fois sur une touche de leur télécommande. Mais ils ne risquent pas de se faire virer si des machines peuvent faire leur travail à leur place ?

Aucune chance, et gare à celui qui viserait cet objectif. Les robots n’ont pas de perte de concentration, sont insomniaques et sont des bourreaux de travail, mais ils ont un point faible, ils ont besoin de l’Homme pour savoir quoi faire, comment le faire et pour comprendre leur langage. Ces deux là sont totalement complémentaires, symbiotiques. Les robots soulagent les testeurs en prenant en charge les tâches longues et répétitives, les testeurs, en échange les entretiennent, les optimisent, et interprètes les données qu’ils fournissent.

Le plus souvent, lorsque qu’un robot est déployé, là où il n’y avait qu’un testeur, il y a maintenant, en plus, un responsable d’exploitation chargé de l’infrastructure, de la rédaction et de la maintenance des scripts de tests.

Et côté ROI, pas d’inquiétude non plus, c’est tout de même l’un des interêts, une gestion automatisée des tests augmentera la capacité de l’équipe et la fiabilité des tests, diminuant significativement les coûts de non qualité.

Conclusion

Si nous avions un conseil à vous donner, n’ayez pas peur d’automatiser ! Que ce soit en confiance, en fiabilité, en couverture, en rapidité, vous y gagnerez. Et si nous avions un second conseil à vous donner, automatisez intelligemment ! Toutes les solutions existantes ne vous sont pas forcément nécéssaires. Prenez le soin et le temps d’étudier votre besoin et les compétences de vos équipes avant de vous jeter sur la solution la plus attirante ou la moins chère. A titre d’exemple, il vaut peut-être mieux investir dans une solution plus coûteuse mais pour laquelle l’écriture des scripts se fait dans un langage de programmation déjà connu de vos équipes. Bonne automatisation !

Découvrez nos autres séries d’articles !

Notre série dédiée aux tests de sécurité

Celle dédiée à Protractor

Le kit de secours métaphorique du testeur agile

Saga de l’audiovisuel – Stress, Endurance, Performance

Saga de l’audiovisuel

Les tests non fonctionnels

De retour sur nos petits écrans, pour découvrir maintenant de quelle façon sont testés les aspects non fonctionnels de notre décodeur numérique.

Eh oui, notre équipement doit savoir afficher une chaine de télévision, il doit comprendre quand nous lui donnons un ordre avec notre télécommande, mais il doit être aussi capable de le faire vite, et de le faire bien.

On lui en demande beaucoup à cette pauvre petite boîte éléctronique.

C’est vrai, les testeurs ne sont pas toujours tendres avec leur décodeurs, mais c’est pour la bonne cause.

Tests d’endurance et stress tests

Dans cette catégorie, on ne teste plus les fonctionnalités à proprement parler du décodeur, mais la résistance du système lors de l’exécution prolongée d’une action ou de la répétition d’une action sur une longue durée.

On parlera d’endurance lorsque la charge imposée au système est relativement faible, et de stress lorsque celle-ci est importante au sens de la consommation de ressources.

Live statique

Ce test, d’endurance uniquement, consiste à laisser le décodeur jouer une chaîne en continu (la veille automatique doit être désactivée), et de vérifier que la chaîne continue d’être diffusée sur la durée spécifiée. Les exigences sur cette durée sont variables selon les fabricants, les décodeurs mais aussi en fonction de la catégorie de chaîne que l’on test. En effet, nous pourrons distinguer entre autres les cas suivants avec une consommation de ressources croissante :

  • Chaîne SD (Standard Definition) non cryptée (gratuite)
  • Chaîne SD cryptée (nécessitant un abonnement)
  • Chaîne HD (High Definition) non cryptée
  • Chaîne HD cryptée
  • Chaîne HD cryptée, avec enregistrement d’un programme sur une autre chaîne et timeshift sur la chaîne en cours

Plus la charge augmente, moins la durée exigée est longue. Par expérience, un décodeur devrait pouvoir jouer en continu un programme SD pendant 7 jours en continu sans rencontrer de problèmes, mais dans la pratique ce n’est pas toujours le cas et parmi les problèmes rencontrés par les équipes de validation, entre autre, freeze (image figée), redémarrage spontané, écran noir…

Le protocole ici est on ne peut plus simple, on démarre un ensemble de décodeurs sur la/les chaînes souhaitées en vérifiant l’image et l’audio, on vit sa vie sans y penser pendant la durée exigée, puis « on relève le mur », c’est à dire, qu’on constate l’état des décodeurs à l’issue de cette durée, nombre de OK, nombre de KO, description des KO. Dans la pratique, on vient jeter un œil tous les jours ou plus sur les décodeurs, car s’ils sont tous plantés après 20 minutes, aucun intérêt de poursuivre le test.

AC On / Off

Ici même principe de tenue du système dans la durée, mais l’action est plus agressive. Il s’agit de répéter la séquence : coupure d’alimentation / mise sous tension. En endurance, des séquences répétées de 10 minutes laissent normalement le temps à tous les décodeurs de finaliser leur séquence de démarrage. En stress, les séquences peuvent être très courtes de l’ordre d’une minute. L’intérêt étant de pouvoir valider le comportement du système lors de l’arrêt brutal des processus en court.

Ce test est stressant pour le software et le hardware, mais permet de détecter des défauts lors de la séquence de boot (démarrage) et d’évaluer la probabilité qu’une coupure de courant en utilisation terrain (sur le meuble télé du client) puisse entraîner une anomalie.

Zapping

Qu’est-ce qu’un zapping ? Ça ne sonne pas très scientifique ce mot. Un zapping est un changement de chaîne. Déclenché par l’utilisateur muni de sa télécommande, il s’agit de l’action la plus courante que doit effectuer un décodeur numérique. Il existe beaucoup de « zappings » différents :

  • Par appui sur la touche chaîne suivante, (P+ ou Next Channel pour les intimes) 
  • Par appui sur la touche chaîne précédente, (P- ou Prev Channel pour les intimes) 
  • Par navigation dans l’EPG (Grille des programmes ou Electronic Program Guide pour les intimes)
  • D’une chaîne SD à une chaîne HD et inversement
  • D’une chaîne cryptée à une chaine non cryptée et inversement
  • Avec un enregistrement en cours
  • Avec la fonctionnalité Pip (Picture in Picture qui consiste à afficher une autre chaîne que celle en cours dans un cadre)

Tous ces zappings font appels à des fonctionnalités différentes et ont donc des comportements différents qui doivent être validés. L’action de zapping peut sembler anodine, mais est en réalité assez complexe, et mobilise également beaucoup de ressources au système.  Le schéma suivant illustre les actions mises en œuvre par le décodeur lors d’un changement de chaîne classique (P+) :

  • t1 : Temps d’apparition de la bannière d’information (info banner) ta : Temps d’apparition de l’écran noir de transition
  • t2 : Durée de l’écran noir de transition
  • tb : Durée d’affichage de l’info banner
  • Temps de zapping = ta + t3 , c’est à dire le temps écoulé entre l’envoi effectif de la commande de changement de chaîne par l’utilisateur et la lecture de la chaîne demandée.

 

Que l’info banner soit présente à l’écran ou non, on considère le zapping effectif dès que l’audio et la vidéo de la nouvelle chaîne sont joués. Le test de la fonctionnalité zapping est effectué au moyen de boîtiers infrarouges (certains sont maintenant bluetooth ou RF) programmables (voir Redrat ou encore IRTrans).

De la même manière qu’en live statique, le testeur programme sa télécommande pour répéter l’envoi de la commande de changement de chaîne à intervalle régulier sur une période donnée, puis vient relever l’état du mur de test à l’issue de la campagne (nombre de décodeurs toujours en zapping, nombre de décodeurs ayant rencontré un problème et description du problème).

Pour se faire une idée, en endurance, un intervalle entre deux demandes de zapping de l’ordre de 15 à 20 secondes est une valeur acceptable afin de laisser le temps au décodeur de déclencher puis de stopper l’ensemble des processus associés, le décodeur pouvant supporter cette charge sur de longues périodes (une à plusieurs semaines).

En stress, cette durée est réduite à environ 5 secondes. A cette cadence, le décodeur n’a pas le temps de charger tous les processus avant de devoir les stopper pour répondre à l’ordre suivant. Il est fréquent lors de ce stress test de voir des décodeurs échouer au bout de quelques heures seulement. Ce test est intéressant car il permet de simuler et d’analyser le comportement d’un décodeur par exemple lorsque l’utilisateur s’endort sur sa télécommande. Dans cette situation, le fabricant doit s’assurer que le système tienne la charge, ou à défaut qu’un redémarrage suffise à le relancer.

Tests de performance

Dans le cadre de la validation d’un décodeur numérique, il est intéressant de mesurer différents temps d’action du système selon les fonctionnalités demandées et de s’assurer qu’elles restent dans des seuils acceptables par utilisateur. Parmi ces mesures, on notera les :

Temps de zapping

Comme nous l’avons vu précédemment, la mesure s’effectue entre l’envoi de la commande par l’utilisateur et l’apparition (audio/vidéo) de la chaîne demandée. Pour effectuer cette mesure, le testeur calcule généralement une moyenne à partir d’un échantillon d’une dizaine de mesures effectuée manuellement. Il est difficile de fournir un critère d’acceptation général pour le temps de zapping tant les durées peuvent varier selon les produits et les fonctionnalités activées.

Temps de Boot / Veille

Ici même principe, on ne cherche plus la tenue dans la durée, mais « simplement » à mesurer les durées des différentes étapes de la sortie de veille, ou de la remise sous tension. Comme pour les temps de zapping, le testeur est à son bureau, devant son décodeur et sa télé et son chronomètre. Il démarre son chronomètre au moment précis où il remet le courant dans le décodeur, ou appuie sur le bouton « On », puis marque différents checkpoints temporels à des moments précis tels que : 

  • L’apparition du message « Démarrage en cours » sur le front panel (l’écran à affichage digital dont tous les décodeurs sont munis en façade)
  • L’apparition du logo sur le téléviseur
  • L’apparition du menu principal ou diffusion de l’audio et de la vidéo d’une chaîne.

Ces mesures sont également moyennées sur des échantillons d’une dizaine de mesures.

Conclusion

Une nouvelle fois, cette liste n’est pas exhaustive. Comme pour les test fonctionnels, beaucoup d’autres tests non fonctionnels et mesures de performances sont possibles, comme le chargement et la navigation dans les menus, chargement et navigation dans la grille des programmes, chargement et navigation dans le menu VOD (vidéo à la demande),…

Le but de ces tests est en quelque sorte de s’assurer que votre décodeur résistera à toutes ou, presque toutes les misères que vous pourriez lui faire subir.

Le dernier article de la saga traitera le sujet de l’automatisation des tests en télévision numérique.

Saga de l’audiovisuel – Tests fonctionnels

Saga de l’audiovisuel

Introduction

Les R&Ds des fabricants de décodeurs numériques possèdent une équipe de validation, dédiée à la vérification du bon fonctionnement des produits avant et pendant leur mise en production mais également après, lors des phases de maintenance.

Un bureau de validation de décodeur numérique est généralement un grand open space, rempli de câbles et d’ordinateurs, jusqu’ici rien d’anormal. Mais ils contiennent également un grand nombre d’équipements audio/vidéo splitter (genre de multiprise pour câbles d’antennes, ou câbles vidéo), de un à 4 téléviseurs directement posés sur les bureaux des testeurs, des décodeurs et leur télécommandes partout et mêmes des murs de tests, sortes de grandes colonnes sur lesquels sont montés 4 téléviseurs et munis de plateaux sur lesquels reposent, devinez quoi ?… Et oui, d’autre décodeurs numériques bien sûr.

Au quotidien, dans ces bureaux, les téléviseurs fonctionnent en permanence, affichant des programmes de tous les pays du monde, des films, les infos, les programmes des chaines musicales, et il n’est pas rare de croiser des testeurs, statiques devant une ou plusieurs télé, une télécommande à la main. Ne vous méprenez pas, cette personne travaille, et une partie de son travail consiste précisément à regarder la télé.

Ouah mais c’est trop bien, je veux faire le même travail !!!

Ne vous emballez pas, leur tâche est plus complexe qu’il n’y paraît. Lorsqu’ils semblent se relaxer devant un film récent, ils sont en réalité en pleine concentration, suivant un protocole de test précis, relevant dans le détail les observations qu’ils font sur le comportement du décodeur, suite aux commandes qu’ils lui ont envoyées au cours du test.

Voici quelques exemples de tests fréquents qu’ils peuvent être amenés à effectuer.

Tests fonctionnels

CAS, ou Conditionnal Access System

Outre le décodage du son et de l’image, fonctions principales du décodeur numérique, de nombreuses fonctions secondaires existent, et parmi elles, le CAS pour Conditionnal Access System.

Comme son nom l’indique, la mission du CAS est de contrôler l’accès des utilisateurs à certains programmes en fonction de leur contenu et du contrat souscrit par l’abonné. Je suis abonné à Sci-Fy, ma carte d’abonné le sait et autorise mon décodeur à afficher la chaîne. La plupart des décodeurs câble, satellite ou TNT (le cas des décodeurs IPTV est un peu différent) possèdent une fente destiné à l’insertion d’une carte puce, la smartcard. Il s’agit de votre carte abonné, permettant de d’identifier votre compte et toutes les chaines auxquelles vous avez souscrit. Ainsi pour tester le CAS, le testeur doit par exemple :

  • Vérifier avec plusieurs cartes possédants des droits différents, que seules les chaines payantes souscrites et les gratuites sont accessibles, les autres devant afficher un message permettant de s’abonner.
  • Insérer / Retirer plusieurs fois la smartcard du décodeur, et vérifier qu’à chaque insertion, la chaîne payante souscrite s’affiche, puis disparaît lors du retrait de la carte.

Contrôle parental

Houlalala, que c’est important, nous l’avons vu un peu plus tôt. La vérification du contrôle parental est capitale, on ne veut surtout pas que le Conseil Supérieur de l’Audiovisuel (CSA) nous tombe dessus !

Les tests associés sont assez amusants (en tout cas, je les trouve amusants…). Pour les voir en cours d’exécution, le mieux est d’être matinal.

Une explication s’impose. Pour tester le contrôle parental, il faut tout d’abord le configurer, c’est à dire saisir un code parental sur le décodeur en précisant le type de contenu protégé par mot de passe, violence, horreur, contenu adulte,…

Ce type de film étant généralement diffusé en dehors des heures de travail, le testeur peut par exemple programmer l’enregistrement, pendant la nuit, de programmes sensibles.

Le lendemain, il revient travailler, se place en face de son mur de test, devant ses quatre téléviseurs, et joue les enregistrements effectués durant la nuit. Objectif, vérifier que chaque enregistrement exige bien la saisie du code parental avant de démarrer.

Le produit étant en cours de développement, il arrive souvent que la fonctionnalité ne soit pas 100% opérationnelle, ou que le testeur saisisse le code parental pour contrôler le bon affichage de la vidéo.

         Mais pourquoi il a dit qu’il fallait être matinal ?

Eh bien parce que certaines situations peuvent être quelques peu gênantes, quand par exemple, un de vos confrère a oublié d’éteindre l’ampli audio utilisé la veille sur le même mur vidéo, dans le cadre d’un test de volume, et que des sons d’un genre douteux résonnent soudain dans les couloirs de la R&D au lancement de vos enregistrements, attirant progressivement tous vos collègues derrière vous pour admirer vos qualités de testeur expérimenté.

C’est la raison pour laquelle il est parfois souhaitable d’effectuer ces tests avant l’arrivée de vos collaborateurs.

Redémarrage

Le test de redémarrage ou reboot, consiste à démarrer un décodeur, s’assurer qu’il a terminé son démarrage, qu’il affiche soit le menu principal, soit une chaîne de télévision, puis de débrancher et rebrancher le cordon d’alimentation afin d’observer le comportement lors de la séquence de démarrage.

Ce test est très intéressant car durant cette phase de fonctionnement, le décodeur active un grand nombre de processus ce qui est très consommateur de ressources. Identification de version du firmware, recherche de nouvelles versions, téléchargement/installation le cas échéant, chargement et démarrage de l’application, démodulation, décodage du flux audio / vidéo, récupération des données de l’EPG… et j’en passe. Comme pour tout système embarqué, la gestion des ressources est un élément important pour lequel le test est indispensable.

Test de navigation dans les menus

Un test qui s’apparente au free testing, pour lequel, le testeur muni de son Excalibur, bon ok sa télécommande, va se balader librement dans les différents menus, menu principal, grille des programmes, navigation avec les flèches dans la grille des programmes, sélection d’un programme, ouverture du menu de vidéo à la demande (VOD), etc… Afin de détecter d’éventuels problèmes d’affichage, ou toute séquence d’actions pouvant entraîner un redémarrage imprévu du décodeur par exemple.

Pour ce test, bien qu’il n’existe pas de protocole prédéfini, il est primordial que le testeur documente l’ensemble des actions effectuées à des fins de reproductibilité.

Il ne s’agit pas ici d’appuyer au hasard sur les touches de la télécommande et de dire : « Il y a un problème ! », l’objectif est bien de se rapprocher du comportement d’un utilisateur mais en spécifiant action par action la séquence menant à une anomalie.

Conclusion

Il existe une multitude d’autres tests fonctionnels, le timeshifting, les enregistrements, la VoD, le zapping, etc… Le but de cet article n’est pas de tous les décrire, mais de donner une idée du type de test pouvant être menés sur un applicatif de décodeur numérique.

Dans le prochain épisode de la saga de l’audiovisuel, nous aborderons le sujet des tests non fonctionnels en télévision numérique.

Saga de l’audiovisuel – Présentation et enjeux du test

Saga de l’audiovisuel

Présentation du test audiovisuel

« Et voici la couleur, au jour fixé et à l’heure dite… »

Déclarait solennellement et avec fierté, Georges Gorces, alors ministre de l’information, le 1er Octobre 1967 à 14h15, à l’occasion de cette prouesse technologique que fut l’arrivée de la couleur sur nos petits écrans. Déclaration qu’il poursuivit par : « Vous cesserez très vite, je le sais bien, d’être sensibles à la magie de la chose. » Et il n’avait pas tort.

A l’époque, Huguette regarde tranquillement son épisode de chapeau melon et bottes de cuir sans se soucier de la qualité médiocre du son et de la vidéo, et demande simplement à René de taper 3 fois sur le poste de télévision lorsque la réception se dégrade. Notre attitude devant nos films et nos émissions préférés a bien changé. Ma vidéo est saccadée, j’appelle mon fournisseur d’accès internet, le son est mauvais, je renvoie ma télé chez Darty, un problème de réception satellite : « Allô Sky, je ne suis vraiment pas content ». Les évolutions technologiques en matière d’audiovisuel nous ont été offertes doucement, au fil du temps, augmentant insidieusement notre niveau d’exigence.

Pourtant, un simple coup d’œil 50 années en arrière permet de prendre conscience du chemin parcouru. Diffusion par câble, satellite et IP, télévision numérique, multiplication du nombre de chaines, qualité HD, Ultra HD, son Dolby Digital. En consommateurs exigeants que nous sommes, nous donnons toujours plus de fil à retordre aux industriels de l’audiovisuel, qui se doivent d’être irréprochables sur la qualité des services proposés, et qui dit qualité dit bien évidemment test. Cet article a donc pour objectif de présenter les méthodes et outils de test dans ce domaine bien particulier qu’est la télévision numérique. Bien que de nombreux types de tests existent dans cette industrie (Hardware, infrastructure, CEM, résistance au choc des décodeurs numériques, etc…), je vous propose de concentrer notre attention sur les tests logiciels d’un organe central de la télévision numérique, le décodeur.

 

Le décodeur numérique..

… ou STB (Set Top Box) pour les intimes, est partout,  dans votre salon, votre chambre, ou peut être votre cuisine. Depuis la disparition en France de la télévision analogique hertzienne le 29 Novembre 2011, cet appareil est nécessaire pour profiter des merveilleux programmes proposés par le service public et privés, et si quelques sceptiques se disent encore :

 

Mais il est fou, j’ai jamais acheté de décodeur moi, je ne sais même pas à quoi ça ressemble !

 

Je vous confirme que vous faites fausse route, votre décodeur est peut-être caché dans votre modem ADSL, votre télé ou encore votre tout nouveau lecteur Blu-ray, mais il est bel et bien là.

Le décodeur est un appareil électronique dont le rôle premier est de récupérer un signal numérique (flux) provenant de votre réseau câble, internet, Satellite ou TNT, puis de le convertir en signaux audio et vidéo pouvant être joués sur votre téléviseur.

Les décodeurs actuels possèdent de nombreuses fonctionnalités secondaires comme l’enregistrement de programmes, le timeshifting (possibilité de stopper, puis de reprendre un programme diffusé en direct), l’EPG (Electronic Program Guide) permettant d’afficher en temps réel des informations concernant les programmes en cours et à venir, et bien d’autres.

Un décodeur est constitué de différentes couches matérielles et logicielles, comme le décrit le schéma simplifié suivant :

                       

  • La couche Hardware : segment matériel du décodeur, il s’agit du circuit électronique sur lequel sont assemblés les différents composants électroniques de l’appareil (microprocesseur, démodulateur, convertisseurs CAN et CNA, …)
  • La couche driver : fournit les briques logicielles nécessaires au pilotage des composants de la couche Hardware
  • Le middleware : il s’agit de l’interface logicielle entre la couche driver et l’applicatif, ces deux dernières ne parlant pas le même langage, la fonction du middleware est donc de rendre possible la communication entre les drivers et l’applicatif
  • L’applicatif : c’est l’interface utilisateur, celle que vous voyez au démarrage de votre décodeur, et avec laquelle l’utilisateur peut interagir via sa télécommande pour changer de programme, baisser le volume sonore ou bien démarrer l’enregistrement d’un programme.

Nous allons nous intéresser plus particulièrement à cette dernière couche, l’applicatif, celle avec laquelle notre utilisateur final, vous, moi, nous quoi, avons un contact direct.

 

Les enjeux du test en télévision numérique

Dans l’industrie audiovisuelle, minimiser la probabilité de présence d’une anomalie logicielle est essentiel.

En effet, un défaut matériel ou logiciel peut avoir un impact considérable tant sur le plan économique, qu’en termes d’image.

Un décodeur numérique est un produit grand public, et pour cette raison, il est produit et distribué en très grandes quantités, par millions. Comment réagiriez-vous en tant qu’utilisateur, tout content de déballer votre tout nouveau décodeur avec diffusion en 4k de MoMoMotus, si vous constatiez un problème lors de l’installation, ou des coupures de son répétées, pile sur les bonnes blagues de Thierry Beccaro ?  

Risques liés à la non qualité

Vous réagiriez très probablement comme des milliers d’autres déballeurs de décodeurs, par des appels répétés au service après vente. Ces appels, multipliés par le nombre important de clients insatisfaits mobilisent de nombreuses ressources, exigent un certain temps de traitement, notamment pour des problèmes complexes nécessitant un support de niveau 2.

Le traitement de ces milliers de cas clients représente un coût important pour l’opérateur. Il arrive également que les problèmes remontés par les clients à l’opérateur mette en évidence un défaut du produit. Dans ce cas, le fabricant doit mobiliser des équipes pour identifier et corriger l’anomalie, au détriment des autres projets en cours de développement. Ce genre de « crise » entraîne à son tour des coûts non négligeables et un risque de retard de livraison pour les autres projets.  

Risques de manquer une technologie

Cela peut encore aller plus loin, jusqu’au rappel des produits. Là, il ne s’agit plus seulement d’une histoire de coût mais également de la perte potentielle d’un marché au profit de vos féroces concurrents qui n’attendent qu’un faux pas de votre part pour s’approprier, à vos dépens, la place de leader de l’intégration de la toute dernière techno de compression audio ou vidéo dans leur terminaux résidentiels. Et il ne se privera pas d’en faire mention sur les salons, les forums hi-tech et autres réseaux sociaux.

Risques de dégradation de l’image de l’entreprise

Une autre fonctionnalité des décodeurs numériques est le contrôle parental. Souvent activé par défaut, il exige un mot de passe pour pouvoir jouer un programme au contenu interdit au mineurs, généralement des programmes contenant des scènes de violence ou de pornographie. Une défaillance du contrôle parental pourrait donc permettre à n’importe quel bambin jouant avec la télécommande de tomber sur un programme qui ne lui est pas destiné.

Ce genre de situation est bel et bien arrivé. Pas à ma connaissance sur les décodeurs numériques, mais dans le cadre de la diffusion de programme par internet (webTV) du groupe Canal+.

Ainsi le 15 Avril 2012, à 13h40, confortablement installés devant leur écrans, parents et enfant s’apprêtait à digérer leur repas dominical devant le dernier opus de la saga Arthur et Minimoys, de Luc Besson. Malheureusement, une défaillance technique sur les serveur de diffusion de la webTV a provoqué la diffusion accidentelle d’extraits de films pour adulte. Suite à cela, les abonnés concernés par le problème ont exprimé leur colère sur le forum du diffuseur, puis au tour des médias de s’emparer de l’affaire, RTL, Ouest-France, France tv info, … Compliqué pour le groupe de justifier un tel problème. La chaîne a dû présenter ses excuses aux abonnés tout en affirmant que la cause du problème avait été identifiée et ne se reproduirait plus.

En règle générale, ces risques sont connus, et bien que quelques rares problèmes passent les mailles des filets comme nous venons de le voir, de nombreux tests sont effectués dans l’industrie audiovisuelle afin de détecter et de corriger le maximum d’anomalies avant que les produits ne soient en utilisation chez les clients.

 

Conclusion

Les technologies de l’audiovisuel se sont démocratisées en quelques 50 années, et désormais, lorsque nous passons devant une nouvelle télévision 4K, ou un décodeur numérique dernier cri, cela semble banal. Il s’agit pourtant d’une industrie de pointe, en constante évolution, qui, à ce titre, nécessite une politique de test aux contours bien définis pour éviter entre autres, des catastrophes économiques et marketing.

Nous arborderons, dans le prochain article, le fonctionnement d’une cellule de validation pour décodeurs numériques ainsi que des exemples de tests courants. 

30 Days of Security Testing – Partie 4/4 : Aller plus loin

Le principe

Notre série d’article sur le défi de Ministry of Testing30 Days of Security Testing, se termine aujourd’hui avec un article dans lequel sont regroupé les défis qui permettent d’enrichir sa connaissance générale des tests de sécurité (actualités, aspects sociologiques, mises en application).

  1. Compulser la documentation
  2. Apprendre les bonnes pratiques
  3. Découvrir les outils
  4. Aller plus loin

Les challenges

Défi 10 : Comprendre ce qu’est l’« ethical hacking » & Défi 30 : Découvrir la différence entre les hackers black hat, white hat et grey hat

Pour rappel, en anglais « to hack » veut simplement dire « bidouiller », il n’y a pas de connotation négative en soi.

Alors que le hacker malveillant (ou black hat) tire profit des failles de sécurité à des fins personnelles, l’ethical hacker (ou white hat) les documente et propose des pistes afin de les solutionner. Il est en possession de toutes les autorisations nécessaires pour entrer dans le système à tester.

Comme vu précédemment, certaines entreprises embauchent des spécialistes en tests de sécurité (qui, par nature, sont des ethical hackers) afin de réaliser un audit. D’autres choisissent de récompenser les personnes qui leur rapportent bénévolement des failles de sécurité découvertes dans les limites de la légalité. Ces récompenses sont appelées « bounties ».

Si le hacker entre dans le système sans disposer des autorisations nécessaires, mais ne commet aucun acte malveillant, on parle de hacker « gray hat ». Des sites comme CVE Details (common vulnerabilities exposure) ou NVD (National Vulnerability Database) répertorient les failles de sécurité d’une multitude de produits.

L’imagerie populaire du hacker est déconcertante : nous serions tentés de croire que tous portent une capuche en permanence. En cause, une méconnaissance de l’activité de hacking, comme en témoigne cette interview d’un photographe de la banque d’images Shutterstock. Il serait pourtant utile que l’activité de hacking, de même que la sécurité informatique, soit mieux comprise, afin que chacun puisse mettre en oeuvre le nécessaire pour se protéger.

Défi 17 : Trouver une faille de sécurité récente

Lorsqu’une faille de sécurité est découverte dans un SI, volontairement ou non, le fait de la rapporter à l’organisation concernée sans exploiter la faille est appelé « disclosure ». Un acte bénévole dont il peut être risqué de parler, comme l’a montré en 2009 l’affaire Forever living products contre Zataz. Le fait de rendre une faille publique avant sa correction (chose que n’avait pas fait Zataz) est appelé « full disclosure ».

L’équipe Project Zero, qui regroupe sous l’égide de Google des spécialistes en sécurité informatique, a pour objectif de trouver des failles de sécurité « zero day », c’est-à-dire n’ayant jamais été exploitées. Leur ligne de conduite : informer immédiatement l’organisation responsable de l’application (disclosure), et ne procéder à une full disclosure qu’après que celle-ci a fourni un patch, ou au bout de 90 jours.

Le 25 novembre dernier, Google a informé Microsoft d’une faille de sécurité présente dans les navigateurs Internet Explorer et Edge. Malheureusement, Microsoft n’a pas été en mesure de fournir un patch dans les temps, et la faille est désormais publique et exploitable même dans la dernière version ! Voici son ticket d’anomalie.

Défi 20 : S’informer sur les attaques DOS/DDOS.

Une attaque DDOS (Distributed Denial Of Service) est une attaque visant à rendre indisponible un serveur. Son qualificatif « Distributed » est employé lorsque l’attaque provient de plusieurs machines différentes. Lorsque l’origine est une unique machine, on parle simplement d’attaque DOS.

On peut distinguer les attaques DDOS réseau et applicatives. Dans le premier cas, on sature la connexion réseau d’un serveur afin de le rendre incapable de répondre aux requêtes. Dans le second, après identification des actions de l’application qui demandent beaucoup de ressources (par exemple, des calculs impactant de nombreuses lignes en base de donnée), l’attaque consiste à les répéter jusqu’à saturation du serveur (source).

Un site web permet de visualiser sur une carte les récentes attaques DDOS.

Défi 23 : Quelles sont les 10 menaces de sécurité les plus courantes en 2016 ?

La liste des 10 failles de sécurité les plus courantes est éditée tous les trois ans par la fondation OWASP. La liste qui devait paraître en 2016 a été repoussée en 2017. L’équipe OWASP explique que le classement est resté sensiblement le même. Voici donc le classement de 2013.

Défi 26 : Comparer les tests de sécurité web et mobiles

Les tests à effectuer dépendent des menaces inhérentes à un système donné.

Certaines menaces sont propres aux applications web, comme les vulnérabilités liées aux cookies. Ces petits fichiers, stockés sur la machine cliente au cours de la navigation, qui contiennent des informations utiles : pages visitées, actions effectuées sur le site, mots de passe.

D’autres sont spécifiques aux applications mobiles, qui demandent des permissions susceptibles de compromettre les informations personnelles de l’utilisateur.

Mais les frontières des menaces tendent à se brouiller, notamment avec l’essor de frameworks tels que Cordova ou Ionic, qui permettent de développer des applications mobiles en se servant de technologies web. Les applications mobiles ne sont plus, logiquement, à l’abri des injections Javascript.

Défi 27 : Comment la tendance BYOA peut-elle affecter la sécurité ?

BYOA signifie « bring your own application » : cette tendance désigne par exemple les employés utilisant Google Docs avec leur compte personnel en lieu et place du SharePoint de leur entreprise. On parle aussi de shadow IT.

Plusieurs points peuvent être soulevés :

  • En stockant des informations sur un outil tiers de son choix (souvent un cloud), l’utilisateur endosse la responsabilité de leur sécurité et devient en même temps dépendant du niveau de sécurité de l’application choisie. Un aspect que ni lui, ni son entreprise, ne maîtrisent. Un éditeur de bonne foi n’est pas à l’abris d’une fuite de données. En outre, l’utilisation des données stockées sur un outil tiers ne peut pas être entièrement maîtrisée.
  • En cas de vol de son ordinateur, l’utilisateur est le seul à pouvoir mettre en oeuvre la protection de ses données (changement immédiat des mots de passe).
  • En cas de vol d’identifiants, l’utilisateur n’a plus aucune prise sur l’utilisation du contenu qu’il a stocké sur un outil tiers.

Pour répondre à ces risques, certaines entreprises mettent en place une politique d’utilisation de logiciels tiers afin de sensibiliser aux menaces de cette tendance et de responsabiliser les employés.

Défi 28 : Partager des idées concernant les tests de sécurité dans un domaine particulier

Nous avons choisi de ne pas nous pencher sur un domaine en particulier, mais plutôt sur un type d’applicatif que nous utilisons quotidiennement : les logiciels open-source.

Logiquement, les failles d’un logiciel open source sont plus susceptibles d’être découvertes par le public que celles d’un logiciel propriétaire. Mais elles sont également plus susceptibles d’être révélées à son éditeur par la communauté, et donc plus vite corrigées. A contrario, les failles d’un logiciel propriétaires ne sont susceptibles d’être découvertes que par son éditeur lui-même, ou par les hackers black et grey hat. Les logiciels propriétaires ne sont pas à l’abris du reverse engineering, une pratique pourtant souvent interdite par les conditions générales d’utilisation.

Voici quelques articles ressources que nous avons trouvé sur le sujet :

… Défi 15 : S’exprimer sur les tests de sécurité sur les réseaux sociaux ou un blog

Voilà qui est fait. Déjà la fin des 28 jours de test de sécurité ! Si vous aussi avez participé au défi, laissez-nous un commentaire avec vos articles de blog, nous sommes curieux de les lire.

Découvrez nos autres séries d’articles !

Notre saga du test audiovisuel

Le kit de secours métaphorique du testeur agile

Notre série dédiée à Protractor