1. Software Testing Methods and Techniques
Durée ? 30mn
Philippe CHARMAN
Last update:

2. Summary The box approach Preliminary Testing Informal Testing Methods
Black Box Testing
White Box Testing
Gray Box Testing
Preliminary Testing
Smoke Testing
Sanity Testsing
Informal Testing Methods
Monkey Testing
Exploratory Testing
Reducing the input data set
Equivalence partitioning
Boundary Value Analysis
Test Case Generation
Pairwise testing
Fault injection methods
Error Handling Testing
Bebugging
Mutation Testing

3. About the Testing Terminolgy
Software Testing has developed many redundant or overlapping terminologies over the last decade
For instance black box testing is equivalent to specification-based testing or functional Testing
The reference is the ISTQB glossary

4. Input -> -> Output
Black Box Testing
Testing software based on output requirements and without any knowledge of the internal structure or coding in the program
Input -> > Output
Black-box testing is focused on results
Synonyms: specification-based testing, functional testing
Program
Le test en boite noire vise à évaluer la réaction du logiciel à certaines entrées sans examiner l’implémentation
Aussi appelé “Black box testing” et “tests fonctionnels”
La principale difficulté réside dans la sélection d’un ensemble adéquat de valeurs de test.
On teste la fonctionalité sans avoir de connaissance particulière sur le langage utilisé, sur l’implémentation,
sur les structures de données,
On sait ce qu’on peut donner en entrée, on sait évaluer si le résultat est correct ou pas.
On peut aussi donner des valeurs non autorisées pour voir si le système réagit correctement
on teste si les erreurs sont bien traitées et si l’utilisateur peut continuer à travailler normalement

5. Black Box Testing Pros Quick understanding of the system behaviour
Simplicity: design the input and get the output
Unaffiliated opinion
Cons
Too many redundant test cases may be created
Missing test cases
Avantages des tests en boite noire
1) Connaissances minimes
Pour créer une suite de test, le testeur a juste besoin de lire la spec fonctionnelle
La spec peut elle-même contenir déjà explicitement des cas de tests.
Pas de besoin de se plonger dans le code comme avec le test de boite blanche.
2) Simplicite
Les principales préoccupations sont:
primo determiner le jeu de parametres d’entrée à tester
deuxio connaitre le résultat attendu
3) Pas d’a priori sur la fonctionalité
Le testeur n’a aucune connaissance du code developpé et va trouver des bugs que le developpeur n’aura pas pu imaginer
Le developpeur: ah oui mais le cas d’utilisation de cette fonctionalité n’a pas été respecté
Le testeur: je teste comme un client peut utiliser
Inconvenients
Le testeur est comme dans un labyrinthe noir sans aucune lumiere
Il va repasser plusieurs fois dans un meme endroit sans s’en rendre compte
Il va oublié des parties
Trop de tests avec des jeu de valeurs differentes qui vont tester le meme use cas
On peut passer a cote de beaucoup de tests

6. Black Box Test Design Techniques
boundary value analysis
cause-effect graphing
classification tree method
decision table testing
domain analysis
elementary comparison testing
equivalence partitioning
n-wise testing
pairwise testing
process cycle test
random testing
state transition testing
syntax testing
use case testing
user story testing
Avantages des tests en boite noire
1) Connaissances minimes
Pour créer une suite de test, le testeur a juste besoin de lire la spec fonctionnelle
La spec peut elle-même contenir déjà explicitement des cas de tests.
Pas de besoin de se plonger dans le code comme avec le test de boite blanche.
2) Simplicite
Les principales préoccupations sont:
primo determiner le jeu de parametres d’entrée à tester
deuxio connaitre le résultat attendu
3) Pas d’a priori sur la fonctionalité
Le testeur n’a aucune connaissance du code developpé et va trouver des bugs que le developpeur n’aura pas pu imaginer
Le developpeur: ah oui mais le cas d’utilisation de cette fonctionalité n’a pas été respecté
Le testeur: je teste comme un client peut utiliser
Inconvenients
Le testeur est comme dans un labyrinthe noir sans aucune lumiere
Il va repasser plusieurs fois dans un meme endroit sans s’en rendre compte
Il va oublié des parties
Trop de tests avec des jeu de valeurs differentes qui vont tester le meme use cas
On peut passer a cote de beaucoup de tests

7. White Box Testing
White box testing is when the tester has access to the internal data structures and algorithms including the code that implement these
Some types:
Code review
Code coverage
Performance
etc.
Usually performed with dedicated QA tools (static or dynamic tools)
Synonyms: clear-box testing, glass box testing, code-based testing, logic-coverage testing, logic-driven testing, structural testing
Le test de boite blanche ne s’intéresse plus à l’aspect fonctionnel vu de l’“extérieur”, du
programme, mais aux details de son implementation
A son flot de contrôle, ou
a son flot de données
Bien souvent le test de boite blanche est fait avec l’aide d’outil spécifiques
Couvrir la couverture de code, revue de code, performance on peut besoin
de voir le code pour faire des tests de boite blanche
En general plutôt le developpeur qui fait ce type de tests, voire un testeur qui aurait
des connaissances de programation

8. White Box Testing Pro Cons
May detect missing test cases with code coverage
May detect bugs with dedicated tools (memory debuggers, static analysis code tools, etc.)
Unit tests can be easily automated
Cons
Programming skills required
Need to understand the implementation that may be complicated
Time-expensive activity
Avantages: 1) Tests manquants
Avec la couverture de code, il est facile de voir le code non couvert pour lequel
Il manque des tests
2) Outils specifiques
Un outil peut trouver des fuites mémoires des fuites de resource qui ne seront pas trouvés des tests en boite noire
On peut aussi trouver des bugs même si aucun test ne les detecte
Ex : if (x = 0) { au lieu de if (x == 0) {
3) Automatisation facile
Les tests unitaires sont fait en connaissant le code et avec les couches basses d’une application
En general pas de GUI, le code est intra-module,
Une fois les tests ecrits, assez faciles d’automatiser tout cela
Inconvénients: 1) Il faut savoir coder
Pas tous les testeurs savent comprendre le code ecrit
Limité plutôt aux développeurs et au développeur qui a écrit le code
2) Comprendre l’implementation qui peut etre compliqué si elle a été ecrit par quelqu’un d’autre
C’est quelque chose qui arrive de temps en temps : on est amené à reprendre du code
3) Prend du temps
Autant un test en boite noire peut commencer tres rapidement, autant un test en boite blanche plus de temps
Regarder le code, le comprendre,
Analyser les resultats des outils de genie logiciel

9. White Box Test Design Techniques
branch testing
condition testing
data flow testing
decision condition testing
decision testing
LCSAJ testing
modified condition decision testing
multiple condition testing:
path testing
statement testing:
Le test de boite blanche ne s’intéresse plus à l’aspect fonctionnel vu de l’“extérieur”, du
programme, mais aux details de son implementation
A son flot de contrôle, ou
a son flot de données
Bien souvent le test de boite blanche est fait avec l’aide d’outil spécifiques
Couvrir la couverture de code, revue de code, performance on peut besoin
de voir le code pour faire des tests de boite blanche
En general plutôt le developpeur qui fait ce type de tests, voire un testeur qui aurait
des connaissances de programation

10. Gray Box Testing
Combination of black box testing and white box testing
Idea: if one knows something about how the product works on the inside, one can test it better, even from the outside
Les tests “boîte blanche” demandent une parfaite connaissance du code testé
Les tests “boîte noire” ne se basent que sur la spécification
Les situations intermédiaires sont appelés tests “boîte grise”
Typiquement le testeur va etre amené à connaitre des details d’implementation
Par le developpeur

11. Gray Box Testing
Pros
Better test suite with less redundant and more relevant test cases
Cons
The tester may loose his/her unaffiliated opinion
L’avantage d’un test de boite grise est d’elaborer une suite de tests plus efficace, plus susceptible de trouver
des bugs
L’inconvénient est l’inconvenient de l’avantage
Un testeur à qui on a donné des indications pour mieux tester une fonctionalite, va etre influencé sans le vouloir
Qui a donné des infos au testeur ? Le developpeur !
Le testeur va etre influence par le developpeur …

12. Testing Levels Who Tests What
Customer DB
App
Server
Acceptance
Testing
Consultant
Customer
System
Testing
Module 1
Module 2
Integration
Testing
Tester
High Level Code
High Level Code
Le test unitaire: noir ou blanc ?
Blanc sans aucun doute car en general c’est le developpeur qui ecrit les tests unitaires
Et meme si par hasard c’est une autre personne comme un testeur, ce sera blanc aussi
Test unitaire
Le test fonctionel au sens test des fonctions/methodes/features qui font partie des requirements: noir ou blanc ?
Ca depend de la personne qui teste
Sí c’est le developpeur qui a écrit le code, c’est forcément blanc
Si c’est un testeur, en general c’est noir.
Noir car même si le testeur a accès au code et il va écrire son plan de tests en fonctions des spécifications
fonctionnelles établies par le chef de projet et le chef de produit pour satisfaire les besoins du client
Noir mais dans certains cas ca peut etre gris si les conditions s’y pretent:
si le testeur a fini le plan de test par rapport aux specs à temps
si le testeur a du temps devant lui
si le développeur lui a donné des indications sur l’implementation et lui a donné des pistes pour tester des
alors le testeur va pouvoir faire de test en boite grise
Le test d’integration: blanc, noir, gris ?
En general la seule personne qui fait des tests d’integration c’est le testeur
Boite noire
Les tests d’acceptation: blanc ou noir ?
Noir quelque soit la personne qui teste
En pratique les tests d’acceptation sont fait par le consultant seul ou avec le client
Component
Testing
Low Level Code
Low Level Code
Developer

13. Smoke Testing
In electronics jargon: when a new electrical system is to be tested, plug it into the power
If there’s smoke, stop the tests
If no smoke, more tests can be executed
In software engineering:
Preliminary tests before advanced tests, for instance when assembling the differents modules
A smoke test is a quick test done at integration time
Good practice: perform smoke tests after every build in continuous integration system
A smoke test should not be confused with a stress test!
Le smoke test pourrait se traduire comme test de detection de fumée
Le terme « test de détection de fumée » provient du domaine des matériels. Il dérive de cette pratique ancienne,
qui consistait simplement à mettre sous tension un équipement lorsque l'un de ses composants avait été modifié
ou réparé. S'il n'y avait pas de fumée, le test du composant était réussi.
On pourrait imaginer que le smoke test est un test de stress comme pour faire “fumer” un logiciel
mais cela n’a rien à voir même si l’image de la fumée peut nous induire en erreur
En general dans les systemes d’integration continues qui construisent les libraries, les installeurs
en permanence, la pratique est d’executer des smokes tests sommaires juste apres le build.

14. Sanity Testing Quick, broad, and shallow testing 2 possible goals:
Determine whether it is reasonable to proceed with further testing
Determine whether the very last release candidate can be shipped (provided more advanced and detailed tests have been performed on previous release candidates)
Example when testing a GUI: checking all the actions from the menus work for at least one test case
Le sanity testing que l’on pourrait traduire par test d’aptitude
Tests superficiels sur les principales fonctionalités tests rapides également plus complets
Que le smoke tests
Typiquement un smoke test c’est environ une heure
Un sanity test c’est une demi-journée, une journée
But: savoir si cela fait du sens d’enchainer avec des tests avancés
Autre cas d’utilisation:
La R&D doit sortir une version majeure.
Tous les tests avancés ont déjà été faits pendant la phase de test mais il y a toujours des
bugs divers qui sont corrigés à la dernière minute et pratiquement tous les jours, il y a une
nouvelle release candidate qui est construite.
On ne va pas repasser les tests détaillés à chaque car ca prendrait trop de temps.
On se contente de tester le minimum pour verifier que rien n’a été cassé avec les dernières
corrections de bugs

15. Smoke Testing vs. Sanity Testing
According to a unfortunately shared opinion:
A smoke test determines whether it is possible to continue testing
e.g. “File > Open” doesn’t work at all whatever the format of the data -> useless to perform more tests
A sanity test determines whether it is reasonable to continue testing
e.g. “File > Open” works only for a subset of the formats of the data -> we should be able to perform more tests
According to ISTQB:
smoke testing = sanity testing
On a souvent tendance à confondre les smoke tests avec le sanity tests
Pourtant ce n’est pas tout à fait la même chose
Un smoke test verifie qu’il n’y a pas d’erreur sévère qui empêcherait de tester dans des
conditions normales.
Par exemple, si l’ouverture des données, l’ouverture d’un projet dans une application ne
peut pas se faire, si “File > Open” ne marche pas du tout, pas la peine de tester les quelques
bricoles mineurs qui restent dans les menus
C’est retour à la case départ direct. On attend un autre build plus stable.
Le smoke test est fait soit par les développeurs, soit par un systeme de build
et test automatique, soit par l’eqiupe qualité selon la facon dont les equipes
De dev et de qualite sont organisées.
La reussite d’un smoke test est la condition sine qua non pour que l’equipe QA
puisse continuer les tests.
Quand on fait un sanity test, on a déjà passé un smoke test.
Un sanity test peut échouer mais les erreurs n’empêchent de continuer à tester.
Si l’ouverture d’un projet marche pour certains formats mais pas pour d’autres, on peut continuer les tests.

16. Monkey Testing Monkey testing is random testing performed by
a person testing an application on the fly with no idea in mind
or an automated test tool that generate random input
Depending on the characteristics of the random input, we can distinguish:
Dumb Monkey Testing: uniform probability distribution
Smart Monkey Testing: sophisticated probability distribution
Le monkey testing qui peut se traduire par tests aleatoires
Soit manuellement : une personne va tester le GUI d’une application comme ca lui vient,
sans plan de test, sans test particulier en tête, juste des clicks, des selections d’objets,
des actions dans le menu contextuel, etc. juste comme ca
Soit par un programme qui va generer des entrees aleatoires pour tester
Le programme peut etre
Soit pas tres malin: genere au hasard n’importe quelle entrée possible mais si
par moment cela ne fait pas de sens
Par exemple dans un GUI, repeter la meme action plusieurs fois alors qu’une seule suffisait
Soit un peu moins bete en introduisant un peu de semantique dans les actions
pour essayer de reproduire ce que ferait un humain
ex tester un "save as …  "
rentrer chemin d’un fichier avec
Dumb: n’importe quel charactere
Smart: se concentre sur les characteres speciaux

17. Monkey Testing
Pro:
May find severe bugs not found by developers that make the application crash
Con:
Less efficient than directed testing
Le monkey testing qui peut se traduire par tests aleatoires
Soit manuellement : une personne va tester le GUI d’une application comme ca lui vient,
sans plan de test, sans test particulier en tête, juste des clicks, des selections d’objets,
des actions dans le menu contextuel, etc. juste comme ca
Soit par un programme qui va generer des entrees aleatoires pour tester
Le programme peut etre
Soit pas tres malin: genere au hasard n’importe quelle entrée possible mais si
par moment cela ne fait pas de sens
Par exemple dans un GUI, repeter la meme action plusieurs fois alors qu’une seule suffisait
Soit un peu moins bete en introduisant un peu de semantique dans les actions
pour essayer de reproduire ce que ferait un humain
ex tester un "save as …  "
rentrer chemin d’un fichier avec
Dumb: n’importe quel charactere
Smart: se concentre sur les characteres speciaux

18. Exploratory Testing Not well-know technique that consists of
Learning the product
Designing the test plan
Executig the test
Interpreting the results
in parallel
Exploratory testing is particularly suitable if requirements and specifications are incomplete, or if there is lack of time
Dans un mode idéal:
le testeur prend connaissance des specs,
écrit le plan de test qui est approuvé par les developpeurs
execute le plan de test une fois la fonctionalite implementée
Cela definit un processus bien defini, c’est carré
Mais des fois il arrive que rien ne se passe comme prévu, les specs
ne sont pas finalisées, le temps pour tester s’est reduit comme une
peau de chagrin
le testeur va faire alors du test exploratoire c’est-à-direà exécuter des tests sans plan de test préalable.
Ce type de test permet de découvrir des anomalies qui échappent à des techniques structurées.
En effet les processus de test classiques n’encouragent pas à “sortir des sentiers battus” et imaginer
lors des phases d’exécution de nouveaux tests autres que ceux planifiés (pression des plannings,
exécutants non expérimentés …). 

19. Exploratory Testing Pros: less preparation is needed
important bugs are found quickly
and at execution time, the approach tends to be more intellectually stimulating than execution of scripted tests.
Cons:
skill testers are needed
tests can't be reviewed in advance
difficult trace which tests have been run
Dans un mode idéal:
le testeur prend connaissance des specs,
écrit le plan de test qui est approuvé par les developpeurs
execute le plan de test une fois la fonctionalite implementée
Cela definit un processus bien defini, c’est carré
Mais des fois il arrive que rien ne se passe comme prévu, les specs
ne sont pas finalisées, le temps pour tester s’est reduit comme une
peau de chagrin
le testeur va faire alors du test exploratoire c’est-à-direà exécuter des tests sans plan de test préalable.
Ce type de test permet de découvrir des anomalies qui échappent à des techniques structurées.
En effet les processus de test classiques n’encouragent pas à “sortir des sentiers battus” et imaginer
lors des phases d’exécution de nouveaux tests autres que ceux planifiés (pression des plannings,
exécutants non expérimentés …). 

20. Equivalence Partitioning
A process of selecting test cases/data by identifying the boundaries that separate valid and invalid conditions
Goal: reduce the total number of test cases to a finite set of testable test cases, still covering maximum requirements
Example: values of months as integer:
| |
invalid partition valid partition invalid partition 2
Three selected values:
A negative value: eg -2
A valid value: eg 5
A value greater than 12, eg 15

21. Boundary Value Analysis
A process of selecting test cases/data by identifying the boundaries that separate valid and invalid conditions.
Goal: reduce the total number of test cases to a finite set of testable test cases, still covering maximum requirements.
Example: values of months as integer (1=Jan, 12=Dec):
| |
invalid partition valid partition invalid partition 2
Four selected values: 0,1 and 12,13
Alternative: six selected values: 0,1,2 and 11, 12,13

22. Pairwise Testing
Effective test case generation technique that is based on the observation that most faults are caused by interactions of at most two factors
Pairwise-generated test suites cover all combinations of two therefore are much smaller than exhaustive ones yet still very effective in finding defects
Can be extended to t-wise testing
Synonym: All-pair testing

23. Pairwise Testing 3 variables x,y,z with 2 possibles values 1 and 2
Exhaustive test cases: 23 = 8
One solution among others: x y z
Test #1 1 2
Test #2
Test #3
Test #4

24. Pairwise Testing

25. Basis Path Testing
One testing strategy, called Basis Path Testing by McCabe who first proposed it, is to test each linearly independent path through the program; in this case, the number of test cases will equal the cyclomatic complexity of the program.[1]

26. Error Handling Testing
Objective: to ensure that an application is capable to handling incorrect input data
Usually neglected by developers in unit tests
Benefit: improving the code coverage by introducing invalid input data to test error handling code paths
Fault injection: Test par injection d’erreurs
consiste à insérer délibérément une erreur dans une application en cours de test, puis en exécutant l'application pour déterminer si l'application traite correctement l'erreur
On peut s’apercevoir qu

27. Error Handling Testing
What kind of bugs can be found
Severe
application frozen or crash
Major:
Undo doesn’t work
Minor:
Missing button Cancel in dialog box
Cryptic error messages
Non-localized error messages

28. Bebugging
The process of intentionally adding known faults to those already in a computer program for the purpose of monitoring the rate of detection and removal, and estimating the number of faults remaining in the program.
Bebugging is a type of fault injection
Synonym: fault seeding
I have a software application, "A" which I feel is extremely stable. I have a developer intentionally add 100 bugs to the software. I then have QA perform their regular test cycle against the applilcation. As an end result, QA ends up finding 90% of the issues which were inserted into the program. Based on this controlled experiment, I can assume that when a stable software application is released, that we are releasing it with 10% of the bugs still remaining in the system. So if I had an application where we had found and resolved 1000 bugs, I can assume that there were actually 1111 bugs in the system and we uncovered 90% of those, or 1000, meaning the software is being released with, approximately, 111 bugs still remaining. Some companies will also employ additional testing measures to increase the find rate, including cycles of exploratory testing and beta testing. Bebugging is only a form of estimating how many bugs actually remain in the software following a release. When you have collected a good deal of historical data like this, you are able to make fairly accurate assumptions as to how stable your release candidates actaully are.

29. Mutation Testing
Suppose a test suite has been written to check a feature or a function
Some questions that may arise:
What is the quality of this test suite ?
Are the relevant input values well tested ?
How to be sure the test suite covers all possible test cases ?
Code coverage and pairwise test set generation can help
Another less known technique is mutation testing
Un problème récurrent quand on écrit des tests est de savoir si les tests sont corrects, sont suffisants.
Qui me dit que ma suite de tests est parfaite ?
Vont-ils vraiment couvrir tous les cas possibles ?
Est-ce que toutes les valeurs d’entrées particulières ont été prises en compte ?
Est-ce que ma suite de test contient tous les cas de test aux limites ?
Au fond, la question: comment estimer l’efficacité d’une suite de tests ? Comment
tester une suite de tests ?
Alors il y a déjà des techniques qui peuvent me donner une indication.
L’estimation de la couverture de code peut aider. Si les tests ne couvrent que 60% des lignes d’une fonction, clairement
Il manque des cas de tests. Mais même avec une couverture de 100% des lignes je n’ai pas la garantie d’être passé dans
tous les chemins d’execution.
Deuxiement facon de faire c’est d’utiliser des outils qui generent des ensemble de cas de tests.
Soit la suite de tests a été écrite dans l’utilisation de tels outils et je compare les tests existants avec ce que me donne
une generation automatique
Ou la suite de tests ‘n’est pas écrite du tout et je me sers de ces outils dès le début en fixant les paramètres en decidant de generer
par exemple toutes les paires de valeurs ou tous les triplé de valeurs
Ca peut rassurer .. Mais dans le test des fois il faut être parano, il faut chercher la petite bête, il faut être vicieux … peut-être pas pour
toutes les fonctionnalités d’une application mais pour certaines oui ! Les fonctions qui sont les plus sensibles
Et une technique pour tester une suite de tests ‘s’appelle le mutation testing, la mutation de code, qui est apparue dans les années 70.
Un premier outil a été developpé en recherche dans les années 80 dans le mileu de la recherche.
Au départ, l’idée n’est pas mauvaise mais la mise en pratique est difficile ne s’est pas révélée concluante.
Puis depuis peu elle a beneficié d’un regain d’interet et nous allons voir en quoi elle consiste

30. Mutation Testing
Idea: bugs are intentionally introduced into source code
Each new version of the source code is called a mutant and contains a single bug
The mutants are executed with the test suite
If a mutant successfully pass the test suite:
either the test suite needs to be completed
or the execution of the mutant code is equivalent to the original code
A test suite which does reject the mutant code is considered defective
L’idée de base est d’introduire des bugs dans le programme à tester et de voir comment réagissent les tests.
Chaque modification de code est appelé un mutant qui contient donc un bug.
Le mutant est testé avec la suite de tests.
Si aucune erreur n’est décelée, a votre avis … ?
c’est bien c’est pas bien ?
Probablement il manque un test
Ou alors l’execution est la meme

31. Examples of Non Equivalent Mutant Code
Original Code
Mutant Code
if (a && b)
c = 1;
else
c = 0;
if (a || b)
c = -1;
Pour introduire un bug, on va modifier tres legerement le code
On peut changer les opérateurs
On peut changer les valeurs

32. Example of Equivalent Mutant Code
Original Code
Equivalent Mutant Code
int index=0;
while (...) {
. . .;
index++;
if (index == 10)
break; }
if (index >= 10)
Un exemple de code.
On change une test d’egalité par un test d’inégalité et manque de bol dans le cas ca ne fait aucune différence
Des que la variable index aura la valeur 10, la boucle sera finie.
Le problème des mutants équivalents est le gros problème des tests de mutuation.
Ce sont des faux positifs

33. Mutation Testing Pros Strenghten the quality of test data Cons
New test cases can be found
Code coverage is increased
Cons
Rather expensive technique for augmenting an existing test suite
The choice of mutation tool and operator set can play an important role in determining how efficient mutation analysis is for producing new test cases
En conclusion, la technique de mutation est complémentaire de celle de la couverture de code
pour s’assurer que la suite de tests
Mais c’est quand même assez couteux il faut recompiler le code à chaque fois
Et faire le tri des faux positifs
Le nombre de mutants peut etre tres importants

34. References
Myers, Glenford J. (1979). The Art of Software Testing. John Wiley and Sons. ISBN 
Kaner, Cem; Falk, Jack and Nguyen, Hung Quoc (1999). Testing Computer Software, 2nd Ed.. New York, et al: John Wiley and Sons, Inc.. pp. 480 pages. ISBN
Ben Smith, Laurie Williams: Should Software Testers use Mutation Analysis to Augment a Test Set? Journal of Systems and Software, 2009
Kaner, Cem; Bach, James; Pettichord, Bret (2001). Lessons Learned in Software Testing. John Wiley & Sons. ISBN 

35. Further Reading http://www.pairwise.org/