Fire at the QA department

La semaine dernière a été riche en événements. Alors que Microsoft sortait sa nouvelle version d’Internet Explorer (version 8), à  Vancouver la CanSecWest fêtait sa dixième édition.

Le fil conducteur entre ces deux événements s’appelle Nils, un jeune étudiant Allemand. Il a réussi à  mettre à  mal la sécurité des trois navigateurs web les plus utilisés (dont Internet Explorer 8), et ceci sur une machine à  jour.

“A toute chose, malheur est bon” dit l’adage. C’est ce que les personnes de Microsoft ont dû se dire lorsque Nils a fait son show. A peine sorti, une faille critique permettant de prendre le contrôle à  distance de la machine est trouvée sur leur bébé. Point positif, cet événement aura été révélateur de talent.

Suite à  son interview avec Ryan Naraine, Nils a déclaré qu’il voulait voir les failles de sécurité résolues. C’est pourquoi les détails techniques de la vulnérabilité ne seront pas communiqués jusqu’à  ce qu’un correctif soit prêt.

On imagine la déception du département QA (quality assurance) qui a dû passer quelques mois à  tester le soft. Il est difficile de rendre coupable telle ou telle équipe surtout lorsqu’on voit les délais imposés pour tester le produit dans les différents environnements ainsi que les tests de coexistence. Les tests de sécurité sont souvent la 5ème roue du carrosse. Dans un but d’amélioration de processus, j’imagine que chez Microsoft, les responsables du projet vont faire leur enquête pour trouver pourquoi une telle faille est passée à  travers les mailles du filet.

Un jour après avoir publié l’interview de Nils, Ryan Naraine écrit un nouvel article dont l’intitulé est “No more free bugs”. Cet article est intéressant car il soulève un problème critique au sein des entreprises qui dévéloppent des logiciels : La chasse aux Bugs.

Dans la “chaîne alimentaire” d’un logiciel, nous rencontrons trois étapes majeures :

Une fois que le produit est testable (tests unitaires effectués suivant les requis de la fonctionnalité et validés par le développement), l’équipe de développement (souvent découpé en plusieurs petites équipes) délivre le produit à  l’équipe de test (elle aussi découpé en plusieurs équipes). Ces dernières vont travailler main dans la main.

La chasse aux bugs est ouverte.

Il est utopique de penser qu’une application est délivrée sans bug. L’objectif est d’avoir un produit le plus stable  possible. La majorité des tests est fait en suivant des procédures types (suivant le standard international Common Criteria), ce qui rend assez stérile le fait de trouver de nouvelles failles surtout lorsqu’il y a de nouvelles fonctionnalités, car les cas de tests n’ont pas encore été tournés. Sachant que l’ordre des tests ne peut pas être inter changé dans le processus et que le temps est incompressible, vous comprenez maintenant pourquoi il existe un commerce underground d’achat de bugs. Il faut savoir que plus le defect est trouvé tôt, moins il coûte.

Les personnes comme Nils sont très utiles car elles ramènent du sang neuf dans le processus. Les départements de tests/QA sont comme des régulateurs que l’on ajuste en fonction des données en entrée. On interagit sur le PID en espérant obtenir la meilleure régulation, mais tant que la valeur d’entrée change, il est difficile de trouver le bon coefficient. Ce qui m’amène à  dire que les départements de tests ont encore de beaux jours devant eux.