Tests manuels

Quel est le logiciel ?

Un logiciel est un ensemble de programmes informatiques qui nous aident à effectuer une tâche.

Types de logiciels :

1. Logiciel système (par exemple, pilotes de périphérique, système d'exploitation, serveurs, etc.)

2.Logiciels de programmation (par exemple, compilateurs, débogueurs, interpréteurs, etc.)

3.Logiciels d'application (par exemple, applications Web, applications mobiles, applications de bureau,
etc.)

Qu’est­ce que le test logiciel ?

1. Les tests logiciels font partie du processus de développement logiciel.

2. Les tests de logiciels sont une activité visant à identifier les bogues du logiciel.
3. L' objectif/le motif des tests est de proposer des produits de qualité au client.
4. Assurer au client l' exactitude et l'exhaustivité de l'application logicielle.

Nécessité des tests logiciels :

1.Pour éviter les risques (prévenir)

2.Pour identifier les erreurs (détecter)
3. Pour éviter des frais supplémentaires

4.Gagner la confiance des clients 5.

Accélérer le développement de logiciels 6.

Optimiser l'activité 7. Vérifier l'adaptabilité

des logiciels

Objectifs/Motif des tests logiciels :

1. Pour prévenir les défauts.

2. Trouver les défauts pouvant être créés par le programmeur lors du développement du logiciel.
3. Aide à fournir un produit de qualité.
4. S'assurer qu'il satisfait aux normes BRS et SRS.

5. S'assurer que le résultat répond aux exigences de l'entreprise et des utilisateurs.

6. Gagner en confiance et fournir des informations sur le niveau de qualité.
Qu'est-ce que le débogage :

1. Une fois que l'équipe de développement aura reçu le rapport de l'équipe de test, elle
commencera le débogage. Cette phase vise à localiser le bug et à le supprimer du logiciel. Il
s’agit d’un processus unique et effectué manuellement.

2. Dans ce processus, un outil spécial appelé débogueur est utilisé pour localiser les bogues, la
plupart des programmes les environnements ont le débogueur.
3. Quelques outils de débogage populaires : WinDbg, OllyDbg, IDA Pro...

Quelle est la différence entre test et débogage ?

• Tester signifie vérifier le comportement de l'application, qu'il soit attendu ou non. Et les tests
peuvent être effectués sans aucune connaissance interne de l'architecture logicielle. C'est
fait par un
testeur.

• Le débogage signifie découvrir la cause principale des défauts et le débogage nécessite une
connaissance interne de l'architecture et du codage du logiciel. C'est fait par le développeur.

Qu'est-ce qui définit (la qualité du logiciel) la qualité du logiciel :

1. Sans bug
2. Livré à temps

3. Dans les limites du budget

4. Répond aux exigences et/ou attentes du client

5. Maintenable

Psychologie des tests :

• Dans les tests de logiciels, la psychologie joue un rôle extrêmement important. •
C'est l'un de ces facteurs qui restent en coulisses mais qui ont un grand impact sur le résultat final.
• Cela dépend principalement de l' état d'esprit des développeurs et des testeurs, ainsi que de la qualité
de la communication entre eux. De plus, la psychologie des tests les aide à travailler vers un
objectif commun.

• Les trois sections de la psychologie des tests sont :

 o L'état d'esprit des Développeurs et des Testeurs.
o Communication de manière constructive.
o Tester l'indépendance.

Assurance qualité contre. CQ :

Les 3P : chaque entreprise repose sur 3 piliers :

 • P - Personnes (CQ - Testeurs) • P -

Processus (AQ - Implique tout au long du processus de développement/SDLC.) • P - Produit

Assurance qualité:

• L'AQ est orientée

processus. • L'assurance

qualité est un processus

proactif. • L'assurance qualité se concentre sur la

prévention des défauts. • L'équipe d'assurance qualité travaille avec l'équipe de développement pour produire

des logiciels de qualité. • L'assurance qualité garantit que les approches et les techniques sont

correctement mises en œuvre (pendant développement). •

L'assurance qualité est

responsable du SDLC. • Par

exemple, vérification

Contrôle de qualité:
• Le contrôle qualité est

axé sur le produit. • Le

CQ est un processus

réactif. • Le contrôle qualité se concentre sur

l'identification/détection des défauts. • Le contrôle

qualité entre en jeu après l'assurance qualité. • QC

vérifie que le projet développé répond aux normes

de qualité définies .
 • QC est responsable du STLC.

• Par exemple, validation

QE (Ingénierie Qualité) :

• L'ingénieur qualité écrit le code mais à des fins de test logiciel.

• Les ingénieurs qualité ne sont rien d'autre que des testeurs d'automatisation.

Qu’est­ce que QAMS ?

• Un système de gestion de la qualité est un ensemble de processus commerciaux axés sur la

satisfaction constante des exigences des clients et l'amélioration de leur satisfaction. Il est

aligné sur l’objectif et l’orientation stratégique d’une organisation.

• Un système de gestion de la qualité (QMS) est un système qui documente les politiques, les

processus commerciaux et les procédures nécessaires à une organisation pour créer et fournir

ses produits ou services à ses clients, et donc augmenter la satisfaction des clients grâce à une

qualité de produit élevée.

Modèle de maturité des capacités (niveaux CMM) :

Il est admis depuis longtemps que l’amélioration continue des processus repose sur de

nombreuses petites étapes évolutives plutôt que sur des innovations révolutionnaires de plus

grande envergure. Le modèle de maturité des capacités (CMM) fournit un cadre pour organiser

ces étapes évolutives en cinq niveaux de maturité qui posent les bases successives d'une

amélioration continue des processus.

Cette méthodologie est au cœur de la plupart des systèmes de gestion conçus pour améliorer la

qualité du développement et de la livraison de tous les produits et services.

Les cinq niveaux du modèle de maturité des capacités logicielles ont été définis comme suit :

1.Initiales

Le processus logiciel est caractérisé comme ad hoc, et parfois même chaotique. Peu de

processus sont définis et le succès dépend des efforts individuels et de l’héroïsme.

2.Répétable

Des processus de gestion de projet de base sont établis pour suivre les coûts, le

calendrier et les fonctionnalités. La discipline de processus nécessaire est en place pour

répéter les succès antérieurs sur des projets ayant des applications similaires.
 3. Défini

Le processus logiciel pour les activités de gestion et d'ingénierie est documenté,

standardisé et intégré à tous les processus de l'organisation. Tous les projets utilisent une
version approuvée du processus logiciel standard de l'organisation pour développer et
maintenir des logiciels.

4. Géré

Des mesures détaillées du processus logiciel et de la qualité du produit sont collectées.

Le processus logiciel et les produits sont compris et contrôlés quantitativement.

5. Optimisation

L'amélioration continue des processus est rendue possible par un retour d'information
quantitatif sur le processus et par le pilotage d'idées et de technologies innovantes.

===================================================
===========================

Projet contre. Produit:

• Si une application logicielle est développée pour un client spécifique en fonction

de ses besoins, elle s'appelle un projet.
• Si une application logicielle est développée pour plusieurs clients en fonction des
exigences du marché, alors cela s’appelle un produit.

7 principes des tests logiciels :

1. Les tests montrent la présence de défauts, pas leur absence

2. Des tests exhaustifs sont impossibles
3. L’absence d’erreurs est une erreur

4. Les tests précoces permettent d'économiser du temps et de l'argent

5. Les tests dépendent du contexte
6. Les défauts se regroupent
7. Attention au paradoxe des
pesticides BÊTA DET

1. Les tests montrent la présence de défauts, et non leur absence :

 • Les tests peuvent montrer que des défauts sont présents mais ne peuvent pas prouver qu'il n'y

en a pas. Les tests réduisent la probabilité que des défauts non découverts subsistent dans le

logiciel, mais les tests ne constituent pas une preuve d'exactitude même si aucun défaut n'est

détecté.

2.Des tests exhaustifs sont impossibles :

• Tout tester (toutes les combinaisons d'entrées et de conditions préalables) n'est

pas réalisable, sauf pour cas triviaux.

• Plutôt que de tenter de tester de manière exhaustive, l'analyse des risques, les techniques de test et les
priorités
devrait être utilisé pour concentrer les efforts de test.

3. Les tests précoces permettent d’économiser du temps et de l’argent :

• Pour détecter rapidement les défauts, les activités de tests statiques et dynamiques

doivent être démarrées dès possible dans le cycle de vie du développement

logiciel.

• Les tests précoces dans le cycle de vie du développement logiciel permettent de réduire ou d'éliminer les
changements coûteux.

4.L’absence d’erreurs est une erreur

• Certaines organisations s'attendent à ce que les testeurs puissent exécuter tous les tests possibles

et trouver tous les défauts possibles, mais cela est impossible. C'est une erreur (c'est-à-dire

une fausse croyance) de s'attendre à ce que le simple fait de trouver et de corriger un grand

nombre de défauts garantisse le succès d'un

système. • Par exemple, tester toutes les exigences spécifiées et corriger tous les défauts trouvés

pourrait toujours produire un système difficile à utiliser mais ne répondant pas aux besoins et

aux attentes des utilisateurs.

5.Les tests dépendent du contexte

 • Les tests sont effectués différemment selon les contextes. • Par

exemple, les tests dans un projet Agile sont effectués différemment des tests dans un projet de

cycle de vie de développement logiciel séquentiel.

6.Les défauts se regroupent

• C'est l'idée selon laquelle certains composants ou modules de logiciels

contiennent généralement le plus nombre de problèmes ou sont responsables

de la plupart des échecs opérationnels.

• Les tests doivent donc être axés sur ces domaines.

7.Attention au paradoxe des pesticides

 • Si les mêmes tests sont répétés encore et encore, ces tests finissent par ne plus trouver aucun
nouveaux défauts.

• Pour détecter de nouveaux défauts, les cas de test et les données de test existants peuvent devoir être
modifiés, et de nouveaux tests
il faudra peut-être l'écrire.

• Les tests ne sont plus efficaces pour détecter les défauts, tout comme les pesticides ne sont plus

efficaces pour tuer les insectes au bout d'un certain temps. Dans certains cas, comme dans le

cas des tests de régression automatisés, le paradoxe des pesticides a un résultat bénéfique, à

savoir le nombre relativement faible de défauts de régression.

===================================================
===========================

SDLC - Cycle de vie du développement logiciel :

• SDLC est un processus utilisé par l'industrie du logiciel pour concevoir, développer et tester des logiciels.

• Le processus SDLC vise à produire des logiciels de haute qualité qui répondent

aux attentes des clients. • Le développement du logiciel doit être terminé dans le

délai et le coût prédéfinis.

• SDLC consiste en un processus détaillé qui explique comment planifier, créer et maintenir des
logiciel.

Pourquoi SDLC est-il nécessaire ?

Voici les principales raisons pour lesquelles SDLC est important pour développer un système logiciel.

Il fournit un ensemble standard de cadres pour les

activités SDLC. SDLC est utile pour le suivi et le

contrôle du projet.

Vitesse de développement accrue et améliorée .

Vous aide à réduire les risques liés au projet et les frais généraux du plan de gestion de projet.
Augmente la visibilité de la planification du projet auprès de toutes les parties prenantes impliquées
dans le développement
processus.
 Amélioration de la relation client.
Il offre une base pour la planification, la planification et l'estimation de projets.

Phases dans SDLC :

1. Collecte et analyse des exigences

2. Conception

3. Codage (développement/mise en œuvre)

4. Tests

5. Déploiement / Installation
6. Entretien
RDC-TDM

1. Analyse des besoins :

• Nous devons collecter et comprendre les exigences du client.

Normalement BA, projet Les managers et chefs de produits sont
impliqués dans cette phase.
• Ils parleront au client, obtiendront les exigences et prépareront un
certain nombre de (BRS/SRS).
• Cette étape donne une image plus claire de la portée de l'ensemble du projet et prévoit les enjeux.
• Cela aide les entreprises à finaliser le calendrier nécessaire pour terminer le travail de ce système.

2. Conception :

• Cela aide à définir l' architecture globale du système.

• Au cours de cette phase, les documents de conception du système et du logiciel sont
préparés conformément aux document de spécification des exigences.
• Cette phase de conception sert de contribution à la phase suivante du modèle.
• Il contient des documents comme DDS (Design Document Spécification) OU
TDD (Technical Design Document).

• Il existe deux types de documents de conception développés au cours de cette phase :

un. Conception de haut niveau (HLD) :
Brève description et nom de chaque module.
Un aperçu des fonctionnalités de
chaque module. Intégration entre
modules.
Les tables de la base de données sont identifiées avec leurs
éléments clés. Schémas d'architecture complets ainsi que les
détails techniques.
 b. Conception de bas niveau (LLD) :
Logique fonctionnelle réelle des modules.
Entrées et sorties complètes pour

chaque module. Détails complets des

intégrations/interfaces.

Résout tous les types de problèmes de

dépendance. Liste des messages

d'erreur.
Tableaux de base de données, qui incluent le type et la taille.

3. Codage :

• Une fois la phase de conception du système terminée, la phase suivante est le codage. Dans cette phase,
les développeurs commencent
construire l'ensemble du système en écrivant du code en utilisant le langage
de programmation choisi.

• Lors de la phase de codage, les tâches sont divisées en unités ou modules et

attribuées aux différents développeurs.

• Il s'agit de la phase la plus longue du processus du cycle de vie du développement logiciel.

• Dans cette phase, le développeur doit suivre certaines directives de codage prédéfinies.

• Ils doivent également utiliser des outils de programmation tels que des compilateurs, des

interprètes et des débogueurs pour générer et implémenter le code.

4. Tests :

• Une fois le logiciel terminé, il est déployé dans l'environnement de test. L' équipe de test

commence à tester la fonctionnalité de l'ensemble du système. Ceci est fait pour vérifier

que l'ensemble de l'application fonctionne selon les exigences du client.

• Au cours de cette phase, l'équipe d'assurance qualité et de test peut trouver des

bugs/défauts qu'elle communique aux développeurs. Ensuite, l'équipe de développement

corrige le bogue et le renvoie au contrôle qualité pour un nouveau test. Ce processus se

 poursuit jusqu'à ce que le logiciel soit exempt de bogues, stable et fonctionne

conformément aux besoins commerciaux de ce système.

5. Déploiement/Installation :

• Une fois la phase de test du logiciel terminée et qu'aucun bogue ou erreur n'est laissé dans

le système, le processus de déploiement final commence. Sur la base des commentaires

du chef de projet, le logiciel final est publié et vérifié pour détecter les problèmes de

déploiement, le cas échéant.

6. Entretien :
 • Une fois le système déployé et les clients commencent à utiliser le système développé,

les trois activités suivantes peuvent se produire :

Correction de bugs - Des bugs sont signalés en raison de certains

scénarios qui ne sont pas testés du tout.

Mise à niveau - Mise à niveau de l'application vers les versions les

plus récentes du logiciel. Amélioration - Ajout de nouvelles

fonctionnalités au logiciel existant.

===================================================
===========================

Quel modèle SDLC est le meilleur ?

• Il n'existe aucun modèle que nous puissions considérer comme le meilleur pour le

processus de développement de logiciels. Mais de nos jours le

• Le modèle Agile est actuellement le plus populaire et le plus largement utilisé par
toute l'organisation logicielle. Dans ce modèle après

• à chaque étape de développement (Sprint), l'utilisateur est en mesure de voir si

le produit répond à ses attentes exigences. Par ça

• la façon dont les risques sont réduits à mesure que des changements continus sont effectués en fonction des
commentaires des clients.

===================================================
===========================
Types (modèles) de SDLC :

1. Modèle de cascade
2. Modèle en spirale
3. Modèle de développement rapide d'applications (RAD)
4. Modèle itératif ou incrémental
5. Modèle
prototype 6.
Modèle V

7. Modèle agile

1. Modèle de cascade :

• Waterfall est l'un des modèles (processus) de développement logiciel les plus anciens et
les plus couramment utilisés, dans lequel le processus de développement ressemble à
un flux, passant étape par étape à travers les phases telles que l'analyse, la conception,
le codage, les tests, le déploiement/l'installation et le support. . Ainsi, il est également
connu sous le nom de « modèle séquentiel linéaire ».
• Ce modèle SDLC inclut l'exécution progressive de chaque étape dans son intégralité.
Ce processus est strictement documenté et prédéfini avec les fonctionnalités
attendues pour chaque phase de ce modèle de cycle de vie de développement
logiciel.

S.
Avantages du modèle Waterfall : 1.

Simple, facile à comprendre et à utiliser.

2. Facile à mettre en œuvre grâce à son processus linéaire.
3.Étant donné que les modifications des exigences ne sont pas autorisées, les chances de
trouver des bogues seront moindres.

S.
 4.L’investissement initial est moindre puisque les testeurs sont embauchés ultérieurement.
5.Préféré pour les petits projets où les exigences sont gelées (bien

comprises au niveau stade précoce).

Inconvénients du modèle en cascade : 1.

Les modifications des exigences ne sont

pas autorisées.

2. S'il y a un défaut dans l'exigence qui se poursuivra dans les phases ultérieures.
3. Mauvais modèle pour un projet long et en cours.
4. Les tests ne commenceront qu’après la phase de codage.
5. L'investissement total est plus important, car si la retouche a été effectuée en

raison de défauts, cela entraîne un investissement long et élevé.

Où nous utilisons (cas d'utilisation pour) le modèle SDLC Waterfall :

1. Les exigences sont documentées avec précision.
2. La définition du produit est stable.

3. La pile technologique est prédéfinie , ce qui la rend non dynamique.

4. Aucune exigence ambiguë (douteuse).
5. Le projet est court.

===================================================
===========================

2. Modèle en spirale : PREE

1.Le modèle en spirale est également connu sous le nom de modèle itératif.
2. Il s’agit d’une combinaison du modèle Prototype et Waterfall.
3.Le modèle en spirale est principalement utilisé dans les projets à haut risque (dans les projets
vastes et complexes).
4. Il est utilisé lorsque les besoins sont importants, peu clairs et complexes.
5. Le modèle en spirale surmonte les inconvénients du modèle en cascade.
6. Il comprend 4 étapes de planification, d'analyse des risques, d'ingénierie et d'évaluation.

S.
7. À chaque cycle, une nouvelle version du logiciel [module] sera proposée au client.
8. Le logiciel sera publié en plusieurs versions. Donc, cela s'appelle aussi
un contrôle de version modèle.

S.
Étapes:

1. Planification des objectifs ou identification de solutions alternatives : Dans cette étape,

les exigences sont collectées auprès des clients, puis les objectifs sont reconnus et
analysés au début du développement du projet. Si le cycle itératif est supérieur à un,
alors une solution alternative est proposée dans le même quadrant.

2. Analyse et résolution des risques : au fur et à mesure que le processus atteint le

deuxième quadrant, toutes les solutions probables sont esquissées, puis la meilleure
solution parmi elles est sélectionnée. Ensuite, les différents types de risques liés à la
solution choisie sont reconnus et résolus grâce à la meilleure approche possible.
Alors que la spirale atteint la fin de ce quadrant, un prototype de projet est présenté
pour la solution la plus excellente et la plus probable.

3. Développer le niveau suivant du produit : au fur et à mesure que la progression du

développement atteint le troisième quadrant, les fonctionnalités bien connues et les
plus requises sont développées et vérifiées avec les méthodologies de test. À la fin
de ce troisième quadrant, un nouveau logiciel ou la prochaine version d'un logiciel
existant est prêt à être livré.
4. Planifiez la phase suivante : au fur et à mesure que le processus de
développement avance dans le quatrième quadrant, les clients évaluent la
version développée du projet et signalent si d'autres modifications sont
nécessaires. Enfin, la planification de la phase suivante (ultérieure) est lancée.
 Prototype : Un prototype est un plan du logiciel.

Exigences initiales du client ---> PROTOTYPE ---> client ---> Conception, Codage, Tests....

Avantages du modèle en spirale :

1. Convient aux grands projets : les modèles en spirale sont recommandés lorsque le

projet est de grande envergure, volumineux, ou complexe à développer.

2. Gestion des risques : de nombreux projets comportent des risques non estimés . Pour

de tels projets, le modèle en spirale est le meilleur modèle SDLC à suivre car il peut

analyser les risques ainsi que gérer les risques à chaque phase de développement.

3. Satisfaction du client : les clients peuvent assister au développement du produit à

chaque étape et ainsi, ils peuvent s'habituer au système et envoyer des commentaires

en conséquence avant la fabrication du produit final.

4. Flexibilité des exigences : toutes les exigences spécifiques nécessaires aux étapes

ultérieures peuvent être incluses précisément si le développement est effectué à l'aide

de ce modèle.

Inconvénients du modèle en spirale :

1. Les modifications des exigences ne sont PAS autorisées entre les cycles.
2. Chaque cycle du modèle en spirale ressemble à un modèle en cascade.
3. Il n’y a aucun test dans la phase d’exigence et de conception.
4. Ne fonctionne pas pour les petits projets.
5. Cela peut coûter assez cher.

===================================================
===========================
3. Modèle RAD :

RAD signifie « Développement rapide d'applications ». Selon son nom lui-même, le modèle

RAD est un modèle permettant de développer des produits logiciels rapides et de haute

qualité par exigences à l'aide d'ateliers.

1.Prototypage et tests utilisateur précoces et réitérés des conceptions.

2.La réutilisation des composants logiciels.
3.Moins de formalité dans les évaluations et autres communications d'équipe.

===================================================
===========================

4.Modèle itératif :
 1.Dans un modèle itératif, l'application sera divisée en petites parties et en développement

se fera en spécifiant et en mettant en œuvre seulement de petites parties du

logiciel, qui peuvent être examinées pour identifier d'autres exigences.

2.Ce processus est répété, créant une nouvelle version du logiciel pour chaque

cycle du modèle. Le modèle itératif est très simple à comprendre et à utiliser.

Dans ce modèle, nous ne pouvons pas commencer à développer le logiciel

complet avec une spécification complète des exigences.

===================================================
===========================

5.Modèle prototype :

• Il s'agit d'une version d'essai du logiciel. Il s'agit d'un exemple de

produit conçu avant de commencer tests réels.

• Ce modèle est utilisé lorsque les exigences de l'utilisateur ne sont pas très claires, et

ce logiciel est testé sur la base des exigences brutes obtenues de l'utilisateur. Les

types de prototypage disponibles sont rapide, incrémental, évolutif et extrême.

• Le modèle prototype fonctionnera comme :

1.Nous prendrons en compte les exigences de

base 2. Sur la base de la discussion, nous créerons un prototype

initial (Un prototype – est un modèle)

3.Une fois le prototype fonctionnel construit, nous demanderons au client de le vérifier et de

l'utiliser

4.La prochaine étape consistera à tester et à améliorer 5. Encore

une fois, nous appellerons l'utilisateur pour le vérifier et l'utiliser, et encore une fois, nous
apporterons les modifications conformément aux instructions.

les commentaires de l'utilisateur jusqu'à ce que nous obtenions toutes les exigences de
l'utilisateur.

6. Une fois que toutes les exigences sont remplies et que le client est d'accord, la
 dernière étape sera signée (Signature - Livrer le produit et terminer le contrat)

Avantages du modèle prototype :

1. Les utilisateurs sont activement impliqués dans le développement

2. Les fonctionnalités manquantes peuvent être facilement identifiées

3. Sur la base des commentaires des utilisateurs, le document SRS est finalisé

Inconvénients du modèle prototype :

1. L'exemple de modèle n'est pas utilisé pour la mise en œuvre réelle

2. La portée du système peut s'étendre au-delà des plans initiaux

===================================================
===========================
6. Modèle V :

• Parallèlement à la phase de développement du logiciel, une série correspondante de phases de

test se déroule également dans ce modèle. Chaque étape garantit qu'un type spécifique de
test est effectué, et une fois ce test réussi, la phase suivante commence seulement.
• Lorsque le besoin est bien défini et ambigu (incertain), nous utilisons le V-Model.
• Il est également connu sous le nom de modèle de vérification et de validation.

Vérification : Phase de conception :

1. La vérification vérifie si nous construisons le bon produit

(logiciel) (pour vérifier si les exigences spécifiques seront
satisfaites ou non).
2. Concentrez-vous sur la documentation. Les tests des documents liés au projet sont appelés tests
statiques.
3. La vérification n'implique pas l'exécution du code.

4.La vérification implique généralement des techniques de tests statiques telles que :
Avis

Procédures pas à pas

Contrôles
5. Il existe les différentes phases de la phase de vérification dans le
modèle en V, je. BRS (Spécification des exigences
commerciales) :
o Il s'agit de la première étape où les exigences du produit sont comprises du
côté du client. Cette phase contient une communication détaillée pour
comprendre les attentes et les exigences exactes des clients .
ii. SRS (Spécification des exigences logicielles) :
 oÀ ce stade, les ingénieurs système analysent et transfèrent l'activité du

système proposé à SRS en étudiant le document des exigences

utilisateur (BRS).

iii. HLD (conception de haut niveau) :

o La conception de haut niveau (HLD) explique l'architecture

qui serait utilisée pour développer un système.

o Le diagramme d'architecture donne un aperçu de l'ensemble d'un système,

identifiant les principaux composants qui seraient développés pour le

produit et leurs interfaces.

iv. LLD (conception de bas niveau) :

o En phase de conception des modules, le système se
décompose en petits modules.

o La conception détaillée des modules est spécifiée, dite Low-

Conception de niveau

Phase de codage :

• Après la conception, la phase de codage est lancée. Sur la base des exigences, un langage de

programmation approprié est décidé. Il existe certaines lignes directrices et normes pour le

codage.

Avant d'être archivé dans le référentiel, la version finale est optimisée pour de meilleures

performances et le code passe par de nombreuses révisions de code pour vérifier les

performances.

Validation : Phase de tests :

1.La validation vérifie si nous construisons correctement le produit (logiciel) (pour

vérifier si nous développons le bon logiciel).

 2. Concentrez-vous sur les logiciels.

3.La validation implique généralement des tests réels.

4.A lieu une fois les vérifications terminées.
5.Ici, nous utilisons les techniques de test

dynamique ci-dessous : Tests unitaires

Tests
d'intégration
Tests du
système UAT

• Avantages du modèle V :
1.Les tests sont impliqués dans chaque phase.
2.Chaque étape du modèle en forme de V a des résultats stricts, il est donc facile à contrôler.
3.Les tests et la vérification ont lieu dès les premiers stades.
4.Idéal pour les petits projets, où les exigences sont statiques et claires.

5.Les méthodes de test telles que la planification et la conception des tests se déroulent bien avant
le codage.
 • Inconvénients du modèle V :
1.La documentation est plus.

2.Si des changements surviennent à mi-chemin, les documents de test ainsi que les

documents requis doivent être mis à jour.

3.L'investissement initial est plus important.

4.Très rigide et moins flexible.

5.Le logiciel est développé pendant la phase de mise en œuvre, de sorte qu'aucun

premier prototype du logiciel n'est produit.

Quand utiliser le modèle V :

1. Le modèle en forme de V doit être utilisé pour les projets de

petite et moyenne taille où les exigences sont clairement

définies et fixées.
2. Des ressources techniques expérimentées sont disponibles

Le modèle Waterfall et le modèle V sont-ils identiques ? :

V Model est la version mise à jour de Waterfall Model.

===================================================
===========================

Techniques de tests statiques :

Nous utilisons des techniques de tests statiques du côté vérification dans le modèle V.
1. Révision

2. Procédure

pas à pas 3.

Inspection

S.
1.Révision :

Examiner les procédures sur les documents pour garantir leur exactitude et leur
exhaustivité.

• Revues des exigences •

Revues de conception
• Révisions de codes

• Examens du plan de test

• Revues de cas de tests , etc.

2.Procédure pas à pas :

S.
 • Il s'agit d'un examen informel .

• Cela n'est pas planifié à l'avance et peut être réalisé chaque fois que nécessaire.

• L'auteur lit les documents ou le code et en discute avec ses pairs.

• De plus, la procédure pas à pas ne contient pas de procès-verbal de la réunion.

3.Contrôle :

• Il s'agit du type d'examen le plus formel .

• L'inspection aura un calendrier approprié qui sera communiqué

par courrier électronique au développeurs/testeurs

concernés.

• Au cours de laquelle au moins 3 à 8 personnes participent à la réunion : 1

lecteur, 2 écrivains, 3 modérateurs et les personnes concernées.

Techniques de tests dynamiques :

Nous utilisons des techniques de tests dynamiques du côté validation dans le modèle V.

1. Tests unitaires

2. Tests d'intégration

3. Tests du système

4. Tests d'acceptation des utilisateurs (UAT)

Pourquoi avons-nous besoin de tests dans le processus SDLC ?

• La phase de test est très importante pour vérifier si le logiciel développé est un produit de

qualité et correspond à un document de conception. Cette étape confirme que le produit

développé répond aux exigences définies par les clients. Au cours de cette étape, nous
 effectuons différents types de tests, notamment des tests unitaires, des tests d'acceptation, des

tests système, etc. L'équipe de tests logiciels travaille en collaboration avec les développeurs

pour identifier et résoudre les bogues logiciels et fournit l'application qualité au client.

Expliquez brièvement le processus de publication du logiciel :

• Dans le processus de publication du logiciel, le chef de projet constitue une équipe de

publication composée de développeurs, de testeurs et de responsables de gestion de projet.

Cette équipe se rend chez les clients et déploie des produits logiciels ou déploie simplement

le logiciel sur le serveur du client. L'équipe dispense également des formations aux clients

concernant le fonctionnement du logiciel si nécessaire.

 Quelle est la différence entre SDLC et STLC ?

• Le cycle de vie du développement logiciel implique la vérification et la

validation complètes d'un processus. ou un projet.

• Alors que le cycle de vie des tests logiciels implique uniquement la validation.

===================================================
===========================

STLC - Cycle de vie des tests logiciels :

DESCRIPTION

1. Analyse des

exigences 2.

Planification des

tests

3. Conception des
tests 4. Configuration de
l'environnement de test 5. Exécution des tests
6. Clôture du test
 1. Analyse des exigences : dans cette phase, les documents

d'exigences sont analysés et validé et la portée des tests est

définie.

2. Planification des tests : dans cette phase, la stratégie du plan de test est définie,

l'estimation de l'effort de test est définie ainsi que la stratégie d'automatisation et la

sélection des outils est effectuée.

3. Conception des tests : au cours de cette phase, des cas de tests sont conçus ; les données de

test sont préparées et l'automatisation les scripts sont implémentés.

4. Configuration de l'environnement de test : un environnement de test simulant

fidèlement l'environnement du monde réel est préparé.

5.Exécution des tests : pour effectuer des tests réels selon les étapes de test.

6.Clôture du test : La clôture du test est la dernière étape du STLC où nous réaliserons toutes les
documentations détaillées

qui doivent être soumis au client au moment de la livraison du logiciel. Tels que le rapport

de test, le rapport de défauts, le résumé des cas de test, les détails RTM, la note de version.

=================================================== ===========================

Qu’est-ce que la clôture du test ?

La clôture des tests est la dernière étape de STLC où nous soumettrons toutes les documentations

détaillées requises au client au moment de la livraison du logiciel. Tels que le rapport de test, le

rapport de défauts, le résumé des cas de test, les détails RTM, la note de version.
Quelle est la liste des documents de clôture des tests ?

Il comprend,

1. documents de cas de test (c'est-à-dire, feuille Excel de cas de test que nous préparons lors des tests réels)

2. plan de test, stratégie de test,

3. Note de version

4. tester les scripts,

5. données de test,

6. matrice de traçabilité et 7. résultats

de tests et rapports tels que rapport de bug, rapport d'exécution, etc.

Expliquez-vous chacun des documents de clôture des tests ?

1. documents de cas de test : incluez des cas de test détaillés qui peuvent être examinés.

2. plan de test, stratégie de test : inclus la planification complète des tests, les stratégies, les calendriers, etc.

3. Note de version : inclut toutes les données liées à la version, telles que la version du

logiciel et le matériel pris en charge. détails, problèmes connus, problèmes résolus,

fonctionnalités ajoutées, etc.

4. scripts de test : il contient des scripts en termes de tests d'automatisation.

5. données de test : elles contiennent la date à laquelle vous avez été utilisée lors du test.

6. matrice de traçabilité : la traçabilité comprend la matrice de tous les cas de test de réussite et d'échec et
les enregistrements de défauts.

7. Résultats des tests et rapports tels que rapport de bug et rapport d'exécution : les résultats des

tests s'affichent dans leur intégralité. estival sur les applications testées.

Qu'est-ce qu'une construction ?

• Il s'agit d'un numéro/identité attribué au logiciel installable qui est

donné à l'équipe de test par le équipe de développement

Qu'est-ce que la libération ?

• Il s'agit d'un numéro/identité donné au logiciel installable

qui est remis au client/client par l'équipe de tests (ou

parfois directement par l'équipe de développement)

Qu’est-ce que le déploiement ?

• Le déploiement est le mécanisme par lequel les applications, modules,

mises à jour et correctifs sont livré des développeurs à l'utilisateur

final/client/client.

Quand les tests proprement dits commenceront-ils ?

 • Les tests comprennent de nombreuses activités dans chaque phase du cycle de vie de

développement, telles que l'analyse des exigences, la création d'un plan de test, la

conception des tests, etc. Ainsi, l'activité de test logiciel doit être démarrée dès que possible

(après la base de référence des exigences) dans le cycle de vie de développement.

Quels outils utilisez-vous pour rédiger des cas de test de révision ?

• Généralement, dans notre entreprise, nous préférons rédiger les cas de tests sur une feuille

Excel car c'est très simple et convivial. Une fois l'examen terminé, nous ajouterons ces

cas de test dans TestLink à des fins de suivi futur.

• TestLink

Version : -1.9.13 (Strombringer)

Qu'est-ce qu'un attribut différent des cas de test ?

1. TestCaseID - Un identifiant unique du scénario de test.

2. Résumé du test - Résumé en une seule ligne du scénario de test.
3. Description - Description détaillée du scénario de test.
4. Prérequis ou pré-condition - Un ensemble de prérequis qui doivent être

respectés avant l'exécution les étapes du test.

5. Étapes de test - Étapes détaillées pour exécuter le scénario de test.

6. Résultat attendu - Le résultat attendu pour réussir le test.
7. Résultat réel - Le résultat réel après l'exécution des étapes de test.
8. Résultat du test - Statut réussite/échec de l'exécution du test.
9. Statut d'automatisation - Identifiant de l'automatisation - si l'application est automatisée ou non.
10. Date - La date d'exécution du test.

11. Exécuté par - Nom de la personne qui exécute le scénario de test.

Qu'est-ce que le gel du code ?

• Le gel du code signifie la finalisation du code et aucun autre changement ne se produira dans le code.

Comment définiriez-vous que les tests sont suffisants et qu’il est temps d’entrer dans la phase de

clôture des tests ? Ou quand devrions-nous arrêter les tests ?

• Les tests peuvent être arrêtés lorsqu'une ou plusieurs des conditions suivantes sont remplies,
1.Après l'exécution du scénario de test – La phase de test peut être arrêtée lorsqu'un

cycle complet de scénarios de test est exécuté après la dernière correction de bogue

connue avec la valeur convenue du pourcentage de réussite.

2.Une fois le délai de test respecté - Les tests peuvent être arrêtés une fois les délais respectés.

sans aucun problème hautement prioritaire laissé dans le système.

 3. Basé sur le temps moyen entre les pannes (MTBF) - Le MTBF est l'intervalle de

temps entre deux pannes inhérentes. Sur la base des décisions des parties prenantes,

si le MTBF est assez important, la phase de test peut être interrompue.

4. Basé sur la valeur de couverture du code – La phase de test peut être arrêtée

lorsque la couverture de code automatisée atteint une valeur seuil spécifique avec

un pourcentage de réussite suffisant et aucun bogue critique.

Quels sont vos rôles et responsabilités de base

(AQ/testeur) ? • Comprendre et analyser les

exigences des tests. • Préparer des scénarios de test

pour les modules individuels. • Rédaction et

révision des cas de test selon les

exigences.
• Exécution des cas de tests.

• Création de défauts, vérification des défauts et gestion des

tâches d'assurance qualité. • Rapport hebdomadaire sur l'état

des tests. •
Communication continue avec l'équipe et le client.

• Préparation de la documentation du plan de test (si vous avez plus de 3 ans d'expérience).

Comment rédiger des cas de tests efficaces ?

• Des cas de tests efficaces ont été pris en compte

1. Les cas de test doivent être simples à comprendre, ce qui facilite leur examen et leur retest.

2. Les cas de test doivent se concentrer sur les exigences de l'utilisateur final.
3. Les cas de test doivent être capables de détecter des défauts.

S.
 4. Les cas de test doivent contenir les étapes et les données de test appropriées.
5. Les cas de test doivent être réutilisables

6. Les cas de test doivent exprimer les résultats attendus et réels.

Mentionnez quels sont les types de documents en assurance qualité ?

• Les types de documents en

assurance qualité sont • Document

d'exigence
• Mesures de test

• Cas de tests et plan de tests

• Organigramme de répartition des tâches

• Mélange de transactions

• Profils

utilisateur •

Journal de

test • Profils

utilisateur •

Rapport d'incident de test

S.
 • Rapport de synthèse des tests

Expliquez ce que vos documents d'assurance qualité doivent inclure ?

• Le document de test d'assurance qualité doit inclure •

Répertorier le nombre de défauts détectés selon le

niveau de gravité • Expliquer chaque exigence ou

fonction commerciale en détail • Rapports d'inspection

• Configurations • Plans de test

et cas de test • Rapports

de bogues • Manuels d'utilisation

• Préparer des rapports séparés pour les gestionnaires et les utilisateurs

===================================================
===========================

ICI NOUS DEVONS CRÉER ET AJOUTER DES IMAGES DE TYPES DE TEST :

Types de tests logiciels : 1. Tests

fonctionnels : les tests fonctionnels impliquent la validation des

spécifications fonctionnelles du système.

2. Tests non fonctionnels : les tests non fonctionnels comprennent le test des exigences non

fonctionnelles du système telles que les performances, la sécurité, l'évolutivité, la

portabilité, l'endurance, etc.

S.
Méthodes de test (méthodes de test) (boîte blanche, boîte noire, boîte grise)

1. Tests en boîte noire 2.

Tests en boîte

blanche 3. Tests

en boîte grise

Tests de boîte noire :

Les tests en boîte noire consistent à tester les exigences et les fonctionnalités sans connaissance
de

contenu interne. Les entrées sont introduites dans le système et les sorties sont

déterminées comme attendues ou inattendues.

S.
Tests en boîte blanche :

Les tests en boîte blanche sont des tests basés sur la connaissance de la logique interne (algorithmes)
d'un
le code de l'application. C'est une approche qui tente de couvrir les composants

internes du logiciel en détail. Les tests en boîte blanche sont également connus sous

le nom de « tests en boîte de verre », « tests en boîte transparente », « tests en boîte

transparente » et « tests structurels ».

Tests en boîte grise :

Les tests en boîte grise utilisent une combinaison de tests en boîte noire et blanche. Les cas

de test de la boîte grise sont conçus avec la connaissance de la logique interne

(algorithmes) du code d'une application, mais les tests réels sont effectués sous forme de

boîte noire. Alternativement, un nombre limité de tests en boîte blanche sont effectués,
suivis de tests conventionnels en boîte noire.
Niveaux de tests logiciels :
1. Tests unitaires 2.
Tests d'intégration
3. Tests du système 4.
Tests d'acceptation des utilisateurs (UAT)

1. Tests unitaires : •
Une unité est un composant ou un module unique de logiciel. • Les
tests unitaires sont effectués sur un seul programme ou un seul

module. • Les tests unitaires sont une technique de test en boîte

blanche.
• Les développeurs effectuent des tests unitaires.

• Techniques de tests unitaires :

Tests de chemin de base
Tests de structure de
contrôle Couverture
conditionnelle
Couverture de
boucles Tests de mutation .

2. Tests d'intégration : • Tests

d'intégration effectués entre deux ou plusieurs modules. • Les
tests d'intégration se concentrent sur la vérification de la
communication des données entre plusieurs
modules.

• Les tests d'intégration sont une technique de test en boîte blanche.

• Tests d'intégration effectués par le testeur au niveau de l'application (au niveau de
l'interface utilisateur). • Tests d'intégration effectués par le développeur au niveau du
codage.

• Types (techniques) de tests d'intégration :

S.
 Tests d'intégration incrémentielle a.
Approche
descendante b.
Approche ascendante
c. Approche
sandwich/hybride

Tests d'intégration non incrémentaux

3. Tests du système : (C'est le domaine dans lequel les testeurs sont principalement impliqués.)

S.
• Tester la fonctionnalité globale de l'application avec le
client respectif exigences.
• C'est une technique de boîte noire.
• L'équipe de test effectue des tests du système.
• Après avoir terminé les tests des composants (unités) et du niveau d'intégration, nous
démarrons le système essai.

• Les tests système se concentrent sur les aspects (types)

ci-dessous : Tests d'interface utilisateur
(GUI)
Tests d'utilisabilité
Tests fonctionnels
Tests non
fonctionnels
Tests in-system Nous effectuons tous les deux des tests fonctionnels et non fonctionnels.

Test de l'interface utilisateur (GUI) :

• Les tests d'interface utilisateur graphique ou tests GUI sont un processus de test de l'
interface utilisateur d'une demande.
 • Une interface utilisateur graphique comprend tous les éléments tels que les menus, les cases à
cocher,

boutons, couleurs, polices, icônes, contenu et images.

• Les tests GUI se concentrent principalement sur la partie front-end.

• Ici, nous nous concentrons principalement sur l'apparence et la convivialité de l'application.

Tests d'utilisabilité :

• Lors de ce test, l'application valide fournit ou non une aide contextuelle au

utilisateur.

• Vérifie avec quelle facilité les utilisateurs finaux peuvent comprendre et utiliser l'application
appelée

tests d'utilisation.

• C'est comme un manuel d'utilisation afin que l'utilisateur puisse lire le manuel et continuer.
Tests fonctionnels :

• Lors des tests fonctionnels, nous vérifions la fonctionnalité du logiciel.

• La fonctionnalité décrit ce que fait le logiciel . La fonctionnalité n'est rien d'autre que le
comportement de l'application.

• Les tests fonctionnels expliquent comment votre fonctionnalité devrait fonctionner.

Test des propriétés objectives

JE.

II. Test de base de données : opérations DML telles que l'insertion, la suppression, la
mise à jour, la sélection
 II
La gestion des erreurs
I.
Tests de calcul/manipulations
I Existence des liens et exécution des liens
V
.
V.
VI. Cookies et sessions

je. Test des propriétés objectives :

Vérifiez les propriétés des objets comme activer, désactiver, visible, focus, etc.

ii. Test de base de données :

Vérifier les opérations de la base de données concernant les opérations des

utilisateurs,

Opérations DML comme insérer, supprimer, mettre à jour, sélectionner

Validations au niveau des tables et des colonnes (Type de colonne, Longueur de
colonne, nombre
de colonnes...)
Relation entre les tables
(Normalisation) Fonctions
Procédures

Déclench
eurs
Index
Vues,
etc.

iii.
La gestion des erreurs:
Le testeur vérifie les messages d'erreur tout en effectuant des actions
incorrectes sur la demande.
Les messages d'erreur doivent être
lisibles. Utilisez un langage
c ensible/simple.
o
m
p
r
é
h

iv. Tests de calcul/manipulation :

Le testeur doit vérifier les calculs.

v. Existence des liens et exécution des liens :

Où exactement les liens sont placés - Existence des liens.
Les liens naviguent vers la bonne ou non - Exécution des
liens Types de liens :
Liens internes
je.
 ii. Liens externes
iii. Liens brisés

vi. Cookies et sessions :

Les fichiers temporaires sont créés par le navigateur lors de la navigation

dans les pages du l'Internet.

Les sessions sont des plages horaires créées par le serveur. La session sera expirée
après quelque temps. (Si vous êtes inactif pendant un certain temps.)

Types de tests fonctionnels :

• Fumée

•Santé mentale
• Unité

• Intégratio

n•
Système •

UAT (User Acceptance Testing) •

Nouveaux tests • Tests de

régression

Tests non fonctionnels

Tests non fonctionnels, nous vérifions les performances du logiciel

sous différents conditions.

Types de tests non fonctionnels :

un. Tests de performances

Tests de charge
Tests de
contrainte
Tests de volume
b. Tests de sécurité
c. Tests de
récupération d.
Tests de compatibilité e.
Tests de configuration f.
Tests d'installation g.
Tests
d'assainissement/déchets h. Tests
d'endurance i. Tests
d'évolutivité.
un. Tests de performances : vitesse de l'application.
Charge : augmentez progressivement la charge de l'application, puis
vérifiez la vitesse de l'application. Ici, charge signifie données.
Stress : Augmentez/diminuez soudainement la charge sur
l'application et vérifiez la rapidité de l'application.
Volume : vérifiez la quantité de données que l'application peut gérer. Ici,
nous appliquons d'énormes données au système jusqu'à ce qu'il se bloque.
Généralement, ce test est effectué pour vérifier comment le système répond
à un grand nombre d'utilisateurs à la fois.

b. Tests de sécurité : pour vérifier le degré de sécurité de

notre application. Authentification : L'utilisateur
est valide ou non.
Autorisation / Contrôle d'accès : Permissions de l'utilisateur valide.

c. Test de récupération :
Vérifiez le passage du système d'anormal à normal.

d. Tests de compatibilité :
Compatibilité
ascendante
Compatibilité
descendante
Compatibilité matérielle (tests de configuration)

e. Tests de configuration :
Il s'agit d'une combinaison de matériel et de logiciels, dans laquelle nous
devons tester s'ils communiquent correctement ou non. En termes
simples, nous vérifions
 comment les données circulent d'un module à l'autre.

F. Tests d'installation :
Vérifiez que les écrans sont clairs à comprendre.

Navigation dans les écrans

Simple ou pas.
Désinstallation.
 g. Tests d’assainissement/déchets
Si une application fournit des fonctionnalités/fonctionnalités supplémentaires,
nous considérons eux un bug.

4. UAT (Test d'acceptation de l'utilisateur) :

• Les tests d'acceptation utilisateur (UAT) sont un type de test effectué par l'utilisateur final
ou le client pour vérifier/ accepter le système logiciel avant de déplacer l'application
logicielle vers l'environnement de production. L'UAT est effectué dans la phase finale
des tests, une fois les tests fonctionnels, d'intégration et du système effectués.

• Voici deux types d'UAT :

o Tests alpha :
Généralement, les tests alpha sont effectués de notre côté selon
l'environnement client. Après le test alpha, le logiciel est prêt à être déployé
dans l'environnement client.
o Test bêta :
Tests bêta effectués côté client, où l'ensemble du système est testé selon
l'environnement client. Généralement, les tests bêta et alpha sont effectués par deux
équipes distinctes.

Cela est en grande partie réalisé par l'équipe qui est l'utilisateur fonctionnel de

ce logiciel. En tant qu'équipe d'assurance qualité, nous les assistons selon la

demande du client.

===================================================
===========================

Tests fonctionnels vs. Tests non fonctionnels :

Test fonctionel:

• Valide la fonctionnalité du logiciel.

• La fonctionnalité décrit ce que fait le logiciel .
• Se concentre sur les besoins des utilisateurs.
• Les tests fonctionnels précèdent les tests non fonctionnels.
Tests non fonctionnels :

• Vérifier les performances, la sécurité, la fiabilité du logiciel.

• Les tests non fonctionnels décrivent le fonctionnement du logiciel .
• Se concentre sur les attentes des utilisateurs.
• Tests non fonctionnels effectués après avoir terminé les tests fonctionnels.
 ===================================================
===========================

Techniques de test/Techniques de conception de tests/Données de test/Techniques écrites de test :

Utilisé pour préparer les données pour les tests.

Données

Couverture (couvre chaque domaine/fonctionnalité de la fonctionnalité)

• Techniques de conception de tests (lors de la conception des cas de test) (pour les tests en boîte noire) :

1. Partitionnement de classe d'équivalence (ECP)

2.Analyse des valeurs limites (BVA)

3.Tableau de décision
4. Transition d'État

5.Erreur de deviner

1.Partitionnement de classe d'équivalence (ECP) :

un. Partitionnez les données en différentes classes et nous pouvons sélectionner les données
 en fonction de la classe puis tester. Il réduit le nombre de cas de tests et permet de gagner

du temps pour les tests.

b. Vérification de la valeur.

c. Classez/divisez/partitionnez les données en plusieurs classes.

2. Analyse des valeurs limites (BVA) :

un. Nous nous concentrons principalement sur les limites

de la valeur. b. Ici, nous considérons 6 facteurs : Min, Min + 1, Min - 1, Max, Max + 1, Max – 1.
 *** Dans les tests de domaine d'entrée, nous utilisons principalement les techniques ECP et BVA.

***
Test du domaine d'entrée : la valeur sera vérifiée dans la zone de texte/les champs de saisie.

3.Tableau de décision :

un. La table de décision est également appelée table cause-effet.

b. Cette technique sera utilisée si nous avons plus de conditions et d'actions correspondantes.
c. Dans la technique de la table de décision, nous traitons des combinaisons d’entrées.
d. Pour identifier les cas de test avec une table de décision, nous considérons les conditions et les
actions.
e. Si nous avons un plus grand nombre de conditions/actions, alors nous

utilisons la table de décision technique.

Exemple de table de décision :

• Prenons un exemple de transfert d'argent en ligne vers un

 compte déjà ajouté et approuvé.

• Ici, les conditions pour transférer de l'argent sont les

suivantes : 1. Compte déjà approuvé.
2. OTP (mot de passe à usage unique) correspond.
3. Suffisamment d’argent sur le compte.
 • Et les actions effectuées sont les suivantes :
1.Transférer de l'argent.
2.Afficher un message indiquant le montant insuffisant.
3.Bloquez la transaction en cas de transaction suspecte.

4.Transition d'État :

un. Dans la technique de transition d'état, l'entrée est donnée en séquence, une étape à la fois. Sous
ceci

technique que nous pouvons tester pour un ensemble limité de valeurs d’entrée.

b. La technique doit être utilisée lorsque l'équipe de test souhaite tester une

séquence d'événements. ce qui se produit dans l'application testée.

c. Le testeur peut effectuer cette action en saisissant diverses conditions d’entrée dans une

séquence. d. Dans la technique de transition d'état, l' équipe de test fournit des résultats

positifs et négatifs.

saisir des valeurs de test pour évaluer le comportement du système.

S.
 5. Erreur de devinette :

un. La recherche d'erreurs est l'une des techniques de test utilisées pour détecter les bogues
dans une application logicielle en fonction de l'expérience antérieure
du testeur. b. Dans Erreur devinée, nous ne suivons aucune
règle spécifique. c. Cela dépend des compétences analytiques
et de l’expérience du testeur. d. Certains des exemples sont,
• Soumettre un formulaire sans saisir de valeurs. • Saisie
de valeurs invalides telles que la saisie d'alphabets dans le champ numérique.

===================================================
===========================

S.
Plan de test contre. Stratégie de test :

Qu'est-ce que le plan de test/planification des tests :

• Le plan de test sert de modèle pour mener les activités de test de logiciels en

tant que processus défini, qui est surveillé et contrôlé par le responsable

des tests.

• Un plan de test est un document détaillé/formel qui décrit la stratégie de test, les objectifs, le
calendrier, l'estimation, les livrables et les ressources nécessaires pour effectuer les tests d'un

produit logiciel. Le plan de test nous aide à déterminer l'effort nécessaire pour valider la

qualité de l'application testée.

Importance du plan de test : • Il

permet de définir comment le logiciel sera vérifié, ce qui sera spécifiquement testé et qui

effectuera le test. En créant un plan de test clair que tous les membres de l'équipe peuvent

suivre, tout le monde peut travailler ensemble efficacement.

• Le plan de test garantit la réussite de votre projet de test et aide à contrôler les risques.

Quand rédiger un plan de test :

• Les tests logiciels doivent commencer très tôt dans le cycle de vie du projet dès qu'il

existe un document d'exigences fonctionnelles (FRD). Le STLC se compose d'une

série de phases réalisées méthodiquement pour aider à certifier l'application testée.

Comment rédiger un plan de test :

• Analyser le produit •

Concevoir la stratégie de

test • Définir les

objectifs du test
• Définir les critères de test

Critères de
suspension Critères
de sortie

• Planification des ressources

• Planifier l'environnement de test

• Calendrier et estimation

• Déterminer les livrables des tests

Format du plan de test IEEE 829 (différents attributs du
plan de test) : 1. Identifiant du plan de test
2. Références
3. Introduction
4. Problèmes de risque logiciel
5.Éléments de test

6. Approche
7. Fonctionnalités à tester
8. Fonctionnalités à ne pas tester
9. Critères de réussite/d’échec
de l’article 10. Critères de suspension et exigences de reprise
11. Besoins environnementaux
12. Besoins en personnel
et en formation 13.
Responsabilités 14. Calendrier
15. Livrables des tests
16. Approbations
17. Glossaire
18. Tâches de test restantes
19. Planification des risques et des imprévus
 Contenu du modèle de plan de test : (QUE tester, COMMENT tester, QUAND tester) :
1. Vue d'ensemble

2. Portée
Inclusion

Exclusi

ons
Environnements de test 3.

Approche/stratégie de test 4.
Procédure de rapport de défauts 5.
Rôles/ responsabilités 6. Calendrier
des
tests

7. Tester les livrables

8. Tarification

9. Critères d'entrée et de sortie 10.

Critères de suspension et de reprise 11. Outils

12. Risques et atténuations 13.

Approbations

===================================================
===========================

Cas d'utilisation, scénario de test et scénario de test :

1. Cas d'utilisation : (décrit l'exigence)

un. Le cas d'utilisation décrit l'exigence.

b. Le cas d'utilisation contient trois éléments.

Acteur, qui est l'utilisateur, qui peut être une personne seule ou un groupe de
j
e personnes, interagissant avec un processus.
.
Action, qui doit atteindre le résultat final.

ii
.

iii. Objectif/Résultat, qui est le résultat d’une utilisation réussie.

2. Scénario de test : (Que tester) a. Une
zone possible à tester (Que tester). b. Le scénario de test
est un aperçu de toute fonctionnalité d'une application
logicielle sous essai.
c. Un scénario de test est dérivé d'un cas d'utilisation.
d. Nous pouvons dire que le scénario de test contient toutes les conditions qui
peuvent être déterminées tester la couverture par rapport aux exigences
commerciales.

3. Cas de test : (Comment tester)

un. Il s'agit d' une description détaillée de toute fonctionnalité expliquant comment
tester. b. Un cas de test est un ensemble d'actions exécutées pour valider une caractéristique
ou une fonctionnalité particulière de votre application
logicielle. c. Actions étape par étape à effectuer pour valider la fonctionnalité de l'AUT
(Comment tester). d. Le scénario de test contient les étapes de test, le résultat attendu et le
résultat réel. e. Il
contient de nombreux détails tels que les conditions préalables, les données de test, le résultat attendu,
le résultat réel, l'état. etc.
• Cas d'utilisation Cas de test V/s
un. Cas d'utilisation : décrit les exigences fonctionnelles, préparées par l'analyste
commercial (BA). b. Cas de test : décrit les étapes/procédures de test, préparées par
les testeurs.

• Scénario de test V/s Cas de test a. Le

scénario de test est « Ce qui doit être testé » et le scénario de test est « Comment
être testé ».
 • Suite de tests (banc d'essai) : a. Test

Suite est un groupe de cas de test appartenant à la même catégorie.

===================================================
===========================

• Contenu du cas de test (écriture) :

1. ID du scénario de test

2. Titre du scénario de test

3. Descriptio

n 4.

Condition

préalable

5. Priorité (P0, P1, P2, P3) - ordre (P0 - Fumée et santé mentale, P1 - Régression, P2 - Fonctionnel,

P3 - Interface utilisateur)

6. ID de l'exigence
 7. Étapes/ Actions

8. Résultat attendu
9. Résultat réel

10. Données de test

[AJOUTER UN MODÈLE BHUSHAN DE CAS DE TEST]

• Modèle de cas de test :

===================================================
===========================

• Scénario de test V/s

 ===================================================
===========================

• Environnement de test :

1. Test Environment est une plate-forme spécialement conçue pour l'exécution de scénarios de test sur le
produit logiciel.
2. Il est créé en intégrant les logiciels et le matériel requis ainsi

qu'un réseau approprié configuration.

3. L’environnement de test simule l’environnement de production/temps réel.
4. Un autre nom pour l'environnement de test est Test Bed.

5. Ce n'est rien, mais un environnement créé pour exécuter les scénarios de test.

===================================================
===========================

• Exécution des tests :

1. Effectuer des tests réels selon les étapes de test. c'est-à-dire qu'au cours de cette phase,

l'équipe de test effectuera les tests, sur la base des plans de tests et du scénario de

test préparés.

2. Critères d'entrée (entrées) : cas de test, données de test et plan de test.

3.Activités :

Les cas de tests sont exécutés sur la base de la planification

des tests. Le statut des cas de test est marqué, comme réussi, échoué, bloqué, exécuté, etc.
 La documentation des résultats des tests et des défauts du journal pour les cas d'échec est
effectuée.
Tous les cas de test chronométrés et ayant échoué se voient
attribuer des identifiants de bogue. Retester une fois
qu'ils sont
corrigés. Les défauts sont suivis jusqu'à la clôture.

4. Livrables (résultats) : fournit un rapport de défauts et un rapport d'exécution du

scénario de test avec les éléments terminés. résultats.

• Lignes directrices pour l'exécution des tests :

1. La version déployée dans l'environnement d'assurance qualité est la

partie la plus importante du test cycle d'exécution.

2. L'exécution des tests est effectuée dans un environnement d'assurance qualité (AQ).

3. L'exécution des tests se déroule en plusieurs cycles.

4. La phase d'exécution des tests consiste à exécuter les cas de tests + les scripts de tests (si
automatisation).

===================================================
===========================

• Matrice de traçabilité des exigences (RTM) :

1. RTM Décrit le mappage des exigences avec les cas de test.

2. L'objectif principal de RTM est de veiller à ce que tous les cas de test soient couverts afin

qu'aucune fonctionnalité ne soit manquée lors des tests logiciels.

3. Les paramètres RTM incluent :

ID de l'exigence

Description de l'exigence
ID des
cas de test
[Image : Un autre exemple parfait pour RTM]

Quels sont les différents types de RTM ?

• Traçabilité directe : ce document est utilisé pour mapper les exigences aux cas de test. Cela
vous aidera à garantir que votre projet avance dans la bonne direction. Cela garantira
également que toutes les exigences sont testées minutieusement.
• Traçabilité ascendante : lorsque vous mappez vos cas de test avec les exigences, vous créerez
une matrice de traçabilité ascendante. Cela vous aidera à vous assurer que vous n'étendez
pas la portée
du projet en ajoutant des fonctionnalités ou des fonctionnalités qui ne faisaient pas partie des
exigences initiales.
• Traçabilité bidirectionnelle : lorsque vous mappez les exigences des cas de test pour la
traçabilité aval et les cas de test aux exigences pour la traçabilité amont dans un seul
document, cela s'appelle une matrice de traçabilité bidirectionnelle. Ce document vous
aidera à garantir que toutes les exigences spécifiées ont des cas de test correspondants et vice
versa.
Comment créer une matrice de traçabilité des exigences ?
1. Fixez-vous des objectifs : la première étape à suivre avant de créer réellement un RTM est
de définir vos objectifs. Cela vous aidera à répondre à la question : à quoi servira le RTM
? Voici un exemple d'objectif dans lequel je souhaite créer une matrice de traçabilité pour
garder une trace des cas de test et des bogues qui seront impactés si des modifications
sont apportées aux exigences.
2. Collecter des artefacts : Une fois que vous avez défini votre objectif, vous devez maintenant
savoir de quels artefacts vous aurez besoin pour atteindre votre objectif. Pour créer une
matrice de traçabilité des exigences, vous aurez besoin de :
• Exigences

• Cas de tests
Résultats des tests

Bogues
La prochaine étape consistera à collecter ces artefacts. Pour cela, vous devrez accéder à la
dernière version des exigences et vous assurer que chaque exigence possède un identifiant
d'identification unique. Vous pouvez ensuite rassembler tous les cas de test de l'équipe de
test. Si les tests sont en cours ou s'ils sont terminés, vous aurez accès aux résultats des tests
ainsi qu'aux bugs trouvés.

3. Préparez un modèle de matrice de traçabilité : pour un modèle de matrice de traçabilité des

exigences, vous pouvez créer une feuille de calcul dans Excel et ajouter une colonne pour
chaque artefact que vous avez collecté.
Les colonnes dans Excel ressembleront à : Exigences, Cas de test, Résultats des tests

4. Ajout des artefacts : vous pouvez commencer à ajouter les artefacts dont vous disposez aux
colonnes. Vous pouvez désormais copier et coller les exigences, les cas de test, les résultats
des tests et les bogues dans les colonnes respectives. Vous devez vous assurer que les
exigences, les cas de test et les bogues ont des identifiants uniques.
Vous pouvez ajouter des colonnes distinctes pour indiquer l'ID de l'exigence, par exemple
Requirement_id, TestCaseID, BugID, etc.

5. Mettre à jour la matrice de traçabilité : La mise à jour de la matrice de traçabilité est un travail
continu qui se poursuit jusqu'à la fin du projet. En cas de changement dans les exigences,
 vous devez mettre à jour la matrice de traçabilité. Il se peut qu'une exigence soit abandonnée ;
vous devez mettre à jour cela dans la matrice. Si un nouveau scénario de test est ajouté ou
qu'un nouveau bug est trouvé, vous devez le mettre à jour dans la matrice de traçabilité des
exigences.

===================================================
===========================

Erreur, bug/défaut et échec :

• Erreur : C'est une erreur humaine. On peut dire qu'une erreur a été commise par le développeur.
• Bug/défaut : C'est la différence entre les résultats attendus et réels.
• Échec : il survient dans un environnement client/client. Lorsque les applications ne
peuvent pas fonctionner leurs fonctions.
 Pourquoi le logiciel a des

bugs ? • Complexité du

logiciel • Erreurs de

programmation •

Exigences

changeantes • Manque de
testeurs qualifiés

Pourquoi un défaut/bug se produit-il ? •

Lors des tests logiciels, le bug peut survenir pour les raisons suivantes : 1. Codage incorrect
2. Codage

manquant 3.

Codage

supplémentaire

===================================================
===========================

Défauts/bugs/problèmes : 1.
Toute fonctionnalité incompatible trouvée dans une application est appelée un défaut/bug/problème.
2. Pendant l'exécution des tests, les ingénieurs de test signalent les incohérences comme

défauts aux développeurs via des modèles ou à l’aide d’outils.

3. Outils de signalement des

défauts : o Terminer
la quête
 o DevTr

ack ou

Jira

o Centre de

qualité o Bug

Zilla etc.

Les outils de gestion des tests et les outils de suivi des bogues sont

complètement différents. Outil de gestion de tests (cas) vs. Outil de

gestion de projet vs. Outil de suivi des bogues.

===================================================
===========================

Contenu du rapport de défaut :

1. Defect_ID 2.

Description du

défaut
3.Versions
 4. Étapes
5. Données collectées
6. Référence
7. Détecté par
8. Statut

9. Fixé avant
10.Date de clôture
11.Gravité
12. Priorité

===================================================
===========================

Classification/Catégorisation des
défauts : • Gravité
1. Bloqueur (Afficher le bouchon)
2. Critique

3. Majeur

4. Mineur

• Priorité 1.
P1 (haute)
2. P2 (Moyen)
3. P3 (faible)
Gravité du défaut : ST (SST) (Severity-System) • La gravité est

attribuée/donnée par les testeurs d'assurance qualité. • Cela affecte

la fonctionnalité. • La gravité décrit la gravité

du défaut et son impact sur le flux de travail de l'entreprise (fonctionnalité). Il est classé en Bloqueur, Critique, Majeur, Mineur.

Priorité des défauts : DP (DIP) (Priorité-Personnes) • La priorité

est principalement donnée/attribuée par le développeur.

• Cela affecte les valeurs de l'entreprise.

• La priorité décrit l' importance des défauts. Le défaut dont la réparation est

urgente. • La priorité des défauts indique l'ordre dans lequel un défaut doit être

corrigé. • La priorité des défauts peut être classée en trois

catégories : 1. P1 : Le défaut doit être résolu immédiatement

car il affecte gravement le système et

ne peut pas être utilisé tant qu’il n’est pas réparé.

2. P2 : Il peut attendre qu'une nouvelle version/build soit créée.

3. P3 : Le développeur peut le corriger dans les versions ultérieures.

 [Image : Exemple]

===================================================
===========================
 Résolution des défauts :

Après avoir reçu le rapport de défaut de l'équipe de test, l'équipe de développement organise

une réunion d'examen pour corriger les défauts. Ensuite, ils envoient un type de résolution à

l'équipe de test pour plus de détails.

communication.

Types de résolution :
1. Accepter
2. Rejeter 3.
Duplique
r 4.
Améliora
tion
5. Besoin de plus d'informations

6. Non
reproductible 7.
Corrigé

8. Tel que conçu.

===================================================
===========================

Cycle de vie des défauts/cycle de vie des

bogues : • Le bug est le nom informel des défauts, ce qui signifie qu'un logiciel

ou une application n'est pas travaillant selon les exigences.

• Lors des tests logiciels, un bug logiciel peut également être un problème, une erreur, une

panne ou un échec. L'insecte s'est produit lorsque les développeurs ont commis une

erreur ou une erreur lors du développement du produit.

===================================================
===========================

Clôture du cycle de test :

un. Activités:

• Évaluer les critères d'achèvement du cycle en fonction du temps, de la couverture des tests,

du coût et du logiciel critique. Objectifs commerciaux, qualité.

• Préparer des métriques de test basées sur les

paramètres ci-dessus. • Documenter les

apprentissages du projet. • Préparer le

rapport de synthèse du test. • Reporting

qualitatif et quantitatif de la qualité du produit du travail au client. • L'analyse des

résultats pour connaître la répartition des défauts par type et gravité.

b. Livrables :

• Rapport de clôture des tests.

• Tester les métriques.

c. Métriques de test :
=================================================== ===========================

Activités d'assurance qualité/

test : • Comprendre les exigences et les spécifications fonctionnelles de l'application.

• Identifier les scénarios de test requis. • Conception de cas de tests pour valider

l'application. • Mise en place de l'environnement

de test (Test Bed). • Exécuter des cas de test sur

des applications valides. •

Consigner les résultats des tests (combien de cas

de tests réussissent/échouent.) • Rapport et suivi

des défauts. • Retestez les défauts corrigés de la

version précédente. •
Effectuer différents types de tests dans l'application. • Rend

compte aux Test Leas de l'état des tâches assignées. •

Participation aux réunions régulières de l'équipe. •

Création de scripts d'automatisation. • Fournit des

 recommandations quant à savoir si l'application/le
système est prêt ou non pour la production.

===================================================
===========================
 Terminologies de tests de logiciels :
(Autres types de tests) : un. Les tests de
régression

b. Re-tester

c. Tests exploratoires

d. Tests ponctuels

e. Tests sur les singes

F. Tests positifs

g. Tests négatifs

h. Tests de bout en bout

je. Tests de mondialisation et de localisation

un. Les tests de régression:

Tests effectués sur une version modifiée (version mise à jour) pour s'assurer qu'il n'y aura

pas d'impact sur les fonctionnalités existantes en raison de changements tels que

l'ajout/suppression/modification de fonctionnalités. En outre, nous pouvons dire que les

tests de fumée ne constituent qu'une petite partie des tests de régression.

1. Type de test de régression unitaire :

Tester uniquement les changements/modifications effectués par le développeur.

je.

2. Type de test de régression régional :

Test du module modifié ainsi que des modules impactés.

je.

ii. Une réunion d'analyse d'impact est organisée pour identifier les modules

concernés avec l'assurance qualité et développeur.

3. Type de régression complète :

test de la fonctionnalité principale et de la partie restante de l'application.

je.

ii. Exemple : Le développeur a apporté des modifications à de nombreux

modules. Au lieu d'identifier les modules concernés, nous effectuons un

cycle de régression complète.

• Lorsque nous avons effectué des tests de régression :

Une fois le défaut corrigé et un nouveau test effectué.

Modification, mise à jour, demande de changement en
fonctionnalité existante. Après ajout de nouvelles
fonctionnalités.
Avant la
sortie.

Après la
sortie.

Migration des données.

 Après changement d'environnement

b. Re-test :
1.
Chaque fois que le développeur corrige un bug, le testeur testera la correction du bug appelée re-
test.
2. Le testeur ferme le bogue s'il a fonctionné, sinon rouvrez-le et envoyez-le à un développeur.
3. S'assurer que les défauts trouvés et affichés dans la version
précédente ont été corrigé ou non dans la version actuelle.

4. Exemple :
La version 1.0 a été publiée, l'équipe de test a trouvé quelques défauts
j (Defect ID 1.0.1, 1.0.2) et les a publiés.
e
. La build 1.1 a été publiée, le test des défauts 1.0.1 et 1.0.2 dans cette build
est désormais un nouveau test.

ii
.

Re-tester VS. Les tests de régression:

Exemple de re-test vs. Les tests de régression:
Fumée contre. Test de santé mentale :
c. Tests exploratoires : •
Nous devons explorer l'application, la comprendre complètement et la tester.
• Comprendre l'application, identifier tous les scénarios possibles, la documenter, puis l'utiliser
pour tester.
• Nous effectuons des tests exploratoires lorsque l'application est prête, mais il n'y a aucune exigence.
• L'ingénieur de test effectuera des tests exploratoires lorsqu'aucune exigence n'est présente.

Inconvénients des tests exploratoires :

•Vous pourriez mal comprendre n'importe quelle fonctionnalité comme un bug (ou) n'importe
quel bug comme une fonctionnalité puisque vous

n'ont pas d'exigences.

• prend du temps.
• S'il y a un bug dans l'application, vous ne le saurez jamais.

d. Tests ponctuels :
• Tester l'application de manière aléatoire sans aucun cas de test ni aucune exigence
 commerciale document.
• Les tests ad hoc sont un type de test informel visant à briser le système.
 • Le testeur doit avoir une connaissance de l'application même s'il n'a pas d'exigences/cas de test.

• Ces tests sont généralement une activité imprévue.

e. Tests sur singes/gorilles :

• Tester les applications de manière aléatoire sans aucun cas de test ni aucune
exigence commerciale. • Les tests ad hoc sont un type de test informel visant à
briser le
système. • Le testeur n'a pas connaissance de l'application.
• Convient aux applications de jeux.

Tests ad hoc vs. Tests de singe contre. Tests exploratoires

F. Tests positifs :
• Tester l'application avec des entrées valides est appelé test positif. • Il
vérifie si une application se comporte comme prévu avec des entrées positives.

g. Tests négatifs
• Tester l'application avec des entrées non valides est appelé test

S.
négatif. • Il vérifie si une application se comporte comme prévu avec
les tests négatifs.

S.
 Positif contre. Cas de test négatifs : par

exemple, si une zone de texte est répertoriée en tant que fonctionnalité et que dans FRS, elle est mentionnée

comme une zone de texte qui accepte 6 à 20 caractères et uniquement des alphabets.

un. Cas de tests positifs :

1. Textbox accepte six caractères.

2. Textbox accepte jusqu’à 20 caractères.

3. Textbox accepte toute valeur comprise entre 6 et 20 caractères.

4. Textbox accepte tous les alphabets.

b. Cas de tests négatifs :

1. La zone de texte ne doit pas accepter moins de 6 caractères.

2. Textbox ne doit pas accepter de caractères de plus de vingt caractères.

3. La zone de texte ne doit pas accepter les caractères spéciaux.

4. La zone de texte ne doit pas accepter numériquement.

h. Tests de bout en bout :

1. Tester les fonctionnalités globales du système, y compris l'intégration des données entre

tous les modules sont appelés tests de bout en bout.

je. Tests de mondialisation et de localisation :

===================================================
===========================

Agile – Scrum

Modèle Agile/Méthodologie Agile/Processus Agile :

• Agile est une approche du développement logiciel dans laquelle les exigences et les solutions
évoluent grâce à l'effort collaboratif d'équipes auto-organisées et interfonctionnelles et de
leur client/client final.

• Les activités de développement et de test sont réalisées en parallèle et en collaboration. • En Agile, au

lieu des BA, le Product Owner collecte et discute avec le
client/fin client.

• Il s'agit d'un modèle de conception rapide à

attribution rapide. • Le modèle agile est une combinaison de modèles itératifs et incrémentaux.
Principes agiles : •
Les modifications des exigences sont acceptées par le client. • Ainsi, le
client n'a pas besoin d'attendre, ce qui assure sa satisfaction. • Nous

développons, testons et publions des logiciels avec certaines fonctionnalités.

 • L' ensemble de l'équipe travaille ensemble pour atteindre un
seul objectif. • Ici, nous nous concentrons sur la conversation
F2F.

• Nous suivons la nature itérative et incrémentale.

Avantages du modèle Agile : • Nous

pouvons accepter/accommoder les changements requis au milieu du développement. •

La sortie sera très rapide. • Ainsi, les clients n'ont pas besoin

d'attendre longtemps. • Créer une bonne

communication entre les équipes. • Modèle facile

à adapter. • Il convient aux petits et grands projets

de développement
de logiciels.

Inconvénients du modèle Agile : • Moins

d'attention portée à la conception et à la documentation, car nous nous concentrons sur une

livraison rapide du logiciel. • Le projet peut facilement dérailler si le représentant du client

ne sait pas clairement quel sera le résultat final.

résultat qu’ils souhaitent.

Tâche de développement :

• Réviser l'histoire •

Estimer l'histoire •

Concevoir

• Coder
• Tests unitaires •

Tests

d'intégration, etc.

Tâche d'assurance qualité :

• Revoir l'histoire
• Cas de tests

• Scénarios de tests

• Données de test

• Examen des tests

• Environnements de tests

• Exécuter des cas de tests

• Signaler les bugs, etc.

===================================================
===========================
Scrum : Scrum est un cadre à travers lequel nous construisons le produit logiciel en suivant les principes
Agile.

Flux de travail Scrum -

Témoignages d'utilisateurs → Backlog produit → Planification du sprint → Backlog de sprint

→ Sprint (1 à 3 semaines et réunions Scrum quotidiennes) → Produit → Revue de sprint et

réunion rétrospective

Équipe Scrum :

L'équipe Scrum implique,

1.Propriétaire du produit
2.Maître Scrum

3.Équipe de développement

4.Équipe d'assurance qualité

1. Propriétaire du produit :

• Le Product Owner est le premier point de contact.

• Il obtiendra l'avis des clients. • Définit

la fonctionnalité du produit. •

Hiérarchiser les fonctionnalités en

fonction de la valeur marchande. • Ajustez les

 fonctionnalités ou la priorité à chaque itération, si

nécessaire. • Le Product Owner peut accepter ou

rejeter le résultat du travail. • Il définira les

fonctionnalités du produit sous forme de User Stories

ou d'Epics.

2. Scrum Master :

• Scrum Master a pour rôle principal de faciliter et de piloter le processus

Agile. • Il agit comme un manager/chef d'équipe pour l'équipe Scrum. •

Il dirige toutes les

cérémonies Scrum.

3. Développeurs et assurance

qualité : • Développer et tester le logiciel.

 Avantages de Scrum (c'est-à-dire Agile Scrum) :
• La qualité peut être garantie car chaque Sprint sera testé plusieurs fois. • L'exigence

peut être acceptée à n'importe quel niveau de maintenance du projet. • Tous ceux qui
participent aux réunions
Scrum afin que la transparence puisse être maintenue. • Chaque Sprint que nous livrons au client afin
que nous puissions maintenir la satisfaction du client et éviter le risque de livraison du projet.
• Aide à économiser du temps et des coûts sur le projet.

===================================================
===========================

Définition de Prêt (DOR) :

Si les points ci-dessous sont prêts ou clairs concernant les User Stories, c'est DOR.

• La user story est claire. •

La User Story est
testable. • La User Story
est réalisable.
• …………………………..
• …………………………..
• …………………………..
• …………………………..

Définition de Terminé (DOD) :

Il est atteint lorsque,

• L'histoire est entièrement développée

• Tests (AQ) terminés • La
régression autour de l'histoire est terminée •
L'histoire répond et satisfait aux critères d'acceptation • La fonctionnalité
est éligible pour être déployée en production.
 ===================================================
===========================

Terminologies Scrum :

Backlog produit : contient une liste de toutes les exigences (comme les user stories et les epics). Préparé par
produit
Propriétaire.
Epic : collection de témoignages d'utilisateurs associés. Epic n'est rien d'autre qu'une exigence importante (de
haut niveau).

User Story : une fonctionnalité/un module dans un logiciel. Définir les besoins du client. Il ne s’agit

que de la formulation d’une exigence sous la forme d’une histoire.

Tâche : Pour atteindre l'équipe de développement des exigences commerciales, créez des tâches.

Sprint/Itération : Période/durée pour terminer (moyens de développement et de test) les user stories,

décidées/sélectionnées par le Product Owner et l'équipe. Cela dure généralement 2 à 4 semaines.

Sprint Backlog : liste des histoires engagées par les développeurs et les QA pour un sprint spécifique.

Réunion de planification du sprint : Il s'agit de la réunion avec l'équipe, pour définir ce qui peut être livré dans
le Sprint et sa durée.

Réunion de revue de sprint : ici, nous passons en revue et démontrons la fonctionnalité ou l'histoire
mise en œuvre par l'équipe à la partie prenante.

Réunion rétrospective Sprint : se déroule uniquement après la fin du Sprint. Toute l'équipe, y compris

le Product Owner et le Scrum Master, doit participer.

Ils discutent principalement

de 3 choses : Qu'est-ce
qui s'est bien passé ?

Qu'est-ce qui n'a pas

fonctionné ? Des améliorations sont nécessaires dans le prochain sprint.

Réunion de préparation de l’arriéré :

• Lors de cette réunion, l'équipe Scrum avec le Scrum Master et le Product Owner. • Le
propriétaire du produit présente les exigences commerciales et, selon l'équipe
prioritaire, en a discuté et identifie la complexité, les dépendances et les efforts. •L'équipe
peut également faire l'histoire en montrant du doigt à ce stade.

Scrum Meeting/Scrum Call/Standup Meeting : cela

se produit tous les jours. Points à discuter lors

des stand-up meetings quotidiens : Qu'allons-

nous faire aujourd'hui ? Qu'ai-

 je fait hier ? Tout

bloqueur/problème pour lequel

nous ne sommes pas en mesure

de continuer.

Story Point : estimation approximative donnée par les développeurs et le contrôle qualité sous la forme de la
série de Fibonacci.

Time Boxing dans Scrum : Le Timeboxing n'est rien d'autre que le Sprint qui est la durée spécifique pour
accomplir la quantité de travail spécifiée.

Écume de mêlées :

• Supposons que 7 équipes travaillent sur un projet et que chaque équipe compte 7 membres.

Chaque équipe dirige sa réunion Scrum particulière. Maintenant, pour coordonner les

équipes, une réunion distincte doit être organisée, cette réunion s'appelle Scrum of Scrums.

• Un ambassadeur (chefs d'équipe) (une personne désignée qui

représente l'équipe) représente le équipe dans la mêlée de mêlées.

• Quelques points discutés lors de la réunion

sont : Les

progrès de chaque équipe, après la

dernière réunion.
 La tâche est à faire avant la prochaine réunion.

Problèmes auxquels l'équipe a été confrontée lors de l'accomplissement de la dernière tâche.

Spike dans Agile Scrum : C'est une histoire qui ne peut

être estimée. Sprint zéro :

• Le sprint zéro a généralement lieu avant le début formel du projet.

• Ce Sprint doit rester léger et de niveau relativement élevé. Il s’agit avant tout de lancer

l’exploration d’un projet et de comprendre où vous souhaitez vous diriger tout en maintenant

une vitesse faible.

Scrum Board/Task Board : il montre

l'état de l'histoire. Scrum Board contient

des points comme,

• User Story : elle répond aux exigences métier réelles.

• À faire : tâches sur lesquelles on peut travailler.

• En cours : tâches en cours.

• À vérifier/tester : tâches en attente de vérification ou de test.

• Terminé : tâches terminées.

Release Candidate : La release candidate est un code/version/build publié pour garantir qu'au cours de
la dernière période de développement, aucun problème critique n'est laissé de côté. Il est utilisé pour
les tests et est équivalent
à la construction finale.
Vitesse : •

La vitesse (est une métrique) utilisée pour mesurer les unités de travail effectuées
(terminées) dans le temps donné cadre.

• On peut dire que c'est la somme des story points que l'équipe Scrum a complétés au cours d'un sprint.

Tableau de combustion:

• Indique la quantité de travail en attente/restant dans le sprint.

Maintenir par le Scrum Master tous les jours. La progression est

suivie par un graphique Burndown.

• Le graphique Burndown n'est rien d'autre qu'il montre que les Vs estimés. efforts réels de la tâche Scrum.

• Vérifier si les histoires progressent vers l'achèvement des

objectifs engagés. points d'histoire ou non.

Graphique de burnup : quantité de travail effectué dans le cadre d'un projet.

===================================================
===========================
Différence entre Scrum et Waterfall :

• Les commentaires des clients sont reçus à un stade précoce dans Scrum plutôt que dans

Waterfall. • Les nouveaux changements peuvent être facilement intégrés dans Scrum

plutôt que dans Waterfall. • Il est

facile de revenir en arrière ou d'adapter de nouvelles modifications dans Scrum.

• Les tests sont considérés comme une phase de la Waterfall, contrairement à Scrum.

Différence entre Scum et modèle itératif :

• Scrum est un type de modèle itératif, mais c'est un modèle incrémental + itératif. Au fur et à

mesure que nous divisons le produit en petites versions incrémentielles, de petites parties de

versions sont complétées en plusieurs itérations.

Toute autre méthodologie Agile en dehors de Scrum : • Kanban,

XP (Extreme Programming), Lean est une autre méthodologie Agile que Scrum.

Autres frameworks utilisés dans le modèle agile :

• Il existe certains développements et méthodologies où vous pouvez utiliser Agile, comme

le développement axé sur les fonctionnalités, le développement logiciel lean, les

méthodologies Crystal, le développement dynamique.

Différentes cérémonies se déroulent dans le Scrum :

• Réunion de

S.
 planification •

Réunion d'examen •

Réunion rétrospective •

Réunion de préparation du

backlog

Différents Amigos/personne impliqués dans le Scrum :

Il existe trois types de personnes impliquées dans Scrum : le Product Owner, le Scrum Master et

l'équipe Scrum qui comprend le développeur, le testeur et le BA.

La taille idéale de l’équipe Scrum est de 7 à

9 ressources. La durée idéale du Sprint est de

2 à 4 semaines.
Les exigences sont définies dans Scrum sous forme de User Stories.

S.
Différents artefacts dans Scrum :

Deux artefacts sont conservés dans Scrum :

• Product Backlog : contient une liste de toutes les user stories. Préparé par le
Product Owner. • Sprint Backlog : contient les User Stories validées par le

développeur et les assurances qualité pour un

Sprint.

===================================================
===========================

Questions supplémentaires :

• Types de tests d'acceptation des utilisateurs

1. Tests alpha
2. Tests bêta

• Différents outils pour les tests

fonctionnels : 1. Sélénium

2. QTP (produit HP)

3. SoapUI (c'est un outil API)

• Différents outils pour les tests non fonctionnels :

1. JMètre

2. Chargeur

3. LoadRunner

4. LoadStorm

5. NéoLoad
6. Prévisions

S.
 7. Chargement terminé

Alors, dans la mêlée, quelle entité est responsable des livrables ? Scrum Master ou Product Owner ? • Ni le
Scrum Master ni le
Product Owner. C'est la responsabilité de l'équipe qui
possède le livrable.

S.
Comment créer le graphique Burn-Down ?

• Il s'agit d'un mécanisme de suivi permettant de suivre un sprint particulier ; les tâches quotidiennes

sont suivies pour vérifier si les histoires progressent ou non vers l'achèvement des points

d'histoire engagés.
Ici, il faut rappeler que les efforts se mesurent en termes de user stories et non d’heures.

Que faites-vous dans une revue de sprint et une rétrospective ?

• Au cours de la revue du Sprint, nous passons en revue et démontrons la fonctionnalité ou

l'histoire mise en œuvre par le équipe Scrum aux parties prenantes.

• Lors de la rétrospective, nous essayons d'identifier de manière collaborative ce qui s'est bien

passé, ce qui pourrait être fait mieux et des mesures à prendre pour une amélioration

continue.

Quelles qualités doit avoir un bon testeur Agile ?

• Il faut être capable de comprendre rapidement les exigences.

• Il faut connaître les concepts et principes Agile.

• À mesure que les exigences changent constamment, il faut comprendre le risque que cela implique.

• Le testeur agile doit être capable de prioriser le travail en fonction des exigences.

• La communication est indispensable pour un testeur Agile car elle nécessite beaucoup de
communication avec les développeurs et associés d’affaires.

En quoi la méthodologie de test (développement) agile diffère-t-elle des autres méthodologies de test
(développement) ?

• Dans la méthodologie de test agile, l'ensemble du processus de test est divisé en un petit
 morceau de codes et à chaque étape, ces codes sont testés. Plusieurs processus ou plans sont

impliqués dans cette méthodologie comme la communication avec l'équipe, de courts

changements stratégiques pour obtenir le résultat optimal, etc.

Décrivez les endroits où « Scrum » et « Kanban » sont utilisés ? • « Scrum »

est utilisé lorsque vous devez passer à un processus plus approprié ou plus important, tandis que si

vous souhaitez améliorer l'exécution du processus sans aucun changement dans l'ensemble du

scénario, vous devez utiliser « Kanban ».

Pourquoi les user stories ne sont-elles pas simplement estimées en heures-

homme ? • L'estimation des user stories basée sur les heures de travail peut être effectuée, mais ce

n'est pas préférable. Si nous le faisons, nous nous concentrerons sur le coût et le budget de la

gestion tout en utilisant les heures de travail.

• Au lieu de cela, nous pouvons utiliser des story points, car ils donnent une idée complète de la

complexité du travail et des efforts requis qui ne peuvent pas être dérivés des heures-homme.

Pensez-vous que Scrum peut être implémenté dans tous les processus de développement logiciel ?

• Scrum est principalement utilisé pour

Projets complexes.
Projets qui ont des délais précoces et stricts.
Lorsque nous développons un logiciel à partir de zéro.

Dites-moi un gros avantage d’utiliser Scrum ?

• Le principal avantage est – un retour d'information précoce du client, donc si des

changements sont nécessaires, ils peuvent être fait au stade initial et produire le produit

minimal viable pour les parties prenantes.

Voyez-vous des inconvénients à utiliser Scrum ?

• Je ne vois aucun inconvénient à utiliser Scrum. Les problèmes surviennent principalement lorsque

l’équipe Scrum ne comprend pas les valeurs et les principes de la Scrum ou n’est pas

suffisamment flexible pour changer.

Si vous recevez une story le dernier jour du sprint à tester et que vous constatez qu'il y a des défauts,

que ferez-vous ? Allez-vous marquer l’histoire comme terminée ?

• Non, je ne pourrai pas marquer l'histoire comme terminée car elle présente des défauts ouverts

et le test complet de toutes les fonctionnalités de cette histoire est en attente. Comme nous

sommes le dernier jour du sprint, nous marquerons ces défauts comme différés pour le
 prochain sprint et nous pourrons raconter cette histoire au prochain sprint.

Comment mesurer la complexité ou l’effort dans un sprint ? Existe-t-il un moyen de

déterminer et de représenter il?

• La complexité et l'effort sont mesurés à travers des « Story Points ». Dans Scrum, il est recommandé

d'utiliser les Fibonacciseries pour le représenter. Compte tenu de l' effort de développement + de

l'effort de test + de la résolution des dépendances et d'autres facteurs qui nécessiteraient la

réalisation d'une histoire.

Lorsque nous estimons avec des story points, nous attribuons la valeur en points à chaque élément.

• Pour définir le Story Point - Trouvez l'histoire la plus simple et attribuez la valeur 1 à cette histoire

et, par conséquent, en fonction de la complexité, nous pouvons attribuer les valeurs aux user

stories.
Lors de la révision, supposons que le propriétaire du produit ou la partie prenante ne soit pas d'accord

avec la fonctionnalité que vous avez implémentée, que feriez-vous ?

• Tout d'abord, nous ne marquerons pas l'histoire comme terminée.

• Nous confirmerons d'abord l'exigence réelle de la partie prenante, mettrons à jour la user story et

la placerons dans le backlog. En fonction de la priorité, nous publierions l'histoire lors du

prochain sprint.

En dehors de la planification, de la révision et de la rétrospective, connaissez-vous d'autres cérémonies en

Scrum ?

• Ces trois réunions sont celles qui ont lieu régulièrement, à part celles-ci. Nous avons une autre réunion

qui est la réunion de préparation du backlog produit où l'équipe, le scrum master,

et le propriétaire du produit se rencontrent pour comprendre les exigences commerciales, les divisent en
user stories et les estiment.

Pouvez-vous donner un exemple de cas où Scrum ne peut pas être implémenté ? Dans ce cas, que proposez-vous
?

• Scrum peut être implémenté dans toutes sortes de projets. Cela ne s'applique pas seulement

aux logiciels, mais également mis en œuvre avec succès dans des projets de mécanique et

d’ingénierie.

Qu’est-ce que MVP en Scrum ?

• Un produit minimum viable est un produit qui possède juste le strict minimum de

fonctionnalités requises qui peut être montré aux parties prenantes et peut être

déployé en production.
Comment calculer un story point ? • Un story

point est calculé en considérant l' effort de développement + l'effort de test + la résolution des

dépendances et d'autres facteurs qui nécessiteraient la réalisation d'une histoire.

Vous êtes au milieu d'un sprint et soudain le product Owner vous présente une nouvelle exigence, que ferez-
vous ?

• Dans un cas idéal, l'exigence devient une histoire et se déplace vers le

backlog. Ensuite, sur la base du priorité, l'équipe pourra la reprendre lors

du prochain sprint.

• Mais si la priorité de l'exigence est vraiment élevée, alors l'équipe devra l'accepter dans le sprint, mais
il doit être très bien communiqué à la partie prenante que l'incorporation d'une histoire au milieu

du sprint peut entraîner des débordements. quelques histoires

avant le prochain sprint.

Quelles sont les meilleures matrices agiles ?

• Matrice d'avancement du sprint : indique la quantité de travail en attente/restant dans le sprint. Maintenir
quotidiennement par le Scrum Master.

La progression est suivie par un graphique Burndown. Cela montre que les Vs estimés. efforts réels
de la tâche Scrum.

• Vitesse : la vitesse (est une métrique) utilisée pour mesurer les unités de travail

effectuées (achevées) dans le temps donné. laps de temps.

• Répartition des catégories de travail : ce facteur nous donne une idée claire de l'endroit où nous

investissons notre temps ou de l'endroit où établir des priorités.

• Sensibilisation à l'élimination des défauts : des produits de qualité peuvent être livrés par les membres
actifs et leurs
conscience

• Organigramme cumulatif : à l'aide de cet organigramme, le

flux de travail uniforme peut être coché, où l'axe X

indique l'heure et l'axe Y indique le numéro. d'efforts.

• Une valeur commerciale délivrée : La valeur commerciale délivrée est une entité qui montre

l'efficacité de travail de l'équipe. Cette méthode permet de mesurer environ 100 points

associés à chaque projet. Les objectifs commerciaux reçoivent une valeur de 1,2,3,5 et ainsi

de suite en fonction de la complexité, de l'urgence et du retour sur investissement.

• Temps de résolution des défauts : c'est un processus par lequel le membre de

l'équipe détecte le bug et l'intention prioritaire par la suppression de l'erreur.

Une série de processus sont impliqués dans la correction du bug :

Effacement de l'image d'un bug

Correction du calendrier

La correction du défaut
 est effectuée Le rapport

de résolution est remis

• Couverture temporelle : temps accordé au code en question lors des tests. Il est mesuré par le rapport du
no. de la ligne de code appelée par la

suite de tests par le nombre total. des lignes de code relatives (en pourcentage).

Comment définir une user story ?

• Généralement, les User stories sont rédigées par BA. Donc, je ne suis pas sûr de la syntaxe,
mais c'est un processus de formulation des exigences sous la forme d'une histoire, c'est
une façon de décrire un ensemble de fonctionnalités/une exigence comme : « J'ai besoin
»

…, De sorte que ...".

Quel modèle SDLC est le meilleur ?

Les modèles SDLC sont sélectionnés en fonction des exigences du processus de développement.

Chaque modèle offre des fonctionnalités uniques pour le développement de logiciels. Pour cette

raison, cela peut varier d’un logiciel à l’autre pour décider quel modèle est le meilleur. Mais de

nos jours, le modèle Agile est le plus populaire et le plus largement adopté par les éditeurs de

logiciels.
 Différents types de plans de test dans les tests logiciels ?

Les plans de test peuvent être utilisés comme documentation de support pour un objectif de test

global (un plan de test principal) et des types de tests spécifiques (un plan spécifique à un type de

test).

• Plan de test principal : un plan de test principal est un document de haut niveau décrivant les

buts et objectifs globaux de test d'un projet ou d'un produit. Il répertorie les tâches, les jalons

et décrit la taille et la portée d'un projet de test. Il encapsule tous les autres plans de test du

projet.
• Plan spécifique au type de test : les plans de test peuvent également être utilisés pour décrire les
détails

liés à un type spécifique de test. Par exemple, vous pouvez disposer d'un plan de test pour les

tests unitaires, les tests d'acceptation et les tests d'intégration. Ces plans de test

approfondissent le type spécifique de test effectué.

Quelles sont les tâches importantes de la phase de

planification des tests ? • Comprendre et analyser les

exigences • Analyse des risques • Estimations des tests

—

(portée

du projet, délai, budget,

ressources disponibles)
• Constitution d'équipe

• Mise en œuvre de l'approche de test

(stratégie) • Définition de la configuration

de l'environnement de test • Matrice de

S.
 traçabilité •

Documentation du plan

de test

Quels sont les documents de référence pour la Planification des Tests ?

• Documents de référence pour l'étape de

planification des tests : Exigences

Plan de projet

Stratégie de test

•Documents de

conception Documents sur les directives

de processus Documents sur les normes d'entreprise, etc.

Qu’est-ce que l’analyse des points de test ?

• Une méthode d'estimation de test basée sur une formule basée sur l'analyse des points de fonction.

S.
Qu’est-ce que le processus de test logiciel ?
• Le processus de test fondamental comprend la planification et le contrôle des tests,
l'analyse et la conception des tests, la mise en œuvre et l'exécution des tests, l'évaluation
des critères de sortie et des rapports, et la clôture des tests.
activités.

Qu’est-ce que l’analyse des points de fonction ?

• Une Méthode visant à mesurer la taille des fonctionnalités d'un système d'information. La mesure est
indépendante de la technologie.
Cette mesure peut être utilisée comme base pour la mesure de la productivité, l'estimation
des ressources nécessaires et l'évaluation du projet.
contrôle.

Quels sont les critères d’entrée dans le plan de test ?

• L'ensemble des conditions génériques et spécifiques permettant à un processus d'avancer

avec une tâche définie, par exemple une phase de test. • Le but des

critères d'entrée est d'empêcher le démarrage d'une tâche qui entraînerait plus d'efforts

(gaspillés) par rapport à l'effort nécessaire pour supprimer les critères d'entrée ayant

échoué.

Quels sont les critères de sortie dans le plan de test ?

• L'ensemble des conditions génériques et spécifiques, convenues avec les parties prenantes,

pour permettre qu'un processus soit officiellement achevé. Le but des critères de sortie

est d'empêcher qu'une tâche soit considérée comme terminée lorsqu'il reste encore des

parties de la tâche en suspens qui ne sont pas terminées. Les critères de sortie sont utilisés

pour établir des rapports et planifier le moment où arrêter les tests.

Qu’est-ce qu’un livrable de test ?

• Tout produit de test (travail) doit être livré à quelqu'un d'autre que
celui du produit de test (travail). auteur.

Quels sont les livrables de test dans le processus de test logiciel ?

Les livrables des tests ne sont rien, mais les documents préparés après les tests. Les livrables

des tests seront livrés au client non seulement pour les activités réalisées mais également pour

les activités que nous mettons en œuvre pour une meilleure productivité.

Certains livrables de test du projet sont,

• Tester les livrables

 • Document de plan

de test, • Document

de cas de test, •

Documents de résultats de test (seront préparés à la phase de chaque type de test, • Rapport de test
ou rapport de clôture de projet (préparé une fois que nous avons déployé le projet

auprès du client), • Matrice de couverture , matrice de défauts et matrice de traçabilité,

• Spécifications de

conception des tests, •

Notes de version, •

Outils et leurs résultats,

• Journaux d'erreurs et

journaux d'exécution, •

Rapports de problèmes et

actions correctives

===================================================
===========================