(Mmh, après réflexion ce n'est peut-être pas le meilleur forum pour poster ce topic. Mais ça rejoint un peu le sujet du développement, parce que le testeur développe sans doute de petits outils de test :} ...)

Lu'!

Si, c'est le bon endroit je pense.

Il y a pas mal de choses à prendre en compte dans l'idée de test logiciel. En particulier, s'il y a plusieurs phases dans la création d'un logiciel ou d'une fonctionnalité (selon la forme de développement choisi) : spécification, conception globale (architecture macro), conception précise, implémentation, chacune se voit attribuer ses tests, la conception précise est testée unitairement (pour vérifier que l'implémentation la réalise bien), la conception de l'architecture se voit attribuer les tests d'intégration et la spécification par des essais pour validation.

Les tests unitaires sont généralement une procédure fortement automatisée par des frameworks spécialisés. Une fois les tests d'une fonctionnalité écris, ils devront être rejoués tant que la fonctionnalité ne les a pas tous validés en première écriture, puis chaque fois que la fonctionnalité ou ses dépendances sont modifiées (pour garantir que l'on introduit pas de nouveaux bugs). Certains outils permettent de générer des tests automatiquement à partir des modèles du logiciel.

Je ne connais pas suffisamment les autres types de tests pour en parler.

Généralement, les bugs sont répertoriés dans des bugs tracker, ils sont classés par sévérité, par fonctionnalités touchées, on peut avoir un suivi des tentatives de réparation, des personnes assignées à son analyse, etc.

Quels sont les qualités à avoir ? Être parano et penser à tout.

Je vais en profiter pour faire un peu de pub pour mon domaine . Si les tests sont très forts pour montrer la présence de bugs dans une fonctionnalité, ils sont généralement incapables de montrer leur absence. Si l'on veut montrer l'absence de bugs, il existe des techniques de preuve de code. Ces techniques demandent à la personne en charge de l'implémentation d'une fonctionnalité de spécifier précisément son rôle avec un langage formel. Par la suite, il est possible d'appliquer sur le code + spécification des outils capables de prouver automatiquement que la fonction fait ce qui est écrit dans la spécification. Si les prouveurs manuels n'en sont pas capables, il est également possible d'utiliser des prouveurs interactifs.

Waouh merci pour ta réponse détaillée !!!

Je n'avais jamais entendu parler de preuve de code, c'est intéressant de voir qu'on peut avoir une approche "positive" du test logiciel.

Salut,

Je parle de généralités et j'exclus les tests effectués par les développeurs.

Comment s'effectuent les tests ? Avec quels types de techniques ?

Ils sont soient exécutés par une personne soit automatisés. Dans les deux cas, un rapport est produit.

Les tests automatisés sont exécutés grâce à un langage de script qui contrôle l'application à tester.

Concrètement, à quelle fréquence ou rythme les tests s'effectuent-ils ? En continu ou avant chaque grosse mise en prod ?

Les tests sont plutôt exécutés suite à des évènements plutôt qu'à une fréquence fixe : nouvelle fonctionnalité, après correction d'un bug, sortie d'une version commerciale, etc

Des tests de non regression peuvent être exécutés pour les versions commerciales, des tests automatisés pour chaque build (qui eux peuvent être à fréquence fixe).

Comment communique-t-on autour des bugs ? 

Effectivement un logiciel dédié est souvent utilisé comme déjà dit.

Va-t-on voir le dev au fil de l'eau pour lui expliquer là où ça buggue, faut-il rendre un rapport détaillé, faire des présentations d'équipe ?...

Le testeur peut faire un rapport détaillé (des logiciels l'aident pour cela) et il peut aussi travailler avec le développeur sur un bug plus complexe.

De manière générale, de quelles qualités ou savoir-être a besoin un testeur pour bien faire sont travail ?

Je dirais plutôt qu'un testeur doit être organisé et faire preuve de beaucoup de rigueur.

Salut,

Beaucoup de chose ont déjà été dites mais c'est un sujet vaste.
Je reprends les grandes étapes du développement logiciel pour y évoquer le rôle des tests.

Développement

Tout d'abord un bon développeur doit aussi être un bon testeur. Un développeur est souvent porté à croire que son code fonctionne avant de l'avoir testé, mais dans les faits l'hypothèse de base qu'il doit avoir en tête c'est qu'un ligne de code non testée ne fonctionne pas. Donc s'il veut produire du bon code, il faut qu'il essaie de passer dans toutes les branches de son code pour vérifier qu'il n'a pas fait une étourderie quelconque (en plus d'avoir bien conçu son code pour qu'ils répondrent à tous les besoins fonctionnels et techniques, mais c'est un autre pb).

Le développeur est généralement responsable des TU (Tests Unitaires) sur son propre code, et désormais la bonne pratique est de mettre en place des tests automatiques qui couvrent les lignes de code développé. Ces tests automatiques pourront être déclenchés automatiquement à chaque build (ou à une fréquence donnée) pour faire de la non régression (intégration continue).
Ils permettent de valider l'ajout de fonctionnalité et détecter les problèmes au plus tôt.

Mais le développeur n'est pas le seul à s'occuper des tests (enfin pas sur un projet sérieux/conséquent en tout cas).

Il y a également les "intégrateurs" et les "valideurs".

Intégration

L'intégrateur est en gros celui qui est reponsable d'installer tous les morceaux d'applications sur une plateforme et de faire en sorte que ces modules communiquent bien entre eux. Il fait quelques tests pour vérifier que c'est bien installé, que tous les échanges techniques entre application sont opérationnels, mais côté test, son rôle s'arrête là.

Validation

En général, au moins avant chaque livraison au client, il y a une phase dite de validation. La fréquence de ces livraisons dépendra entièrement du projet, de la phase de celui-ci et des méthodologies (agile ou non) utilisées.

Le rôle des "valideurs" est de vérifier que la version est conforme aux spécifications et de chercher les bugs.
Les valideurs écrivent des "cahiers de recette" qui décrivent tous les scénarios de tests (ces tests pouvant être automatisés ou non).

Un test comprend des prérequis (état et version des composant pour pouvoir dérouler le test) un scénario (une liste de choses à faire) et des attendus (une liste de choses à vérifier).

Ces tests sont généralement déroulés plusieurs fois. Il y a notamment des recettes interne/usine/client : La recette interne est déroullée sans que le client soit impliqué, la recette usine est déroullée avec le client chez le fournisseur avant la livraison, la recette client est effectuée chez le client après la livraison et l'installation de celle-ci (souvent sur une plateforme de pré-production).

Parmis les tests de validation, on retrouve des scénarios dits "nominaux" senser reproduire la manière dont l'application sera utilisée par le client final. Ces scenarios s'appuient sur les spécifications du produits.
On trouve ensuite d'autre de tests plus liés à la robustesse ou sur des points précis que l'on sait à risque.
Chaque anomalie détectée sur un logiciel donne également lui à la création d'un scénario permettant de le reproduire. Ce scénario permet au développeur de comprendre le problème, puis au valideur de valider qu'il est bien corriger dans la version suivante.

Plus les problèmes sont détectés tôt, moins il coute cher (un bug qui passe au travers des tests unitaires, d'intégration et de validation et qui n'apparaît quand production nécessitera, s'il est grave, la création rapide d'un patch qui devra lui même subire toute les étapes de validation avant d'être installé en production).
Dans le cas des patchs, on ne rejoue pas forcément tous les scénarios de tests de l'application. Si seul un composant est touché, on pourra ne rejouer les scénarios de non régression que sur cette partie là, ainsi que le scénario des anomalies corrigée par le patch.

Tests de performance

Dans une branche un peu à part et transverse, on trouve les tests de performances. Souvent les performances sont également spécifiées (le système doit être capable de répondre à X requêtes en Y secondes), donc ils peuvent aussi faire partie du scope de la cellule de validation.
Cependant les problèmes de performances nécessitent souvent des compétences techniques assez poussée (pour identifier et comprendre les problèmes) ainsi que des plateforme spécifiques (afin que les mesures de perfs soit représentative et pas dépendantes d'autres actions exécutées en parallèles, mais aussi à cause de la présence de gros jeux de données qui peuvent gêner les autres tests, et du fait que l'application sera souvent poussée à ses limites et donc sera peu ou pas utilisable).
Bref c'est encore une monde un peu différent, je ne détaille pas plus.

 Outils de gestion des anomalies

Pour les outils, on utilise des outils de "bugtracking" qui permette de référencer les bugs connus et/ou les évolutions. Sur les projets où j'ai travaillé, il y en a souvent un côté client et un côté fournisseur (avec une synchro automatique (partielle) ou non entre les deux).
Il peut n'y en avoir qu'un, par contre côté fournisseur on a toujours une visibilté "interne" et une visibilité "externe" pour distinguer ce qui est en visibilité du client ou non (on ne l'embête pas avec tous les bugs sur les versions internes qui sont détéctés et corrigés sur des versions intermédiaires qui ne lui on pas été livrées).

Qualités du valideur

Parmis les qualités à avoir, la rigueur me semble en effet primordiale.
S'il ne respecte pas scrupuleusement les scénarios de tests, la valideur peut louper des choses. Il ne jamais ce dire j'ai testé ce truc 100 fois, mais la peine que je le fasse ce coup si. Il doit vérifier entièrement les attendus et ne pas ce dire des trucs du genre "à c'est bon, la valeur est OK en BD, pas la peine que je vérifie sur l'écran".
Il doit être attentif au détail

Pour être un bon valideur, il faut aussi qu'il soit capable de sortir des scénarios écris pour faire d'autre tests plus libres où il pourra détecter d'autre problème non couvert pas les scénarios, ou mal décrit dans ceux ci (il faudra qu'il le soit d'autant plus si c'est lui qui écrit ces scénarios de tests).
Là la compétence technique du valideur (et son expérieunce) est importante (pour savoir les pbs qui ont le plus de chance de se produire dans ce genre de développement). Elle sera également appréciée si elle permet au valideur de développer des outils autour de la validation (test automatisé, création de cahier de recette automatisée, synchro avec les outils de bug tracking, ...)
Sa compétence fonctionnelle est aussi très importante. Il doit comprendre à quoi sert l'application et comment elle sera utilisée par le client.
C'est là une plus value importante qu'il doit apporter par rapport au test du dévelopeur qui aura tendance à tester juste que ce qu'il avait lui même en tête et qui peut être bien différent de ce que le client souhaite.

Je pense aussi qu'il est un bon relationnel, que ce soit avec les développeurs, ou avec les clients qu'il sera souvent amener à cotoyer pendant les phases de recettes.

-
Edité par macaque 3 août 2015 à 18:44:20

Merci pour vos réponses tsez et macaque, j'y vois bien plus clair !!

Bonjour,

Il y a aussi le pentester, ce qui est une branche particulière des tests, je reprends les questions ci dessus pour ce type de testeur :

Comment s'effectuent les tests ? Avec quels types de techniques ?

Avec des outils, soit existants, soit développés par le pentester. Tout type de technique est possible afin de tester l'équipement, cela va du scan de vulnérabilité jusqu'à l'exploit.

Concrètement, à quelle fréquence ou rythme les tests s'effectuent-ils ? En continu ou avant chaque grosse mise en prod ?

Pour le pentester, les tests sont continus, dans le sens où l'on test plusieurs projets simultanément, puis ensuite on passe à d'autres projets. On ne dépend pas d'un projet spécifique, ce sont des tiers (d'autres entreprise ou au sein de la même entreprise) qui demandent à ce qu'on test leurs produits.

Comment communique-t-on autour des bugs ? 

On dresse un rapport qu'on remet ensuite aux tiers.

Va-t-on voir le dev au fil de l'eau pour lui expliquer là où ça buggue, faut-il rendre un rapport détaillé, faire des présentations d'équipe ?...

Un rapport détaillé est remis aux managers (rarement des contacts directs avec les développeurs) démontrant les vulnérabilités/failles trouvées ainsi que des solutions possibles qui sont décrites pour les développeurs. C'est ensuite à eux de décider s'il vont les corriger ou pas.

Il y a parfois des vulnérabilité qui ne peuvent pas être corrigées : faute de temps, de moyens, ou parce que ce n'est techniquement pas possible (impossibilité de monopoliser une chaine de production, impossibilité de changer la version d'un système sous peine de provoquer des problèmes de cohérences etc...)

De manière générale, de quelles qualités ou savoir-être a besoin un pentesteur pour bien faire sont travail ?

Rigueur, curiosité et savoir s'adapter rapidement.