Avant d'entrer dans le vif du sujet, revenons à la notion de qualité logicielle pour détourer quels aspects de celle-ci nous allons traiter. Voyons ensuite les "symptômes" du développeur qui ne teste pas ou teste mal. Enfin, nous expliquerons pourquoi ce livre devrait susciter l'intérêt du lecteur concerné.
La qualité logicielle ?
Une notion subjective.
Selon les points de vue, la qualité logicielle n'a pas la même définition.
Autant de préoccupations différentes pour un même produit. Dans ce qui suit, nous allons plutôt nous intéresser à la qualité du logiciel telle qu'elle est perçue par le développeur.
La nécessité d'assurer un suivi de la qualité logicielle.
Pour vous convaincre de la nécessité d'intégrer dans toute démarche de développement (qu'elle se fasse dans le cadre d'une entreprise, d'un projet institutionnel, d'une réalisation bénévole en logiciel libre) une approche raisonnable de la qualité logicielle, nous pourrions lister les plus fameuses défaillances de l'histoire de l'informatique et d'autres domaines de l'ingénierie.
Sans nous lancer dans le récit exhaustif de ces grandes catastrophes techniques dont les plus fameuses ont coûté des vies humaines tandis que d'autres ont gaspillé des milliards de budget, citons tout de même quelques cas où une défaillance informatique s'est avérée responsable au moins en partie d'une catastrophe :
Ces projets sont bien sûr hors du commun et sont bien différents de ceux que chaque entreprise, ingénieur ou développeur rencontrera dans sa carrière. Souvent, le risque causé par une panne est plus limité. Toutefois, de nombreux projets nécessitent un haut niveau de sureté de fonctionnement :
Néanmoins, même pour les projets ne requérant aucun niveau de sécurité, la présence de bogues provoquant la défaillance d'un système peut engendrer des coût imprévus voire mener à l'échec d'un projet, ce qui est déplaisant pour tous les intervenants. En 2002, une étude commandée par le National Institute of Standards and Technology conclue que les bogues et les erreurs logiciels coûtent chaque année 59 billions de $ à l'économie américaine soit 0,6 % du PIB.
Les mauvaises pratiques ou « À qui s'adresse ce livre ? ».
Si, lorsque que vous constatez l'apparition d'un bogue dans un programme que vous êtes en train de développer, vous adoptez le comportement suivant :
Cette démarche, en plus d'être coûteuse en temps, est inefficace. Elle est difficile à mettre en œuvre dans une grande base de code lorsqu'on ne sait pas d'où le bogue peut venir. De plus, tout ce travail est perdu étant donné que si un bogue similaire réapparaît, il faudra remettre les traces dans le code en espérant ne pas avoir déjà oublié comment le bogue était apparu, et comment il avait été corrigé. Si c'est ainsi que vous procédez, ce livre est fait pour vous !
Si lorsque votre code atteint une complexité suffisamment grande, vous commencez à craindre de faire des modifications sur des portions de code que vous avez écrite il y a longtemps parce que vous ne savez pas si vos modifications risquent de casser quelque-chose sans que vous vous en rendiez compte ; si vous en avez marre de passer 20 % de votre temps à développer et 80 % de temps à chasser les bogues ; si vous perdez de l'argent parce que pour un produit donné, vous passez plus de temps à corriger des bogues gratuitement lors de la période de garantie que de temps à développer le produit en étant payé, alors ce livre est pour vous.
Pour un développeur, pratiquer des tests et vérifications permet de relire le code source, repérer les erreurs et apprendre à les éviter.
Pourquoi vérifier et tester ?
La vérification et les tests sont deux disciplines de la qualité logicielle. Ces techniques, si elles sont adoptées et appliquées rigoureusement et avec intelligence dès le début d'un projet peuvent améliorer significativement la qualité logicielle. 
L'adoption d'une pratique de test systématique apportent de multiples avantages :
Ce livre s'adresse donc aux développeurs qui ignorent les aspects techniques d'une démarche de test logiciel intégrée au processus de développement. C'est une initiation à ces pratiques qui est proposée tout au long de cet ouvrage.
Après la lecture de ce livre, vous serez en mesure :
Remarquons que ces deux disciplines peuvent ne pas être suffisantes et être complétées par d'autres solutions adéquates visant à assurer la qualité logicielle. Remarquons enfin que si la qualité d'un logiciel au sens où nous la traitons ici peut jouer un rôle, elle n'est en rien garante du succès commercial d'un projet.
Quels sont les pré-requis ?
La lecture de ce livre nécessite d'avoir tout de même une expérience même courte du développement en utilisant la programmation orientée objet. Il est bon d'avoir une expérience sur un projet suffisamment complexe pour avoir perçu ce qui est évoqué plus haut.

Développer en Java/Analyse statique de code

L'analyse statique de code permet, sans avoir à compiler ou exécuter le code, de détecter des erreurs, du code suspect ou des pratiques à risques. Certains compilateurs détectent ce genre d'éléments et peuvent avertir le développeur via un message d'erreur. Certains outils sont spécialisés dans l'analyse de code et peuvent rapporter aux développeurs les problèmes rencontrés.
Quelques outils.
Si un environnement de développement est utilisé, celui-ci doit déjà donner quelques informations sous forme d'avertissement. La plupart d'entre eux peuvent être utilisés en ligne de commande ou être intégrés à l'environnement de développement.
De tels outils sont disponibles pour différents langages dans les articles List of tools for static code analysis et Automated code review.
Checkstyle.
Checkstyle permet d'assurer que du code Java respecte bien des conventions. Sur le site officiel on peut trouver une liste des règles que Checkstyle sait vérifier.
L'ensemble des conventions à respecter sont indiquées dans un fichier XML. Il est possible de l'adapter pour inhiber des règles jugées trop contraignantes. L'application est livrée notamment avec un fichier représentant les conventions de Sun, largement adoptées.
PMD.
PMD détecte le code suspect et les mauvaises pratiques :
FindBugs™.
FindBugs permet également d'auditer l'application et de détecter des problèmes potentiels parmi quelques dizaines de problèmes connus. Ces détections concernent aussi bien des mauvaises pratiques que la correction du code, la correction dans un contexte concurrentiel, l'internationalisation, les failles de sécurités, les performances ou les pratiques risquées.

Introduction au test logiciel/Intégration dans le processus de développement