En coulisses : Rapport de l’un des sprints Creo 1.0

Dans un article précédent, nous avons présenté Scrum, la méthode interne utilisée par PTC pour le développement de Creo. Scrum fournit à nos équipes R&D une approche progressive à la gestion de projet réussie. Mais prend-elle réellement en considération les personnes qui utiliseront le logiciel après sa sortie ?

Michael Pfrommer, vice-président de Creo chargé du développement de produits, pense que les clients de Creo auront de nombreux avantages à retirer de la méthode Scrum, car celle-ci garantit la pertinence et la fiabilité des nouvelles versions.

Dans la suite de l’interview, Michael Pfrommer décrit en détail les tests réalisés sur Creo et comment nous décidons du moment où une nouvelle version doit sortir :

GH : J’ai souvent entendu dire que PTC « intègre la qualité » lors du développement de logiciels. Que voulez-vous dire par là ?

Michael Pfrommer : Chez PTC, nous encourageons nos développeurs de logiciels à « intégrer la qualité » lors de la conception et du développement des fonctionnalités d’un produit. Nous consacrons du temps en amont à nous assurer que les exigences sont clairement définies, que les conceptions fonctionnelles sont révisées et approuvées par l’équipe, et que les développeurs réalisent un pré-test des modifications de code dans leur environnement de développement local avant de le renvoyer vers le flux principal de développement du logiciel.  Nous nous efforçons de suivre une logique d’intégration de la qualité dès les phases de conception et de codage.

GH : Vous avez précédemment indiqué que durant chaque période de développement ou sprint, l’équipe crée un produit potentiellement livrable. En d’autres termes, tous les ajouts réalisés lors du sprint fonctionnent correctement avant que vous ne passiez à l’ensemble de nouvelles fonctionnalité ou de correctifs suivant . Pouvez-vous nous décrire en quoi consiste le test d’un sprint ?

Michael Pfrommer : Vous avez tout à fait raison, il est essentiel que chaque sprint soit fonctionnel et testé. C’est pourquoi, après seulement quelques semaines de développement, nous réalisons un test du code. Des contrôles individuels sont effectués sur toutes les fonctionnalités, qu’elles soient nouvelles ou mises à jour.

GH : De manière aléatoire ? De manière méthodique ?

Michael Pfrommer : De manière stratégique. Les cycles de tests se décomposent généralement en cinq étapes principales :

  1. Accord préliminaire. Dans un premier temps, nous nous mettons d’accord sur les éléments qui vont être testés. Il s’agit du plan de test. Celui-ci est généralement élaboré à partir d’une association de spécifications produit, d’une définition et de critères d’acceptation.
  2. Documentation des tests. Cette étape consiste à documenter les tests, essais-types, conditions de réussite et, si possible, à construire un test automatisé.
  3. Exécution des tests.
  4. Cette étape consiste à établir des rapports, à effectuer le suivi et à gérer les résultats des tests.
  5. Identification des tests ayant échoué et établissement d’un ordre de priorité.

GH : Automatisez-vous un grand nombre de tests ?

Michael Pfrommer : Oui. Tous les qualiticiens développent en continu des tests automatisés et construisent des suites de tests toujours plus complètes destinées à tester tous les aspects du sprint. Pour Creo, nous exécutons plus d’un million de tests automatisés avant de sortir une version sur le marché.

GH : Comment réussissez-vous à traiter les résultats de tous ces tests ?

Michael Pfrommer : Pour chaque test, le résultat obtenu est soit Pass (le test a été exécuté et ses résultats étaient corrects), Fail (le test a été exécuté mais ses résultats étaient incorrects) ou OK to Fail (le test a été exécuté, les résultats ont été analysés et le test doit faire l’objet d’une mise à jour). Nous procédons de même avec tous les tests réalisés pour chaque sprint et obtenons ainsi un aperçu objectif de la qualité de chacun d’eux.

GH : Après avoir complété un certain nombre de sprints, vous obtenez un candidat de sortie potentiel ?

Michael Pfrommer : Oui. Le propriétaire du produit indique que le cahier des charges produit a été respecté et définit cette version de code comme candidat de sortie.

GH : Pourquoi chaque sprint n’est-il pas considéré comme un candidat de sortie potentiel ?

Michael Pfrommer : Eh bien, nous prenons en compte un ensemble de facteurs. Le propriétaire du produit doit décider si le logiciel est suffisamment complet pour apporter de la valeur ajoutée à nos clients. Si une version sort prématurément, le produit ne répondra pas à leurs besoins. Si elle sort trop tard, il se peut que les clients aient trouvé une autre solution, et PTC aura alors raté une opportunité de ventes.

Nous nous demandons également quelle a été l’évolution du marché. Comment les affaires ont-elles évolué ? Peut-être avons-nous acquis une technologie ou un produit qui peut nous aider à mieux satisfaire les exigences du client, ou peut-être qu’un partenaire a développé une solution adaptée.

En fin de compte, nous considérons que chaque fois que nous attribuons à une version le statut de candidat de sortie potentiel, elle entre dans une phase de test de plus grande ampleur qui implique l’intervention d’un nombre de personnes encore plus grand. Ces tests à plus grande échelle impliquent l’intervention d’un plus grand nombre de personnel interne, de partenaires logiciels et de clients. Tout ceci demande beaucoup d’efforts et nous ne souhaitons le faire qu’une fois que nous sommes sûrs de l’impact positif qu’aura la sortie de la nouvelle version.

GH : Pouvez-vous nous décrire les phases de ces tests à plus grande échelle ?

Michael Pfrommer : Nous considérons le produit dans son ensemble. Par exemple, dans le cas d’un candidat de sortie :

  • Nous prenons en compte d’autres aspects que la seule qualité fonctionnelle, comme les performances, la fiabilité, la convivialité, l’évolutivité, la facilité d’entretien et la compatibilité.
  • Nous exécutons des tests sur un grand nombre de machines et de plates-formes en utilisant le candidat de sortie en dehors de l’environnement de construction du développeur.
  • Nous procédons à un beaucoup plus grand nombre de tests manuels, comme par exemple, en sortant une version beta du logiciel pouvant être partagée avec des testeurs du monde entier.
  • Nous testons la compatibilité avec nos autres produits.
  • Nous testons toutes les langues et toutes les configurations de langues prises en charge.
  • Nous fournissons une version du candidat de sortie à nos partenaires éditeurs de logiciels et constructeurs de plates-formes afin que ceux-ci puissent associer leurs offres à notre version la plus récente du logiciel.
  • Nous consignons toutes les étapes ci-dessus, établissons des rapports, le suivi, la gestion et la résolution des erreurs critiques.

GH : Ces tests sont donc aussi importants que les sprints.

Michael Pfrommer : Oui. Les deux sont importants. Je vois trois avantages à la méthode Scrum. Premièrement, la stabilité du produit tout au long de son développement. Nous voulons nous assurer que nos clients sont contents et attendent chaque nouvelle version avec impatience. Nous voyons chaque sprint comme une progression rapide dans l’évolution du produit. C’est une approche transparente et par étape – les résultats sont visibles en l’espace de quelques semaines et nous pouvons en faire la démonstration à nos clients.

Deuxièmement, il est possible de changer d’avis, en cours de projet, sur ce qui est souhaitable et indispensable. Avec les nouvelles technologies de Creo, Scrum offre une plate-forme permettant de gérer les problèmes imprévus qui ne peuvent pas être facilement résolus de façon classique par prévision ou planification.

Troisièmement, à l’issue de chaque sprint, nous avons un candidat de sortie potentiel.

GH : Quelle importance PTC accorde-t-il à cette phase de test sur l’ensemble du développement de produits ?

Michael Pfrommer : Plus d’un million de tests automatisés sont effectués et 20 % de notre capacité totale de développement de produits est dédiée aux tests. Pour Creo 1.0, nous prévoyons d’investir plus de 200 000 heures en tests manuels, et ce, sans compter les milliers d’heures passées par nos clients, nos partenaires éditeurs de logiciels et constructeurs de plates-formes et autre personnel externe.

GH : Avec tous ces tests automatisés, pensez-vous qu’un jour les tests manuels seront supprimés ?

Michael Pfrommer : Non, je ne peux pas imaginer cela.  Nous pouvons réduire les problèmes au minimum de différentes manières. Par exemple, aller jusqu’aux fondements de l’application permet d’en réduire la complexité et implique l’utilisation d’un moins grand nombre de lignes de code. Mais nous réaliserons toujours des tests, et nous aurons toujours besoin qu’une personne utilise le logiciel pour détecter les défauts les plus bizarres, et parfois les plus évidents.

Ne ratez pas les prochains articles de la section « En coulisses » dans lesquels nous ferons le point sur l’état actuel de Creo 1.0.

Cet article a été publié dans En coulisses avec les mots-clefs : , , . Bookmarker le permalien. Laisser un commentaire ou faire un trackback : URL de trackback.

Poster un commentaire

Votre e-mail ne sera jamais publié ni communiqué. Les champs obligatoires sont indiqués par *

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <pre> <q cite=""> <s> <strike> <strong>