OUTILS DE TEST

MANUEL
Test :
 Le processus d'identification des bogues dans un logiciel (projet/produit) est connu sous
le nom de "test".
 L'ingénieur de test doit vérifier (valider) si le logiciel développé est conforme ou non aux
exigences du client. Il est chargé de fournir un logiciel de qualité au client.

**Note : La principale responsabilité de l'ingénieur de test est de vérifier (valider) si

l'application développée (logiciel) est utile à l'utilisateur final ou non.

Bogue : L'écart par rapport à l'exigence est appelé bogue ou défaut.

Qualité:La justification de toutes les exigences du client par la convivialité et la sécurité est
connue sous le nom de qualité.
 Prenons un exemple :: Livré/libéré

Analyste commercial Document requis Entreprise DéveloppeurProjet/produit

Moi Architecte Plan Constructe Constructeur Accueil
ur
Client

Plan
Superviseur

Ingénieur d'essai

Projet :
Il sera développé sur la base des exigences du client ; une fois développé, il sera livré au client.
Les membres de l'équipe (utilisateurs finaux) l'utiliseront en fonction des besoins du client.
Ex : Spicejet.com, selenium4testing.com, construire sa propre maison selon ses besoins.
Produit :
Il sera développé en fonction des besoins de l'entreprise. Une fois développé, il sera mis sur le
marché en fonction des besoins du client, qui choisira le produit.
Ex:Mobile App, Calculator, Facebook, yahoo, MS Office, Mac operating system, windows
operating system, Gmail etc...

Types de tests :
 Outils de test

Tests fonctionnels Tests non fonctionnels

Test de charge

Tests manuels Tests d'automatisation Tests de performance

Selenium, winner runner Stress Testing

QTP, RFT, silktest, eau, test d'imbibition à l'eau

Applications basées sur l'Internet :

Ces applications sont accessibles dans le monde entier avec un nombre illimité d'utilisateurs.

Ex : Gmail, Facebook, selenium 4testing

Applications basées sur l'intranet :

Ces applications sont également accessibles dans le monde entier, mais avec un nombre limité
d'utilisateurs.

Ex : Applications limitées à une organisation spécifique.

Appel d'offres pour le projet :

Rôles impliqués :
1. Analyste commercial en marketing (BA)
2. Gestionnaire de l'engagement (EM)

 Analyste commercial en marketing (BA) :

L'agent de marketing rencontrera le client et le convaincra avec sa proposition. Lorsque le client

est satisfait de la proposition, le client et l'entreprise signent le projet.

Signer:

L'accord officiel entre le client et l'entreprise sur la réalisation du projet est connu sous
le nom de "signature".
 Réunion de lancement :

Une fois le projet approuvé, l'entreprise organise une réunion delancement. Il s'agit
d'une réunion rapide à laquelle participent tous les hauts responsables, qui annoncent
le projet et le client et choisissent le chef de projet. Le gestionnaire de projet est
responsable du cycle de développement durable.

 Gestionnaire de l'engagement (EM) :

Le responsable de la mission est chargé de maintenir la relation entre le client et l'entreprise. Il

fait le lien entre le client et l'entreprise.

Appel d'offres pour le projet

1 Cr
Client
A propos de 1 an
l'entreprise

L'histoire
Proposition Signer la fin
Estimations

Temps et coût
Réunion de
C1 C2 C3
lancement

2cr 1.5 cr 1 cr Chef de projet

2 ans 1,5 an 1 an
Hiérarchie des projets ou hiérarchie des désignations ou hiérarchie des rôles

LLM : Gestion de bas niveau

MLM : encadrement intermédiaire

HLM : Gestion à haut niveau

LE CYCLE DE VIE DU
DÉVELOPPEMENT LOGICIEL (SDLC) :
Il se compose des phases suivantes,

1. Phase des besoins

2. Phase d'analyse
3. Phase de conception
4. Phase de codage
5. Phase de test
6. Phase de livraison et de maintenance.

PIN:Note d'initiation/intimation de projet :

Il s'agit d'un courriel qui sera préparé par le chef de projet et qui contient la date de début et la
date de fin du projet. Le courrier sera envoyé au client et à la direction générale.
Le code PIN indique le début du projet.

1) Phase de demande :
Rôles:Analyste commercial
Responsable de l'engagement
Chef de projet

 Le BA est chargé de rassembler toutes les exigences dans un modèle de document

d'exigences (RTD).
 Une fois que toutes les exigences sont rassemblées dans le modèle d'exigences, ils
signent les exigences,
 Le document approuvé est connu sous le nom de SRS (Software/system requirement
specification) ou BRS (Business requirement specification) ou FRS(Functional requirement
specification) ou BDD(Business design document) ou BD (Business document).
 Une fois que le document SRS a été défini, le BA est responsable duPOC (Proof of
concept).
 Pendant le POC, le BA est chargé de développer le prototype qui sera présenté au
client.

Prototype : Il s'agit d'un échantillon d'application grossier et rapidement développé ; il

ne contient aucune des fonctionnalités réelles. Il décrit simplement comment le projet
va être et comment il va se présenter. L'objectif principal du prototype est de collecter
et de comprendre correctement toutes les exigences.

 Le responsable de la mission est chargé de maintenir le rapport ou la relation entre le

client et l'entreprise. Il se concentrera également sur les exigences supplémentaires, les
coûts supplémentaires et les délais supplémentaires du projet.
 Le gestionnaire de projet est responsable du suivi des phases et il aidera le BA et l'EM à
mener à bien leurs activités.
Note : Le résultat de la phase des exigences est le SRS et le prototype.

2) Phase d'analyse :analyse des besoins.

Rôles :Gestion à haut niveau
Encadrement intermédiaire
Chef de projet
BA
  Tous les acteurs susmentionnés se réuniront pour une réunion et effectueront les
activités suivantes
a. Étude de faisabilité
b. Choix de la technologie
c. Plan de ressources
d. Plan de santé et de sécurité
a. Étude de faisabilité: Faisable signifie possible ou non. Les rôles ci-dessus
prendront en charge chaque exigence dans le document SRS. Les exigences
seront analysées et l'on déterminera s'il est possible de les développer ou non. Si
c'est le cas, on déterminera le temps nécessaire au développement, aux tests et
à la livraison au client. Si une exigence n'est pas réalisable, ils en informent le
client.
b. Sélection des technologies : La liste des technologies telles que Java, .net,
MSSQL, Oracle, Selenium, etc. nécessaires au développement du projet, aux
tests et à la livraison au client sera décrite ici.
c. Plan de ressources :le nombre de ressources nécessaires pour le développement
et les tests du projet (développeurs, ingénieurs de test, ingénieurs de base de
données) sera décrit ici.
d. Plan du matériel et des logiciels :le nombre de matériels tels que les ordinateurs
de bureau, les ordinateurs portables, les téléphones mobiles, les imprimantes,
etc. ainsi que les logiciels nécessaires pour le projet seront décrits ici.

 Tous ces éléments seront consignés dans un document appelé "plan de projet". Il sera
envoyé au client pour examen.

3) Phase de conception :
Rôles : Architecte/architecte en chef
Analyste d'affaires (BA)
Chef de projet

 L'architecte passe en revue toutes les exigences du document SRS, et si des clarifications
sont nécessaires, l'agent d'exécution est responsable de l'élimination de toutes les
exigences non éliminées.
 Une fois que l'architecte a pris connaissance de toutes les exigences, il les divise en
plusieurs modules etsous-modules.
  Une fois que tous les modules sont divisés, il fournit le diagramme architectural
(diagramme de flux) de l'ensemble du projet à l'aide d'UML (langage de modélisation
unifié).
 Tous ces éléments seront consignés dans un document appelé "document de
conception" ou "SRS".

4) Phase de codage :
Rôles: Développer l'équipe
Équipe de test
BA
Chef de projet

 Une fois les modules divisés par l'architecte, ils seront attribués aux développeurs et à
l'équipe de test.
 Les développeurs sont chargés de développer le code source des modules. Une fois que
le code source est stable, ils l'enregistrent dans le dépôt central.
 Le responsable du développement extrait le code source de son système local, puis le
développe et le transmet à l'équipe de test pour qu'elle le teste.

Dépôt central :
 Le terme "référentiel" désigne un dossier de stockage. Le dépôt central est le dossier auquel
toutes les ressources de l'organisation ont accès. Il contient tous les fichiers sécurisés.
Ex: SVN - Sub Version
VSS- Visual source safe
TFS - Team Foundation Server
CVS - Système de versions concurrentes
Perforce, Github
Check in:Le processus de téléchargement des fichiers du système local vers le référentiel
central est connu sous le nom de Check in ou Commit.

Check out:Le processus de téléchargement des fichiers du référentiel central vers le système
local est connu sous le nom de Check out.

Build:Le processus de conversion du code source en code exécutable est connu sous le nom de
Build.

5) Phase de test :
Rôles:Ingénieurs d'essai
Équipe de développement
Analyste d'affaires (BA)
Chef de projet

 Une fois que le document SRS est terminé, il est envoyé à l'équipe de développement et
à l'équipe de test.
 L'équipe de développement est chargée d'examiner le document SRS, de le comprendre
et de développer la version.
 L'équipe de test est également chargée d'examiner le document SRS. Lors de l'examen,
si des exigences peu claires (doutes) sont identifiées, elles seront mises à jour dans le
document intitulé "Rapport d'examen (RE)".
 Le rapport d'examen sera envoyé au chef d'équipe qui consolidera (en un seul
document) tous les rapports d'examen en un seul document appelé "Rapport d'examen
consolidé(CRR)" et l'enverra à l'agent d'exécution.
 Le BA est chargé d'examiner toutes les exigences qui ne sont pas claires et de fournir
des éclaircissements, puis le "rapport d'examen actualisé(URR)" est envoyé à l'équipe
chargée des tests.
 L'équipe chargée des tests réexaminera le document SRS en y apportant des
clarifications.
 Une fois que l'équipe de test a bien compris toutes les exigences, elle prend le modèle
de cas de test et rédige les cas de test pour toutes les exigences.
 Les documents relatifs aux cas de test seront envoyés au BA. Il l'examinera et indiquera
s'il est nécessaire d'ajouter de nouveaux cas de test.
 Sur la base des commentaires du BA, l'équipe de test mettra à jour les cas de test.
 Une fois que les cas de test ont été établis (complétés), ils sont envoyés au client pour
un examen final.
 Une fois que la version est transmise à l'équipe de test, celle-ci exécute tous les cas de
test sur la version.
 Lors des tests, si des bogues sont identifiés, ils sont signalés (envoyés) à l'équipe de
développement. Le développeur le corrige et le renvoie à l'équipe de test pour qu'il soit
testé.
 L'ingénieur de test vérifiera si le bogue est réellement corrigé ou non et, en même
temps, il vérifiera s'il y a d'autres bogues.
 S'il est identifié, il sera signalé au développeur.
 Le même processus sera poursuivi jusqu'à ce que la version soit stable (sans bogues ou
pas de bogues).
 La version stable sera livrée au client.
 6) Livraison et maintenance:
Rôles:Ingénieurs d'essai
Équipe de développement
Analyste d'affaires (BA)
Chef de projet
Client

Livraison :Une fois que la version est stable dans l'environnement de test, l'équipe de test (TL)
envoie un courrier électronique au chef de projet pour lui indiquer que la version est stable,
puis le chef de projet livre la version au client.

 Le client déploiera la construction dans l'environnement scénique et effectuera des

tests.
 L'environnement d 'étapeest l'environnement commun dans lequel l'équipe de test et
l'équipe du client testent l'application avant qu'elle ne soit mise en service.
 Une fois que la construction est stable dans l'environnement d'essai, le client la déploie
dans l'environnement de production.
 Une fois que la construction est déployée avec succès dans l'environnement de
production/live, nous pouvons conclure que le projet a été livré avec succès au client.
Entretien :
L'expression "en direct" signifie que le client ou les utilisateurs finaux utilisent l'application. La
maintenance se poursuivra tant que l'application sera en service.

MaintenancePhase TAT
Correction des
Client
Délai d'exécution bogues, CR
BA/PM/TL
3 Bugs
(Amélioration)
3 CR Entreprise

12/24 heures 3 insectes - 3 jours

3 CRS - 4 jours

7 jours

 Une fois que le projet a été livré avec succès au client et qu'il a été déployé avec succès
dans l'environnement de production, la maintenance du projet est lancée.
 Pendant l'entretien, l'entreprise est responsable de deux activités.
a) Corriger les bogues.
b) Mise à jour des CR d'améliorations/demandes de changement.
 Tant que le projet est en cours, la maintenance du projet sera maintenue.
 Conformément à l'accord, l'entreprise assurera initialement une maintenance gratuite
pendant 3 à 5 ans (en fonction de l'accord sur le projet).
 Une fois la période de maintenance gratuite terminée, le client renouvellera l'accord de
maintenance.
  Lorsque le client envoie des bogues et des CRS, quelqu'un de l'entreprise (développeur,
BA, testeur) doit envoyer l'accusé de réception au client dans le TAT (délai d'exécution)
convenu selon l'accord, qui peut être de 12 ou 24 heures.
 Le courrier contient le nombre d'heures nécessaires à la réparation et à la livraison de la
nouvelle construction au client.
 Tant que le projet est en cours, la maintenance du projet sera maintenue.

Q. Quels types d'applications avez-vous testés ?

LES TYPES D'APPLICATIONS :

Trois types d'applications peuvent être testés ;

1) Applications Web
2) Applications de bureau
3) Applications mobiles

1) LES APPLICATIONS WEB:

Ces applications sont accessibles à l'aide d'un navigateur.

Il est de deux types
a) Applications de l'architecture à trois niveaux.
b) Applications de l'architecture N-Tier.

Environnement/système:

Toutes les applications sont des combinaisons de l'environnement.

L'environnement contient :
1. Couche de présentation.
2. Couche commerciale.
3. Couche base de données.
ENVIRONNEMENT

CANDIDATURE
COUCHE PRÉSENTATION/CLIENT

Réponse à la demande
SERVEUR
COUCHE D'AFFAIRES

Réponse à la demande
BASE DE
DONNÉES COUCHE DE BASE DE DONNÉES

1. Couche de présentation :

La partie frontale à laquelle l'utilisateur final va accéder est connue sous le nom
de couche de présentation/client.

2. Couche commerciale :

C'est le serveur qui est chargé de répondre à la demande. Cela signifie qu'il
prend la demande de l'application, l'envoie à la base de données, prend la
réponse de la base de données et la renvoie à l'application. L'ensemble de ce
processus est connu sous le nom de service de la demande.

Ex : Tomacat, JBoss, Weblogic, WebSphere, IIS

3. Couche base de données :

La couche base de données est chargée de stocker les données sous forme de
tableaux.
Ex: MS SQL, My SQL, ORACLE

a) Applications de l'architecture à trois niveaux:

Dans les applications à architecture à trois niveaux, les trois couches susmentionnées sont
disponibles dans trois machines différentes (couches) que nous appellerons "niveaux". C'est
pourquoi on parle d'applications à architecture à trois niveaux.

Ex : PL - Navigateur
SErver - Tomacat
Base de données - Oracle
b) Applications de l'architecture N-Tier:

C'est la même chose que les applications de l'architecture à trois niveaux. En fonction du
nombre d'utilisateurs (charge), nous aurons un plus grand nombre de serveurs et de bases
de données.

En fonction de la demande de charge, la logique commerciale sera répartie entre les serveurs
et les bases de données. C'est pourquoi nous l'appellerons "applications d'environnement
distribué".

PL PL PL

Serveur Serveur Serveur

BL

DB DB DB

DBL

2) LES APPLICATIONS DE BUREAU:

Ces applications sont accessibles sans navigateur.

Ex : Skype, calculatrice, MS Office, lecteur vlc, etc.
Elle est de deux types :
 1 étage
 2 niveaux

 1 étage:

Ces applications sont limitées à un système spécifique (PC). Les trois couches PL, BL et DBL
ne seront disponibles que dans ce système spécifique.
Ex : VLC player , Calc
 2 niveaux:

La couche de présentation sera disponible dans un système, la couche commerciale et la

couche de base de données seront disponibles dans un autre système, avec l'aide du
LAN/WAN, nous pouvons accéder à ces applications à partir de plusieurs systèmes. Nous
parlerons donc d'applications à deux niveaux, également connues sous le nom
d'applications d'architecture client-serveur.
Ex : Skype

NOTE:Pour les applications de bureau, nous devons installer l'application du côté de

l'utilisateur/client, puis nous sommes les seuls à pouvoir y accéder. Pour tester les applications
de bureau, nous devons le faire à la fois sur le client et sur le serveur.

Pour une application Web, nous devons la tester uniquement sur le client.

(BL)

Serveur + DBL

Applica
tion

LAN WAN LAN

M1 M2 M3
PL

3) LES APPLICATIONS MOBILES:

Les applications accessibles sur la plateforme mobile sont connues sous le nom
d'applications mobiles.
 Ex: Android, IOS, Blackberry, Windows, etc.

Ils sont de trois types

a. Applications natives
b. Applications Web
c. Applications hybrides

a. Applications natives :

Ces applications sont accessibles sans navigateur.

Ex: Viber, fonctionnalité d'appel, msg, horloge, etc.

b. Applications Web:

Ces applications sont accessibles à l'aide du navigateur du téléphone portable.

Ex: selenium4testing.com

c. Applications hybrides:

Ces applications sont accessibles à la fois sans navigateur et avec des navigateurs.
Ex : Gmail/application Gmail, Facebook/application Facebook, sites web/applications
bancaires, etc.

NOTE:Pour les applications web, il n'est pas nécessaire d'installer l'application du côté de
l'utilisateur/client car nous pouvons y accéder à l'aide d'un navigateur. Pour tester les
applications web, nous devons le faire uniquement sur le client.

LES MÉTHODOLOGIES D'ESSAI :

Q :Qui est responsable des tests ? À quel niveau l'ingénieur de test sera-t-il impliqué dans les
tests ?

Ils sont de trois types

a. Tests en boîte noire

b. Tests en boîte blanche
c. Tests de la boîte grise

a. Tests en boîte noire:

 Si la ressource effectue des tests sur la partie fonctionnelle de l'application, elle sera
considérée comme un "testeur de boîte noire".

La partie fonctionnelle consiste à déterminer si l'application développée répond ou non aux

exigences du client. Les testeurs effectuent des tests en boîte noire dans l'environnement de
test et dans l'environnement d'étape (environnement de pré-production).

b. Tests en boîte blanche :

Si la ressource teste la partie structurelle (programmation) de l'application, elle sera

considérée comme un "testeur boîte blanche". Les développeurs sont responsables des tests
boîte blanche dans l'environnement de développement.

c. Tests de la boîte grise:

Si la ressource a de l'expérience dans les deux types de tests (tests de la boîte blanche
et tests de la boîte noire). Il sera alors traité comme un "testeur de boîte grise".

LES NIVEAUX DE TEST :

Si un projet doit passer du stade de l'approbation à celui de la production, il doit subir les
niveaux de test ci-dessous.

1) Test au niveau de l'unité

2) Tests au niveau des modules
3) Niveau d'intégration des tests
4) UAT (tests d'acceptation par l'utilisateur)
5) Test du système

1) Niveau de test unitaire: L'unité est le plus petit flux ou scénario de l'application.
 Le développeur est responsable des tests unitaires.
 Il divise le module assigné en plusieurs unités et développe le code pour toutes
les unités.
 Il est chargé de vérifier si chaque unité fonctionne comme prévu ou non.

2) Tests au niveau du module :

 En ce qui concerne les tests au niveau du module, l'équipe de test et l'équipe de
développement sont toutes deux responsables.
 Le développeur combinera toutes les unités connexes pour former un module.
  Une fois le module développé, le développeur est responsable des tests en
boîte blanche dans l'environnement de développement.
 Une fois que le module est remis à l'équipe de test, celle-ci est responsable des
tests en boîte noire dans l'environnement de test.

3) Tests d'intégration:
 Le processus de combinaison de tous les modules développés est connu sous le
nom d'intégration.
 Vérifier si le flux de données navigue d'un module à l'autre est connu sous le
nom de test au niveau de l'intégration.
 L'équipe de développement et l'équipe de test sont toutes deux responsables
des tests d'intégration.
Ex: Créez un compte dans Gmail, vérifiez si vous pouvez vous connecter à
l'application avec le compte créé. Composez ensuite un message et envoyez-le,
puis vérifiez s'il a été correctement distribué ou non.
 Lors de l'intégration, si un module obligatoire est manquant, le responsable du
développement remplacera le module obligatoire par un code fictif appelé "stub"
ou "driver".

D1 D2 D3 D4 D5
+ + + + +
Connexion aux informations d'identification Composer
Envoyer Déconnexion

Stub/Driver:Les deux ne sont rien d'autre qu'un code factice, ils ne contiennent
aucune fonctionnalité.
  Si le responsable du développement utilise une approche descendante pour
intégrer les modules, lors de l'intégration, si un module obligatoire est manquant,
il sera remplacé par Stub.
 Si le responsable du développement utilise une approche ascendante pour
intégrer les modules, il remplacera le module obligatoire manquant par le pilote
lors de l'intégration.

4) Test d'acceptation par l'utilisateur:

 C'est ce qu'on appelle les tests d'acceptation par l'utilisateur/le client. Une fois
que la version est stable dans l'environnement de test, nous prévoyons de la
livrer au client. Avant de livrer la version au client, ce dernier enverra les cas de
test d'acceptation de l'utilisateur à l'équipe de test pour qu'elle les exécute.
 L'équipe de test exécutera tous les cas de test de l'AU dans l'environnement de
test ; si tous sont réussis, le chef de projet livrera la version au client.
 Le client exécutera à nouveau tous les cas de test de l'AU dans l'environnement
du client (environnement scénique). Si toutes les conditions sont remplies, le
client déploiera la version dans l'environnement Live ou Production.
 L'UAT est de deux types :

a.Tests alpha
b. Bêta-test UAT
Alpha testing Beta testing (UATCS)

(UATC) Environnement de testEnvironnement d'étape

a. Test alpha :L'exécution de tous les cas de test de l'AU dans un environnement de test
par l'équipe de test est connue sous le nom de "test alpha".

b. Bêta-test :L'exécution de tous les cas de test de l'AU dans l'environnement de stage
du client par l'équipe du client ou l'équipe de test est connue sous le nom de "bêta-
test".

Une fois le test bêta passé, le client passe à l'environnement réel.

Environnement de test Client

Construction (UATCS) passe

Construction de Démarrage
l'équipe de test Livrer

UATCS

5) Test du système:
 Il est également connu sous le nom de tests non fonctionnels. Une fois que
l'application est stable, nous pouvons passer aux tests non fonctionnels.
 Lors des tests non fonctionnels, les performances (temps de réponse) de
l'application seront identifiées.
 Le temps écoulé entre la demande et la réponse est appelé temps de réponse. Il
sera identifié à l'aide de plusieurs types de tests non fonctionnels tels que les
tests de charge, les tests de performance, les tests de stress et les tests de
rupture.
LES MODÈLES DE DÉVELOPPEMENT DE LOGICIELS :
Q. Quel processus avez-vous utilisé pour développer votre projet ?

Les modèles sont les suivants.

1) Modèle en cascade
2) Modèle en spirale
3) Modèle en V
4) Modèle de poisson
5) Processus agile

1) Modèle de cascade :
Il s'agit du processus ou du modèle initial introduit pour le développement de logiciels
(ancien processus). L'exécution séquentielle de toutes les phases du cycle de
développement durable est connue sous le nom de modèle de la chute d'eau. Une fois
la phase achevée, l'encadrement de haut niveau l'analyse.

REMARQUE : la façon dont les cascades se succèdent d'un niveau à l'autre, de la

même manière que les phases du SDLC seront mises en œuvre.

Avantages :

 Il est très facile de mettre en œuvre le projet car il s'agit d'une exécution
séquentielle.
 Inconvénients :

 Le risque thérapeutique ne peut pas être identifié à un stade précoce du cycle de

vie et ne peut donc pas être évité.
 Il s'agit d'un processus long et coûteux.
 Nous ne pouvons pas accepter que les exigences changent au milieu du projet.
Les demandes de changement sont effectuées à la fin du projet et les demandes
de changement sont facturées par l'entreprise.

mois

2) Modèle Spiral :

 Le modèle en spirale est une combinaison du modèle en cascade et du prototype.

  Au lieu de recueillir toutes les exigences en une seule fois, l'agent d'exécution en
recueille quelques-unes, qui seront analysées et conçues à l'aide du prototype. Il
sera ensuite remis au développement.
 Une fois que le développeur a mis au point la version, celle-ci est transmise à
l'équipe chargée des tests. Le même processus se poursuivra pour toutes les
exigences.
 Une fois que toutes les exigences sont remplies et que la version est stable, elle est
livrée au client.

Avantages :

 Nous pouvons économiser du temps et de l'argent, car nous exécutons toutes les
phases en parallèle.
 Le risque peut être identifié dès les premières étapes du cycle de développement
durable et il peut être évité dès les premières étapes du cycle de vie.
 La modification de l'exigence peut être acceptée au milieu du processus.

Inconvénients :

 Le risque de livraison est énorme, en raison des délais agressifs (moins de temps).
 Il n'est pas possible d'accepter un changement d'exigence à la fin du projet afin
d'éviter les risques de livraison.
 3) Modèle V (modèle de vérification et de validation) :
Validation:

Il est également connu sous le nom de "QC" (Quality control). L'équipe chargée des
essais est responsable de la validation. L'équipe de test vérifiera si le logiciel développé
correspond ou non aux exigences du client.

Les ingénieurs d'essai sont des validateurs.

Vérification:

Déf. 1 : Vérifier si chaque document de résultat de phase est conforme ou non aux
directives de l'entreprise et du client.

Def2:Vérifier si chaque rôle au sein de l'organisation fonctionne conformément à la politique de

l'entreprise.
Lignes directrices pour les entreprises et les clients ou non. La vérification est
également connue sous le nom d'AQ (assurance qualité).

Le groupe de gestion du projet/processus (PMG) ou le groupe d'audit sont responsables de

lavérification.

 À partir du modèle en V, même l'équipe chargée des essais participera à la collecte

des exigences.
 Le BA est responsable de la collecte des exigences, parallèlement l'équipe de test
analysera toutes les exigences pour vérifier s'il est possible de les tester ou non.
 Une fois le SRS défini, l'équipe de validation est responsable du plan de test.
 Sur la base des phases d'analyse et de conception, l'équipe de validation prépare le
plan de test du système et le plan de conception.
 Une fois le code développé, ils le transmettent à l'équipe de test qui effectue tous
les niveaux de test. Une fois que la version est stable, elle est livrée au client.

Avantages :
  Les activités de test sont lancées dès la phase de définition des besoins afin de
garantir la qualité.
 Pour chaque phase, l'équipe de vérification et l'équipe de validation vérifieront les
phases afin de garantir la qualité.
 Le risque peut être identifié à un stade précoce parce que nous avons une activité de
test parallèle, de sorte qu'il peut être évité.
 Nous pouvons accepter les changements d'exigences au milieu de la phase.

Inconvénients :

 C'est un processus long et coûteux, mais nous pouvons garantir la qualité.

4) Modèle de poisson :

 C'est la même chose que pour le modèle V.

 Dans le modèle poisson, nous aurons plusieurs équipes de vérification du client et de
l'entreprise pour vérifier le processus et fournir plus de qualité et de sécurité.
 Il est plus cher que le modèle V.
 Il offre une plus grande sécurité et est appliqué dans des projets de sécurité de haut
niveau tels que la NASA, l'armée de l'air, la marine, l'armée de terre, etc.
Note : L'équipe de validation examinera les résultats des tests unitaires lorsque la
version est en cours de développement.
5) Processus agile :

 Il comporte de nombreux sous-modèles tels que le modèle adaptatif, le modèle

Scrum, le modèle itératif, etc... Le modèle que nous allons utiliser est le modèle
Scrum.
 Il s'agit d'un modèle itératif et progressif. Le modèle Scrum comprend les activités
suivantes.
a. Maître de stage
b. Histoires d'utilisateurs
c. Réunion Scrum/appels Scrum/DSM
d. Plan Sprint
e. Réunion de sprint
f. Arriérés

a. Scrum master :

Le scrum master est la personne qui va diriger le projet. Le chef de projet ou le client
joue le rôle de scrum master. Le Scrum Master est responsable des réunions de scrum et
des réunions de sprint.

b. Histoires d'utilisateurs :
Les exigences seront saisies sous la forme de flux utilisés par l'utilisateur final (modes
d'utilisation par l'utilisateur final). C'est pourquoi nous l'appellerons " histoires
d'utilisateurs". La BA est chargée de collecter

c. Réunion Scrum :

 Chaque jour, tous les membres de l'équipe participent à une réunion rapide au
cours de laquelle ils décrivent les activités réalisées hier et les tâches prévues
aujourd'hui, ainsi que les difficultés éventuelles.
 Tous les membres de l'équipe, y compris le scrum master et le client, doivent
décrire.
 L'objectif principal de la réunion scrum est de suivre les ressources et de
maintenir la transparence.

d. Plan Sprint :

 Le sprint est une période de temps fixe qui peut être d'une semaine, de deux
semaines, de trois semaines, etc. C'est le chef de mêlée qui en décide.
 Le plan de sprint consiste à collecter des histoires d'utilisateurs, à les analyser, à
les développer, à les tester et à les livrer au client.
 Pendant le sprint, si nous ne sommes pas en mesure de répondre à l'une des
exigences, le sprint ne sera pas prolongé. Les exigences en suspens doivent être
reportées au sprint suivant. Le sprint est une période fixe

e. Réunion Sprint :

Une fois le sprint terminé, le plan du prochain sprint sera décidé lors de la réunion de
sprint. Ils discuteront de la réussite ou de l'échec du sprint en cours et des difficultés
rencontrées.

f. Retards :

Pendant le plan de sprint, si des histoires d'utilisateurs ne peuvent pas être réalisées,
elles seront considérées comme des Backlogs. Ces backlogs doivent être complétés au
cours du prochain sprint.

Elle est de deux types,

(i) Backlog de produit

(ii) Backlog de sprint
 Backlog de produit : Les exigences (histoires d'utilisateurs) que nous allons
collecter, développer, tester et livrer au client dans le cadre du plan de sprint
sont connues sous le nom de backlogs de produits.
Backlog de sprint: Les exigences qui ne sont pas satisfaites dans le cadre du plan
de sprint seront traitées comme le carnet de commandes du sprint.

Avantages:

 Chaque sprint sera testé plusieurs fois par l'équipe de test et le client, afin de garantir la
qualité.
 Toutes les phases du SDLC sont exécutées en parallèle, ce qui permet d'économiser du
temps et de l'argent.
 La modification des exigences peut être acceptée à n'importe quel stade du projet
(même après la livraison du sprint).
 Le risque peut être identifié à un stade précoce et il peut être évité
 Nous pouvons maintenir la transparence du projet.
 Le client participera également aux réunions scrum, ce qui nous permettra d'obtenir les
informations très rapidement.
 Chaque sprint est livré au client, de sorte que nous n'avons pas de risque de livraison.
 Nous pouvons obtenir la satisfaction du client en lui livrant tous les sprints.
 Le sprint est également connu sous le nom d'itératif. Son modèle itératif et progressif
Inconvénients :

Maintenir toutes les informations relatives au sprint est une tâche très difficile, mais nous
pouvons la surmonter avec l'aide d'outils de gestion des tests tels que Scrum wise, Quality
center, JIRA et test link, etc.

Types de tests fonctionnels (ou) Types de tests boîte noire :

1) Test de fumée:

 Une fois la version développée et déployée dans n'importe quel environnement, les
premiers tests sont effectués, c'est ce qu'on appelle les tests de fumée. Dans un premier
temps, l'équipe de développement déploie la version préliminaire dans l'environnement
de développement et effectue un test de fumée. Ils vérifient que chaque champ lié à un
module navigue correctement ou non sur ses pages et contrôlent la fonctionnalité
principale de l'application. L'objectif du test de fumée est de vérifier si la version est
prête à être testée ou non. Le développeur se concentrera sur les tests en boîte blanche
 Si tous ces champs naviguent correctement vers les pages correspondantes, ils
concluront que le test de fumée est réussi.

2) Test de santé :
 Une fois que la version est déployée dans l'environnement de test, l'équipe de test
effectue le test de fumée dans l'environnement de test. C'est ce que l'on appelle le test
d'équilibre.
 Lors du test de bon sens, l'équipe chargée du test effectue au moins un tour de la
fonctionnalité principale du flux et vérifie si elle fonctionne correctement ou non.
 Si le test d'intégrité est réussi, l'équipe de test exécute tous les cas de test. En cas
d'échec, l'équipe de développement rejette le projet.

Ex pour Main flow : Créer un compte dans Gmail, se connecter à ce compte, composer
un e-mail, l'envoyer à une adresse valide et vérifier s'il a été délivré correctement ou
non.

Note :Une fois le test de vérification effectué, l'équipe de test (responsable du test) doit
envoyer un e-mail contenant les résultats du test de vérification à l'équipe de développement.
 3) Tests préalables aux SRN:SRN - Software Release Notes (notes de mise à jour du
logiciel)

 Il contient l'état de la construction, par exemple le nombre de modules disponibles dans

la construction pour les tests.
 Nombre de modules en cours de développement.
 Nombre de stubs et de drivers disponibles dans le build.
 Nombre de bogues corrigés et disponibles dans la version.
 Nombre de bogues en cours de développement
 Lignes directrices en matière de déploiement, etc.

 Avant de transmettre le document SRN à l'équipe de test, cette dernière effectuera

un test de fumée dans l'environnement de développement, connu sous le nom de
test pré-SRN.
 Il est également connu sous le nom de Build acceptance testing (BAT) ou Build
verification testing (BVT).

Note : Une fois que la version est transmise à l'équipe de test, les ingénieurs de test
examineront le document SRN pour connaître le statut de la version (ce qu'elle contient).
Ensuite, le test effectuera un test de bon sens.

2. L'ordre est le suivant : l'équipe de développement effectue d'abord les tests de fumée, puis
l'équipe de test effectue les tests pré-SRN dans l'environnement de développement. Si les deux
sont acceptés, l'équipe de développement transmet la version à l'équipe de test, qui procède
alors à un test d'intégrité.
 4) Tests de l'interface graphique et de l'interface utilisateur :
Les cinq activités suivantes seront testées dans l'interface utilisateur graphique.

 Vérifiez l'orthographe de tous les champs.

 Vérifiez la police de tous les champs où elle doit rester cohérente.
 Vérifiez la couleur et l'alignement de tous les champs, qui doivent rester cohérents.
 Vérifier l'aspect général de la page

5) Tests de régression:

La réalisation de tests sur des fonctionnalités déjà testées dans les versions itératives et
incrémentielles est connue sous le nom de "tests de régression".

Elle sera réalisée de deux manières :

 Chaque fois qu'un bogue est identifié, il est signalé au développeur, qui le corrige et le
transmet à l'équipe de test sous la forme d'une nouvelle version (Build2). L'ingénieur de test
effectue un nouveau test pour vérifier si le bogue est réellement corrigé ou non.
 Les cas de test qui ont été passés sur l'ancienne version seront exécutés à nouveau sur
la nouvelle version et vérifieront s'ils fonctionnent de la même manière que la
précédente ou non.

Le test des fonctionnalités déjà testées se fait à l'adresse . Tester les nouvelles
fonctionnalités n'est pas un test de régression. Il relève de l'exécution des cas de test.
 Note :Si une mise à jour du code est effectuée, le nouveau code peut affecter le code
existant, c'est pourquoi nous effectuons des tests de régression.

6) Répétition des tests :

 Effectuer des tests sur les mêmes fonctionnalités encore et encore avec plusieurs
ensembles de données de test différentes sur la même construction est connu sous le
nom de "Retesting".
 L'exécution des cas de test qui ont échoué sur les versions itératives et incrémentielles
est également connue sous le nom de "re-test".

Données de test :Les données que l'équipe de test utilise pour les tests sont appelées
"données de test".

Ex : 1. Tester la fonctionnalité de connexion de Gmail avec plusieurs jeux de

données différents les références.

2. Tester la recherche d'aller simple de Spicejet avec plusieurs séries d'origines et

de passagers différents.

Q : Quelle est la différence entre le test de régression et le retesting ?

Q : Quelle est la différence entre les tests de régression et les tests

d'intégration ?

7) Tests de bout en bout :

L'ingénieur de test doit identifier tous les scénarios d'utilisation de l'application par l'utilisateur
final et vérifier si les scénarios de bout en bout fonctionnent correctement ou non.

En effectuant des tests de bout en bout, nous pouvons réaliser des tests au niveau de
l'intégration.

Ex: Le scénario de bout en bout pour Gmail.

 8) Test de compatibilité:

 Tester si l'application fonctionne comme prévu dans tous les environnements ciblés ou
non est connu sous le nom de "test de compatibilité". L'environnement est une
combinaison de systèmes d'exploitation, de navigateurs, de serveurs, de bases de
données, etc.
 Les tests de compatibilité sont de deux types :les tests inter-navigateurs et lestests inter-
plateformes.
 Tester si l'application web fonctionne comme prévu dans tous les navigateurs ciblés tels
que firefox, safari, google chrome, IE etc. est connu sous le nom de "cross browser
testing".
 Tester si l'application de bureau fonctionne comme prévu sur différentes plateformes
ou systèmes d'exploitation tels que Windows, LINUX, MAC, Solaris, etc. est connu sous
le nom de "test multiplateforme".

Ex pour les tests inter-navigateurs: Tester si le spicejet fonctionne dans les environnements ci-
dessous ou non.

Windows - Internet explorer, Firefox, Google chrome, Safari, Opera

Linux - Internet explorer, Firefox, Google chrome, Safari, Opera

MAC - Firefox, Google chrome, Safari, Opera

Ex pour les tests inter-plateformes :Testez si skype fonctionne dans les plateformes ou
environnements suivants
 Fenêtres
Linux
MAC et Mobile

Remarque : lorsque nous effectuons des tests de compatibilité, nous devons nous
concentrer davantage sur l'interface graphique de l'application.

9) Tests de convivialité :

 L'utilisabilité est la facilité d'utilisation. L'ingénieur d'essai doit assurer la convivialité de

l'application pour la satisfaction de l'utilisateur final.
 Cela dépend de l'application pour laquelle nous devons assurer la convivialité.

Ex : pour les applications bancaires (sécurisées), nous devons fournir plus de sécurité alors que
pour les sites sociaux (Face book, twitter), nous devons fournir plus de convivialité.

10) Tests ad hoc:

 Adhoc signifie à notre manière.

 Le test adhoc consiste à tester l'application à sa manière, après avoir compris toutes les
exigences et après avoir effectué au moins une série de tests manuels sur l'application.
 L'objectif principal des tests adhoc est de rendre l'application utilisable.
 11) Tests exploratoires :

 L'exploration consiste à identifier le nouveau besoin ou la nouvelle caractéristique. Une

fois que la construction est stable, les experts du domaine testent l'application en
fonction de leurs connaissances du domaine, tout en examinant si les exigences
existantes sont suffisantes, sinon ils fournissent de nouvelles exigences.
 L'objectif principal des tests exploratoires est d'assurer la convivialité et la sécurité de
l'application.

12) Test du singe/test du gorille:

 Une fois que l'application est stable, nous pouvons procéder à des tests sur des singes.
 Effectuer des tests sur l'application en réalisant des actions anormales est connu sous le
nom de tests Monkey/Gorilla.
 Les actions anormales signifient que l'on clique continuellement sur un champ pendant
une longue période et que l'on vérifie si l'application se bloque ou non.
 Testez l'application avec des données invalides telles que des balises HTML (<html>) et
vérifiez si l'application se bloque ou non.
Note: L'objectif des tests de singe est de vérifier si l'application se bloque ou non
(Means obtiendra une exception de type "serveur non trouvé").

13) Essais statiques :

 Tester l'application sans effectuer aucune action est connu sous le nom de test
statique.

Ex:1. Tests de l'interface graphique

2. Validations:- la vérification de la disponibilité des champs dans la page fait
partie des tests statiques.

14) Essai dynamique:

 Tester l'application en effectuant une action est connu sous le nom de test
dynamique.

Ex : tests de régression, retests, tests ad hoc, etc.

 15) Test d'authentification :

 L'authentification consiste à vérifier si les références/données sécurisées sont

disponibles dans la base de données ou non.
 Le test d'authentification consiste à tester l'application avec plusieurs séries de
données valides et non valides. Pour les données valides, l'application doit afficher la
page d'accueil, tandis que pour les données non valides, elle doit afficher le message
d'authentification approprié (message d'erreur).

Ex : Tester la fonctionnalité de connexion de HMS avec plusieurs jeux d'identifiants valides et

non valides. Il doit authentifier correctement l'application.

16) Test d'URL direct :

 Se connecter à une page sécurisée et prendre l'URL de la page sécurisée et accéder à

cette URL dans un nouveau navigateur. Lorsqu'il ne devrait pas être accessible, s'il
l'est, l'application n'est pas sécurisée.

Ex : Connectez-vous à Gmail.com, copiez l'URL de la page d'accueil. Ouvrez un nouveau

navigateur et accédez directement à l'URL, qui ne devrait pas être accessible.

17) Test d'étanchéité du pare-feu:

 Connectez-vous à l'application en tant qu'utilisateur d'un niveau et essayez

d'accéder aux données au-delà de la limite de votre rôle. Si elles sont accessibles,
nous en concluons que l'application ne fonctionne pas conformément au rôle (elle
présente une fuite du pare-feu).

Ex : Se connecter à l'application HMS en tant que Jr. Doctor et tente d'accéder

aux données de Sr. Médecin, là où il ne devrait pas être accessible
 18) Test de base de données :

 Tester si les données sont correctement insérées dans la base de données de toutes
les tables est connu sous le nom de test de base de données. À l'aide de requêtes
SQL, nous pouvons effectuer des tests sur les bases de données.

Ex : Lorsque nous créons l'enregistrement permanent dans HMS, tous les détails du
patient seront stockés dans la base de données HMS, en tant qu'ingénieur de test,
nous devons nous connecter à la base de données et vérifier si les données sont
correctement insérées dans toutes les tables ou non.

Test de déploiement/test d'installation: L'équipe de déploiement ou le

responsable des tests déploie la version dans plusieurs environnements tels que dev,
testing, stage1, stage2, production, etc. et vérifie si le déploiement s'est déroulé
correctement ou non.

Q : Une fois la version publiée, comment allez-vous la tester ?

R : Dans un premier temps, nous effectuerons des tests d'intégrité, s'ils sont concluants, nous
exécuterons tous les cas de test, puis nous effectuerons tous les types de tests fonctionnels
décrits ci-dessous.
Types de tests fonctionnels - flux d'exécution des tests fonctionnels sur le produit fini, une
fois qu'il a été remis à l'équipe chargée des tests.

Note : Pour toute application, tous les tests ci-dessus seront effectués pour s'assurer
que l'application répond aux exigences du client, qu'elle est de qualité et qu'elle est utile
à l'utilisateur final ou non.

2. S'il s'agit d'une application de bureau, il n'est pas possible d'effectuer des tests d'URL
directs ni des tests entre navigateurs.

Modèle de rapport d'examen:

Examinez le document SRS de spice jet et fournissez le rapport d'examen selon le modèle ci-
dessous.

ID de l'exigence Exigence Commentaires par TE Commentaires

Description
7. Lâcher d'adultes, d'enfants et de nourrissons 1. Quelle est la différence entre

Les descentes devraient être disponibles. Enfant, adulte et nourrisson

2. Quelles sont les valeurs des domaines de

l'adulte, de l'enfant, du nourrisson ?

19) Test de mondialisation :

Il s'agit de deux types

a. Tests de localisation.

b. Tests d'internationalisation.

a. Tests de localisation :

 Tester l'application dans toutes les langues locales propres à notre pays,
comme l'hindi, le bengali, le télougou, etc. est connu sous le nom de test
de localisation.
 Il prend en charge un maximum de 10 langues pour une intégration
unique. Nous l'appellerons donctest"L10N".

Ex:1. Testez Google.co.in dans toutes les langues locales comme l'hindi, le
bengali, le télougou, etc...

2. Tester le distributeur automatique de billets dans des langues locales telles que
l'hindi, le télougou et l'anglais.

b. Tests d'internationalisation :

 Tester l'application dans toutes les langues internationales comme le

japonais, le chinois, l'espagnol, etc. est connu sous le nom de test
d'internationalisation. Il prend en charge un maximum de 18 langues
pour une seule intégration. C'est pourquoi nous l'appelleronstest"I18N".

Ex : Tester Gmail.com dans toutes les langues internationales comme le

japonais, l'espagnol et le chinois etc...

LE CYCLE DE VIE DES TESTS DE LOGICIELS :

Il comprend les phases suivantes :

1) Plan de test du logiciel.

 2) Conception de tests de logiciels.
3) Exécution du test.
4) Analyse des résultats.
5) Rapports et BLC.
6) Livraison et entretien.
7) Rapport de synthèse de l'essai/ rapport post-mortem de la construction.

1. Plan de test du logiciel :

 Le plan est un document stratégique qui décrit comment exécuter une tâche de manière
efficace et efficiente.
 Le plan de test logiciel est également un document stratégique qui décrit comment
effectuer des tests de manière efficace et efficiente. Le plan de test sera préparé par le
responsable du test ; une fois préparé, il sera envoyé à l'équipe de test pour examen.
 Sur la base du plan de test, nous sommes chargés d'effectuer les tests.
 Il contient les activités ou l'index ci-dessous.

Plan de test Index

1. L'objectif

1.1 Champ d'application des tests

2. Documents de référence

3. Éléments du test

3.1 Caractéristiques à tester

3.2 Caractéristiques à ne pas tester

4. Stratégie d'essai

4.1 Types de tests

4.1.1 Types de tests fonctionnels

5. Environnement de test

6. Critères de réussite ou d'échec des tests

7. Analyse des défauts et fermeture

8. Produits livrables des essais

9. Tests d'automatisation

10. Risques et éventualités

11. Exigences en matière de matériel et de logiciel

12. Plan de ressources

13. Rapport de synthèse de l'essai/ rapport post-mortem de la construction.

1. L'objectif :

L'objectif principal du plan de test sera décrit ici. Il contient l'étendue des tests.

1.1 Portée des essais :

Les types de tests que l'équipe de test est chargée de tester sur l'application sont
connus sous le nom d'étendue des tests.

Ex: L'équipe de test est responsable des tests manuels et de l'automatisation du projet.

2. Documents de référence :

La liste des documents utilisés par le responsable du test pour préparer le plan de test est
décrite ici.

Le responsable des essais utilisera les documents du SRS pour préparer le plan d'essai.

3. Éléments du test :

3.1 Caractéristiques à tester :

La liste des fonctionnalités ou des modules dont l'équipe est responsable sera décrite
ici, ainsi que la liste des tests effectués par l'équipe de test sur les modules.

Ex: L'équipe de test est responsable de la réservation d'un vol, d'un hôtel et de la
gestion des réservations.

Pour les modules susmentionnés, ils sont responsables des tests manuels et de
l'automatisation.

3.2 Caractéristiques ne devant pas être testées :

 La liste des modules et des tests dont l'équipe de test n'est pas responsable est décrite
ici.

Ex : L'équipe de test n'est pas responsable des modules de paiement et n'est pas non
plus responsable des tests de performance, des tests de charge et des tests de stress.

4. Stratégie de test :

La stratégie est la liste des mesures que nous allons prendre pour réaliser le plan.

 La stratégie de test correspond à la liste des types de tests fonctionnels. Les mesures
que l'équipe de test va prendre pour effectuer les tests sont connues sous le nom de
stratégie de test.
 Nous effectuerons tous les types de tests fonctionnels tels que la régression, le re-test,
etc... sur l'application.
 En bref, un plan signifie ce qu'il faut faire. La stratégie consiste à savoir comment
réaliser le plan.

5. Environnement de test :

L'environnement est le système que nous allons utiliser pour déployer la construction et
tester l'application, appelé environnement de test.

Ex:Type de machine : Windows server enterprise

OS : Windows
Processeur : Intel Xeon CPU
Mémoire : 4GB/2.13 GHZ
Disque dur : 150GB
Base de données : Microsoft SQL server 2008 standard edition
Serveur web : IIS 7.0
Client : Microsoft internet explorer, Firefox, Google chrome

6. Test réussi/échec/critères :

Si un cas de test s'écarte du résultat attendu, il sera considéré comme un échec ou un

bogue.

Chaque bogue a un critère ou un type de bogue.

Elle est de cinq types

a. Bloqueur
b. Très élevé
c. Haut
 d. Moyen
e. Faible

7. clôture de l'analyse des défauts :

Au moment de la livraison de la version, si des bogues/défauts sont disponibles, ils seront

analysés par l'équipe de test et le chef de projet. Si un bogue n'a pas besoin d'être corrigé, il
sera fermé.

8. Produits livrables des essais :

La liste des modules que nous allons livrer au client est connue sous le nom de " livrables".

Tous les modules seront divisés en plusieurs phases et le responsable fournira également le
délai visé (date de livraison).

Délais (date de
Phase n° Modules livraison)

1. BookaFlight
2. ManageMy Booking
1 3. Statut du PNR 30 juin

2 4. Horaires de vol 31 juillet

5. Avantages pour l'entreprise

3 6. Connexion des épices 30 septembre

9. Tests d'automatisation :

Le nombre de modules que l'équipe de test va automatiser sera décrit ici, ainsi que l'outil
d'automatisation et la stratégie que les ingénieurs de test vont suivre.

10. Risques et éventualités :

La liste des risques auxquels l'équipe va être confrontée lors de l'exécution du projet et de la
solution correspondante sera décrite ici.

Risques Éventualités
Maintenir les ressources
Manque de ressources tampons

Changements continus des exigences Analyser les besoins

Absence d'évaluation par les pairs Suivi Examens par les pairs

11. Exigences en matière de matériel et de logiciel :

Le nombre de machines (ordinateurs portables, téléphones mobiles, imprimantes, etc.)

nécessaires pour les tests, ainsi que les logiciels correspondants, seront décrits ici.

12. Plan de ressources :

Le nombre de ressources nécessaires pour les tests manuels, les tests d'automatisation et les
tests de base de données sera décrit ici.

13. Rapport de synthèse de l'essai/établissement d'un rapport post mortem :

Une fois les tests terminés, le responsable des tests doit préparer le rapport de synthèse des
tests, qui contient le résumé des tests.
 2) Conception de tests logiciels :
Le processus de rédaction des cas de test sur le modèle de cas de test après avoir compris
toutes les exigences est connu sous le nom de "conception de test logiciel".

 Chaque organisation aura son propre modèle, sur la base duquel l'ingénieur de test est
chargé de rédiger les cas de test.
 Nous disposons des modèles ci-dessous pour écrire les cas de test. Il contient une page
de garde, des cas de test, des données de test, une matrice de traçabilité et un rapport
de test.

Exigence- Test priorité TC Test Pré- Test Réel Attendu Résulta Comment
Types de ment ID scénario production types Résulta Résultat t aires
t
ID

Page de couverture :

Nom du module :

Nombre total de cas de test :

Nombre de cas de test P1 :

Nombre de cas de test P2 :

Nombre de cas de test P3 :

Nombre de cas de test P4 :

Requirement ID : Le numéro de l'exigence pour laquelle nous écrivons les cas de test sera décrit
ici.

Types de tests: Le type de cas de test est appelé type de test. Il en existe cinq types.

 GUI
 Validation
 Cas de test positif (ou) Cas de test positif fonctionnel.
 Cas de test négatif (ou) Cas de test négatif fonctionnel
 Cas de test de la base de données
 Cas de test positif : Le test de l'application avec toutes les données valides est connu
sous le nom de scénario de test positif.

Cas de test négatif : Tester l'application avec au moins une donnée invalide est connu
sous le nom de scénario de test négatif.

Priorité : Elle décrit l'importance du cas de test et se décline en plusieurs types : P1, P2, P3 et
P4.

P1 : Si le cas de test décrit la fonctionnalité principale de l'application/module, il sera

traité comme P1.

La fonctionnalité principale signifie que si le cas de test a échoué, nous ne pouvons

pas poursuivre les tests. La priorité est donc "P1".

P2 : Si le cas de test décrit la fonctionnalité au niveau du champ, la priorité est "p2".

Le cas de test au niveau du terrain signifie que s'il échoue, nous pouvons continuer
les tests, mais il est important qu'il soit présent dans l'application conformément aux
exigences du client.

P3 : Tous les cas de test de l'interface utilisateur graphique relèvent de la priorité P3.

P4 :L'ingénieur de test a la possibilité de donner des suggestions à l'application. Ces

suggestions seront reprises sous la forme de cas de test et la priorité est alors "P4".

ID du cas de test: le numéro de série du cas de test sera décrit ici.

Scénario de test :Le scénario est un flux ou une méthode utilisée par l'utilisateur final.
L'exigence sera divisée en tous les flux ou scénarios utilisés par l'utilisateur final et ceux-ci
seront décrits ici. L'ingénieur de test doit identifier le maximum de flux possibles (scénarios)
pour l'exigence ou l'histoire de l'utilisateur.

Condition préalable :la condition requise pour tester le scénario est décrite ici.

Étapes du test :la liste des étapes nécessaires à l'exécution du scénario est décrite ici. Sur la
base des étapes de test, l'ingénieur de test exécutera l'application ou la construction.

Résultat attendu :Au moment de la rédaction des cas de test, nous n'aurons pas l'application
avec nous. Nous attendons donc le résultat du scénario. Le résultat escompté sera mis à jour
dans la colonne du résultat escompté.

Résultat réel:Il sera mis à jour au moment de l'exécution des cas de test.l'ingénieur de test
observera le comportement réel de l'application pour le scénario et il sera mis à jour ici.
Résultat:Une fois l'exécution du test terminée, l'ingénieur de test compare le résultat réel au
résultat attendu. Si les deux correspondent, il met à jour le résultat comme réussi, sinon il le
met à jour comme échoué.

Commentaires :L'autorité de contrôle ou le client fournira les commentaires ici.

Consulter le document des CTs sur la connexion à Gmail

Techniques de conception des tests :

Pour réaliser des tests de manière efficace, nous devons suivre les techniques de
conception de tests ci-dessous.

1. Analyse de la valeur limite (BVA)

2. Partition en classes d'équivalence (ECP)

3. Deviner l'erreur

1. Analyse de la valeur limite (BVA) :

Lorsque nous devons tester une plage de 1 à 100 ou de 1 à 1000 ou de 1 à 1 manque ou

de 1 à 2 manques, il n'est pas possible d'effectuer des tests exhaustifs (tests complets).
Nous devons donc appliquer la technique BVA.

 Divisez la plage en plusieurs limites comme min-1, min, min+1, milieu, max-1,
max et max+1.
 Pour effectuer le test positif, tester le champ avec min, min+1, middle, max-1, et
max. Là où il devrait accepter. (Cas de test +ve)
 Pour effectuer un test négatif, tester le champ avec min-1 et max+1. Là où il ne
devrait pas accepter. (Cas de test -ve)
 S'il fonctionne comme indiqué ci-dessus, nous pouvons en conclure qu'il
n'accepte que la plage.
Scénario de test +Ve : Vérifier le champ avec les limites min, min+1, middle, max-1, et max.

-Scénario de test : Vérifier le champ avec les limites min-1 et max+1

2. La partition en classes d'équivalence (ECP) :

Lorsque nous avons des exigences particulières, comme vérifier si le champ (nom
d'utilisateur ou mot de passe) accepte les caractères tels que a à z, A à Z, 0 à 9 et #
%@$&*. En même temps, le champ ne doit pas accepter les caractères spéciaux tels
que <>-+/\.

 Dans ce cas, il n'est pas possible d'effectuer des tests exhaustifs avec tous les
caractères. Nous devons donc suivre la technique ECP.
 Divisez les données d'essai en deux classes égales.
a. Classe de données d'essai valides b. Classe de données de test non valide
 Préparer les données de test de toutes les manières possibles.
 Pour effectuer un test positif, il faut tester le champ avec des données de test
valides. Où il doit accepter. (Cas de test +ve)
 Pour effectuer un test négatif, il faut tester le champ avec des données de test
non valides. Lorsqu'il ne doit pas être accepté (cas de test Its -Ve)
 Si le fonctionnement est conforme aux attentes, nous pouvons conclure qu'il est
conforme aux exigences.
 3) Erreur de devinette :

Chaque fois qu'un bogue est identifié par l'ingénieur de test, il doit être signalé au
développeur, qui le corrige et le renvoie à l'équipe de test. L'ingénieur de test vérifiera si le
bogue est réellement corrigé ou non. En même temps, il doit deviner les erreurs ou les bogues
dans les fonctionnalités correspondantes. Il doit également tester les fonctionnalités connexes.
C'est ce qu'on appelle la "supposition d'erreur".

Ex : Dans la page PR, le message d'alerte ne s'affiche pas, cela a été corrigé par le développeur
et testé par le testeur. Où le message d'alerte fonctionne correctement dans la page PR.
L'ingénieur chargé des tests doit maintenant se pencher sur les fonctionnalités connexes telles
que l'avis d'admission et l'admission, puis rechercher (en supposant) le même type de bogue.

Matrice de traçabilité :

Il s'agit de vérifier si l'ingénieur de test a couvert tous les cas de test pour l'ensemble des
exigences ou non.
 Sur la base de la matrice de traçabilité, le responsable ou le client vérifiera si l'ingénieur de
test a couvert tous les cas de test ou non.

Identifiant
Nombre du cas de
Req ID de CT test Commentaires
1 1 1
2 1 2
3 1 3
4 1 4
5 1 5
6 1 6
7 1 7
8&9 5 8 à 12 ans
L'exigence n'est pas
Pas encore claire. En attente des
10 mis en œuvre commentaires de BA

4) Exécution du test :

 Le processus d'exécution des cas de test sur l'environnement de test est connu sous le
nom d'exécution des tests. Chaque fois que la version est mise à la disposition de
l'équipe de test, l'ingénieur de test doit consulter le document SRN pour connaître l'état
de la version.
 Sur la base du document SRN, le responsable des tests déploie la version et l'équipe
chargée des tests effectue des tests de vérification.
 Une fois le test d'intégrité terminé, les résultats sont envoyés par courrier au
développeur.
 Si le test d'intégrité est réussi, l'équipe de test continuera à exécuter les cas de test, si le
test d'intégrité est échoué, l'équipe de test rejettera la version à l'équipe de
développement.
 Lors de l'exécution des cas de test, l'ingénieur de test observera le comportement réel
de l'application pour le scénario et le mettra à jour dans le champ des résultats réels. Il
en sera de même pour tous les cas de test.

5) Analyse des résultats :

 Lors de l'exécution des cas de test, l'ingénieur de test met à jour le champ du résultat
réel, puis il compare le résultat réel avec le résultat attendu, si les deux correspondent, il
fournit le résultat comme réussi, sinon il le met à jour comme échoué.
  Pour la réussite, nous utiliserons la couleur verte, tandis que pour l'échec, nous
utiliserons la couleur rouge. L'exécution du test et l'analyse des résultats sont deux
processus parallèles.

Note : Une fois l'exécution des cas de test terminée, nous sommes chargés d'exécuter tous les
types de tests fonctionnels sur l'application afin d'identifier les bogues.

* Combien de cas de test pouvons-nous écrire en une journée ?

Tout dépend des exigences et de l'ingénieur de test, mais en moyenne, nous pouvons écrire
environ 40 à 50 cas de test par jour. Cela signifie que nous prenons environ 8 à 10 minutes pour
un cas de test afin d'analyser les besoins et de préparer le cas de test sur le modèle de cas de
test avec les données de test.

* Combien de cas de test pouvons-nous exécuter en une journée ?

Cela dépend également des cas de test et de l'application, mais en moyenne, nous pouvons
exécuter 50 à 60 cas de test par jour, car il faut revoir le cas de test et l'exécuter sur
l'application.

L'exécution d'un scénario de test prend en moyenne 5 à 8 minutes.

6) Rapport :

 Le processus de signalement/envoi des bogues (cas de test échoués) au développeur est

connu sous le nom de "reporting".
 Il en existe deux types.

1. Signaler les bogues en utilisant les fichiers XL.

2. Signaler les bogues à l'aide d'outils de signalement.

1. Signalez les bogues en utilisant le fichier XL :

L'ancienne procédure consistait à utiliser le modèle ci-dessous pour mettre à jour le bogue et
l'envoyer au développeur.

Ins Titre du Statut Sévérité Prior Descrip Capture Constr Signal Attribué
ect bogue/ ité tion du d'écran uire é Commentaires
e Résumé bogue Versio Par
ID n à
1.

Bug ID :

Le numéro de série du bogue sera indiqué ici.

Titre du bug/résumé :

Le résultat effectif du bogue sera décrit ici.

Statut :

En fonction du bogue, les ingénieurs de test ainsi que le développeur sont chargés de donner le
statut. Il est en dessous des types.

 Nouveau :
Chaque fois que l'ingénieur de test identifie un bogue. Au départ, le statut du bogue est
Nouveau. Le nouveau bogue sera signalé au développeur.
 Ouvert :
Le développeur vérifiera si le nouveau bogue est réellement un bogue ou non. Si oui,
nous mettrons à jour le statut de nouveau à ouvert.
 Fixé/vérifié :
Le développeur prendra un certain temps pour corriger le bogue ouvert, une fois qu'il
sera corrigé, il mettra à jour le statut d'ouvert à corrigé. Le bogue corrigé sera envoyé à
l'ingénieur chargé des tests.
 Fermé :
L'ingénieur chargé des tests vérifiera si le bogue corrigé fonctionne réellement comme
prévu ou non. Si cela fonctionne, nous mettrons à jour le statut de "corrigé" à "clôturé".
L'état fermé est la fin de l'insecte.
 Re ouvert :
Le bogue corrigé sera testé par l'ingénieur de test ; s'il ne fonctionne pas comme prévu,
il fera passer le statut de corrigé à réouverture et le bogue réouvert sera renvoyé au
développeur.
 Le développeur vérifie s'il s'agit réellement d'un bogue ou non. Si c'est le cas, il l'ouvre,
corrige le bogue et le renvoie à l'équipe de test.
 Rejeté/pas de bogue/en attente/différencié :
Lorsque l'ingénieur de test identifie un bogue, il le signale au développeur avec un
nouveau statut. Si le développeur n'accepte pas le bogue, il mettra à jour le statut de
nouveau à Rejeté/pas un bogue et le bogue sera renvoyé à l'équipe de test.

Gravité :

Il décrit l'importance de l'impact du bogue sur l'application lors des tests. La sévérité désigne la
gravité de l'insecte. Il est inférieur aux types.

 Bloqueur :
Si le bogue bloque l'ensemble des tests du module, la gravité ou le type de bogue est
bloquant.
 Très élevé :
Si le bogue bloque partiellement les tests du module, la gravité du bogue est très
élevée.
 Haut :
Si le bogue ne bloque que le scénario spécifique du module, la gravité est élevée.
 Moyen :
Tous les bogues de l'interface graphique sont de gravité moyenne.
 Faible :
L'ingénieur de test a également la possibilité de faire des suggestions. La suggestion sera
donc signalée sous la forme d'un bogue, dont la gravité est faible.

Priorité :

La priorité décrit dans quel ordre le bogue doit être corrigé par le développeur. En fonction
de la gravité, l'ingénieur de test donnera la priorité au bogue comme suit

Sévérité Priorité
 Bloqueur/Urgent/critique P1

Très élevé P2

Haut P3

Moyen P4

Faible P5

Description :

Les étapes détaillées pour produire/obtenir le bogue seront décrites ici. En fonction de ces
étapes, le développeur vérifiera s'il s'agit réellement d'un bogue ou non.

Capture d'écran :

L'ingénieur de test fera une capture d'écran du bogue et la téléchargera dans le modèle de
bogue. Il s'agit de prouver que le bogue signalé est valide et de comprendre ce bogue.

Version de construction :

Le numéro de build sur lequel l'ingénieur de test a identifié le bogue sera décrit ici.

Rapporté par :

L'ingénieur de test qui a identifié le bogue le décrira ici.

Assign to:Le nom du développeur ou le nom du responsable du développement, qui va corriger

le bogue, sera décrit ici.

Commentaires :

Les ingénieurs d'essai et les développeurs peuvent poser des questions sous forme de
commentaires.

Note :Le rapport sur le fichier XL prendra beaucoup de temps, c'est pourquoi nous prévoyons
d'utiliser les outils de rapport.

Ex :
 ID Titre du
Phase DU bogue / Priorit
s BUG Résumé Statut Sévérité é Description de l'insecte Capture d'écran

L'application 1. Ouvrez Spicejet.com

n'affiche pas 2. Cliquez sur le bouton radio
les deux Roundtrip
sélecteurs Nouve 3. L'application n'affiche pas les deux
I 1 de date au Bloqueur P1 sélecteurs de date D:\NNagesh\NSPiceje

Le nom de
Spicejet
s'affiche 1. Ouvrez Spicejet.com
comme Nouve 2. Observez le logo Spicejet
II 2 spacejet au Moyen P4 3. Il s'affiche en tant que spacejet D:\NNagesh\NSPiceje

Le bouton
radio 1. Ouvrez Spicejet.com
Oneway ne Nouve Très 2. Le bouton radio Oneway n'est pas
III 3 s'affiche pas au élevé P2 disponible Chemin d'accès
La case à
cocher
"étudiant" 1. Ouvrez Spicejet.com
n'est pas Nouve 2. La case à cocher "étudiant" n'est
I 4 disponible au Haut P3 pas disponible Trajectoire
Changer la
couleur de la
page
d'accueil de
spicejet en Nouve
II 5 bleu au Faible P5 1. Ouvrir Spicejet.com Trajectoire
Le lien vers
le club
Spicejet ne
permet pas 1. Ouvrez Spicejet.com
de naviguer 2. Cliquez sur le lien Spiceje Connect
vers la page 3. Le lien Spiceje Connect ne permet
du club Nouve pas de naviguer vers la page
III 6 Spicejet au Bloqueur P1 MySpicetrip Trajectoire

1. Ouvrir
L'application http://selenium4testing.com/hms
ne maintient 2. Se connecter à l'application
pas 3. Cliquez sur Search Registration
l'interface Nouve 4. L'application ne gère pas
I 7 graphique au Moyen P4 l'interface graphique Spicejet_GUI.png
 L'interface 1. Ouvrir
graphique http://selenium4testing.com/hms
de la liste de 2. Se connecter à hms avec
travail user1/user1
d'admission 3. Cliquez sur ADT
n'est pas 4. Cliquez sur Admission worklist
maintenue 5. Observez l'interface graphique,
correctemen Nouve elle ne se maintient pas
II 8 t au Moyen p4 correctement. D:\NNagesh\Nhms_AD

Le champ 1. Ouvrir http://spicejet.com

adulte ne 2. Observer tous les champs
s'affiche pas Nouve 3. La liste déroulante des adultes
III 9 sur la page au Bloqueur P1 n'est pas disponible D:\NNagesh\NSpiceje

L'application 1. Ouvrir http://spicejet.com

n'affiche pas 2. Cliquez sur le champ LeavingFrom
Hyderabad Nouve Très 3. L'application n'affiche pas
I 1 et Bangalore au élevé P2 Hyderabad et Bangalore D:\NNagesh\NSpiceje
Q : Quelle est la différence entre gravité et priorité ?

Q : Quelle est la différence entre la priorité dans les cas de test et la priorité dans les modèles
de bogues ?

Q.Si le développeur n'accepte pas votre bogue, comment allez-vous prouver que votre
bogue est valide ?

R : Sur la base de la description du bogue, du document SRS et des captures d'écran,

nous essayons de prouver que le bogue est valide. S'il n'est pas accepté, je prends le journal
des interruptions pour prouver que le bogue est valide, s'il n'est toujours pas accepté, je
l'envoie à un BA, au chef de projet et enfin au client.

Q. Expliquez le scénario dans lequel le bogue a une gravité élevée avec une priorité faible et
une sécurité faible avec une priorité élevée.

A:Gravité Priorité

Bloqueur - P1

Sécurité élevée Très élevée - P2 Priorité élevée

Haut - P3
 Moyen - P4

Faible sécurité Faible - P5 Faible priorité

Nous avons deux bugs, l'un est un bloqueur et l'autre un moyen. Le bloqueur aura une
priorité élevée et le moyen aura une priorité faible.

En fonction de la gravité, l'ingénieur chargé des tests accordera la priorité. En fonction de la

priorité, l'équipe de développement est chargée de corriger

Mais le responsable du développement a la possibilité de modifier la priorité, en

fonction de la situation.

 Les bogues liés à la livraison de la phase actuelle seront convertis en priorité élevée,
quelle que soit leur gravité.
 Les bogues qui ne font pas partie de la livraison actuelle seront convertis en priorité
faible, quelle que soit leur gravité.

Phase Id de bogue Titre du bogue/Résumé Statut Gravité Priorité

I. 1. Spice jetname affiche New Medium P4---P1

En tant que jet spatial

2. 2. Spice jet connect link is not New Blocker P1----P4

Naviguer sur la page spice jet connect

Rapport d'essai/rapport sur l'état d'avancement de la construction :

Une fois que l'exécution du cas de test est terminée sur le build, l'ingénieur de test
est chargé d'envoyer un rapport de test au responsable ainsi qu'au client. Le format ci-
dessous
Rapport sur l'état de la construction/Rapport d'essai

Rapport sur l'état de la construction / Rapport de test

Test Engg Name :
Construire Non 1
Identifiants de connexion
 Navigateur FF, IE GoogleChrome

Matrices de test
Nombre total de cas de test 200
Nombre de cas de test exécutés 150
Nombre de cas de test en
attente 50
Nombre de cas de test réussis 100
Nombre de cas de test Échec 50
Nombre de cas de test ignorés 10
Nombre de bogues signalés 3

Métriques de test :

Le terme "métrique" désigne la mesure de la tâche. Les métriques de test signifient la mesure
des tests.

En attente :

Si le développeur n'a pas donné de fonctionnalité du tout, ces cas de test ne peuvent pas être
exécutés. Il est en cours d'examen.

Sautée :

Le développeur a fourni les fonctionnalités, mais nous ne sommes pas en mesure de

les tester, car les fonctionnalités dépendantes ont échoué.

Ex : si la connexion a échoué, nous ne pouvons pas exécuter la composition.

La composition des cas de test est ignorée.

 Le rapport sera poursuivi jusqu'à ce que la version soit stable, ce qui signifie que la
majorité des cas de test sont réussis et qu'aucun bogue bloquant n'est disponible dans
l'outil de rapport.
 La version stable sera livrée au client.

Q : Expliquez-moi la structure hiérarchique de votre organisation.

Signaler les bogues en utilisant les outils de signalement :

 Tout outil de reporting a deux types d'utilisateurs : L'un est l'utilisateur administrateur
et l'autre est l'utilisateur final.
 Utilisateur administrateur: L'utilisateur administrateur est responsable de la création du
projet, de la création d'utilisateurs tels que les ingénieurs de test, les développeurs, etc.
Il affectera l'utilisateur au projet
  L'utilisateur final: Il est responsable de l'utilisation (rapport) ou de la réception des
bogues, par exemple : ingénieurs de test, développeurs, etc.

Ex : QC, JIRA, Bugzilla, Redmine, Test manager etc...

BugZilla :

 Accédez à Bugzilla en utilisant selenium4testing.com

 Cliquez ensuite sur Bugzilla.
 mailto:jan30selenium@gmail.comSe connecter à Bugzilla en tant qu'ingénieur de
test(jan30selenium@gmail.com& password : selenium)
 En utilisant Bugzilla, nous pouvons effectuer les activités suivantes.
a. Signaler un bogue.
b. Recherche des insectes.
c. Nous pouvons prendre le rapport.
d. Préférence.

Introduction à Bugzilla
Qu'est-ce que Bugzilla ?
Bugzilla est un système open-source de suivi des problèmes et des bogues qui
permet aux développeurs de suivre efficacement les problèmes en suspens concernant
leur produit. Il est écrit enPerl et utilise la base de données MYSQL.

Bugzilla est un outil de suivi des défauts, mais il peut être utilisé comme outil
degestion des tests et peut donc être facilement relié à d'autres outils de gestion des cas de
test tels queQuality Center, Testlink, etc.

Ce système ouvert de suivi des bogues permet aux utilisateurs de rester en contact
avec leurs clients ou leurs employés et de communiquer efficacement sur les problèmes
tout au long de la chaîne de gestion des données.

Les principales caractéristiques de Bugzilla sont les suivantes

 Capacités de recherche avancées

 Notifications par courrier électronique
 Modifier/déposer des bogues par courrier électronique
 Suivi du temps
 Sécurité renforcée
 Personnalisation

Comment se connecter à Bugzilla ?

Étape 1) Pour créer un compte dans Bugzilla ou pour se connecter à un compte existant,
cliquez sur l'optionNouveau compte ou Connexion dans le menu principal.

Étape 2) Entrez maintenant vos données personnelles pour vous connecter à Bugzilla.

1. Identifiant de l'utilisateur : jan30selenium@gmail.com

2. Mot de passe : selenium
3. Cliquez ensuite sur"Se connecter"
Étape 3) Vous êtes connecté avec succès au système Bugzilla

Créer un rapport de bug dans Bugzilla

Étape 1) Pour créer un nouveau bogue dans Bugzilla, visitez la page d'accueil de
Bugzilla et cliquez sur l'ongletNOUVEAUdans le menu principal.
Cliquez sur le lien Nouveau puis l'application ouvre la fenêtre suivante comme ci-dessous.

Étape 2) Dans la fenêtre suivante

Cliquez sur le nom du projet comme HMS et l'application ouvre une nouvelle fenêtre avec
les options suivantes

1. Saisir le produit
2. Saisir le composant
3. Description du composant
4. Sélectionnez la version,
5. Sélectionner la gravité
6. Sélectionner le matériel
7. Sélectionner le système d'exploitation
8. Saisir le résumé
9. Saisir la description
10. Pièce jointe Pièce jointe
11. Soumettre

NOTE : Les champs ci-dessus varieront en fonction de votre personnalisation de

Bugzilla.

Saisissez tous les champs nécessaires concernant votre bogue comme indiqué ci-dessous,
Si vous avez des pièces jointes à votre rapport de bogue, vous pouvez les joindre en cliquant sur le bouton
"Ajouter une pièce jointe" et cliquez sur le bouton "Engager" à la fin de la page pour signaler votre bogue.

Étape 4) Création d'un bogue Le numéro d'identification 208 est attribué à notre bogue. Vous pouvez
également ajouter des informations supplémentaires au bogue attribué, telles que l'URL, les mots-clés, le
tableau blanc, les balises, etc. Ces informations supplémentaires sont utiles pour donner plus de détails sur
l'insecte que vous avez créé.

1. Grande zone de texte

2. URL
3. Tableau blanc
4. Mots clés
5. Tags
6. Dépend de
7. Blocs
8. Pièces jointes
Étape 5) Dans la même fenêtre, si vous descendez plus bas. Vous pouvez sélectionner la date limite et le statut
du bogue. La date limite dans Bugzilla indique généralement le délai dans lequel le bogue doit être
résolu.
Créer des rapports graphiques

Les rapports graphiques sont un moyen de visualiser l'état actuel de la base de données des bogues. Vous
pouvez exécuter des rapports sous la forme d'un tableau HTML ou d'un graphique à base de lignes, de pics ou
de barres. L'idée du rapport graphique dans Bugzilla est de définir un ensemble de bogues en utilisant
l'interface de recherche standard, puis de choisir un aspect de cet ensemble à représenter sur les axes
horizontaux et verticaux. Vous pouvez également obtenir un rapport tridimensionnel en choisissant l'option
"Pages multiples".

Les rapports sont utiles à bien des égards, par exemple si vous voulez savoir quel composant a fait l'objet du
plus grand nombre de rapports de bogues. Pour représenter cela dans le graphique, vous pouvez sélectionner la
gravité sur l'axe X et le composant sur l'axe Y, puis cliquer sur générer un rapport. Il génère un rapport
contenant des informations cruciales.

1. Cliquez sur rapports en haut de la fenêtre comme suit

2. Cliquez sur Rapports graphiques

La page des rapports graphiques s'affiche comme suit,

Sélectionnez l'axe vertical comme Gravité et l'axe horizontal comme Priorité ou tout autre axe que vous
souhaitez sélectionner et vous obtiendrez le rapport graphique correspondant.

 Générer un rapport avec des fonctionnalités avancées en entrant plus de détails sur le bogue comme ci-
dessous
Dansle graphique ci-dessous, les bogues ou bloqueurs les plus graves dans les composants sont au nombre de
88, tandis que les bogues de gravité normale sont au sommet avec un nombre de 667.

Parcourir la fonction

Étape 1) Pour localiser votre bogue, nous utilisons la fonction de recherche, cliquez sur le boutonRechercher
dans le menu principal.
Les rapports se poursuivront jusqu'à ce que la version soit stable. Une fois qu'il est stable, il
est livré au client, puis la phase de livraison et de maintenance du Refer est lancée.

Une fois que la version est livrée avec succès au client, le responsable des tests
prépare un rapport de synthèse des tests, qui est mis à jour dans le plan de test et envoyé au
client au moment de la livraison de la version.

RAPPORT DE SYNTHÈSE DES TESTS / RAPPORT DE CONSTRUCTION POST-MARTUM

 Nombre de versions publiées par l'équipe de développement - 50

 Nombre de constructions acceptées par l'équipe de test - 25
 Nombre de constructions rejetées par l'équipe de test - 25
 Nombre de cas de test préparés par l'équipe de test - 1000
 P1 - 500, P2- 350, P3-100, P4-50

 Nombre de bogues identifiés - 400

o Bloqueur - 100
o Très élevé - 150
o Élevé - 100
o Moyen - 40
o Faible - 10
 Nombre de bogues identifiés par le client - 100
o Bloqueur - 10
o Très élevé - 50
o Haut - 10
o Moyen - 10
o Faible - 20
 Histoires de réussite
 Défis

Q : Quels sont les critères d'entrée (début) et de sortie (fin) des tests ?

R : Le plan de test et le document SRS sont les critères d'entrée des tests.

Les tests n'ont pas de fin. Elle se poursuivra tant que la construction sera en cours. Mais les
activités de test changeront après la livraison de la version au client. Pendant la maintenance,
nous n'allons pas effectuer tous les types de tests fonctionnels. Nous effectuerons les tests de
régression.

Terminologie
Le terme "pair" désigne le coéquipier ayant la même
désignation. Tous les pairs participeront à une
réunion et discuteront du projet afin de clarifier tous
les modules. L'objectif de l'examen par les pairs est
d'obtenir une connaissance fonctionnelle de tous les
Examen par les pairs modules par chaque ingénieur de test.
Lors de l'examen par les pairs, le pair principal
prépare le document sur l'examen par les pairs,
Rapport d'examen par les connu sous le nom de rapport d'examen par les
pairs pairs.
Si le même examen par les pairs est effectué
devant le responsable ou le chef de projet, il s'agit
alors d'un examen approfondi. Le responsable ou le
gestionnaire de projet observe si les membres de
Passer en revue l'équipe comprennent bien le projet ou non.
Lors de la visite à pied, le responsable préparera le
document sur la visite à pied, connu sous le nom de
Rapport de visite rapport de visite à pied.
La combinaison de plusieurs cas de test est connue
Suite de tests sous le nom de suite de tests.
La combinaison de la suite de tests et de
l'environnement de test est connue sous le nom de
Banc d'essai banc d'essai.
Rapport quotidien sur l'état de la situation.
Chaque jour, nous devons envoyer l'état
d'avancement de notre travail au responsable dans
DSR un modèle.
Procès-verbal de la réunion.
Lorsque nous participons à une réunion, la
discussion qui s'y déroule est consignée sous forme
de note brute. Plus tard, il sera mis à jour dans un
courrier qui sera envoyé à tous les membres de
l'équipe. L'objectif du MOM est de maintenir la
transparence de la réunion entre les membres de
MOM l'équipe.
Le processus consistant à vérifier si l'entreprise suit
ou non les lignes directrices. L'inspection sera
L'inspection effectuée sans préavis.
Il s'agit également de vérifier si l'entreprise respecte
ou non les lignes directrices. L'audit sera effectué
Audit avec notification préalable
Stable signifie qu'aucune mise à jour n'est
nécessaire.
Une version stable signifie que la majorité des cas
de test sont réussis et qu'aucun bogue bloquant n'a
Stable été identifié dans la version.
AUT Application en cours de test
 Lorsque la construction est rejetée, le développeur
analyse l'échec. S'il remet la même version à
l'équipe de test sans ajouter de nouvelles
fonctionnalités, on parle de PatchBuild.
Si le développeur publie une version avec de
nouvelles fonctionnalités, il s'agit d'une nouvelle
Création d'un correctif version.
Le mettre à la disposition des utilisateurs ciblés.
Une fois que les cas d'essai ou le document SRS
ont été rédigés, ils seront archivés dans le dépôt
central pour les utilisateurs ciblés. Il est connu sous
Publier le nom de "publication".
Les défauts liés à la conception sont connus sous le
nom de défauts. Ex : défauts de l'interface
graphique
Les défauts fonctionnels sont des bogues (erreur du
programmeur).
Ex : Tous les bogues fonctionnels
Erreur : Les exceptions dans le script sont connues
Bogue/défaut/erreur sous le nom d'erreur.
Un cas d'utilisation est une liste d'étapes,
définissant généralement les interactions entre un
rôle (appelé "acteur") et un système, afin d'atteindre
un objectif. L'acteur peut être un ingénieur de test
ou un utilisateur final
Les exigences seront converties en liste d'étapes
Cas d'utilisation par le BA.
Rapports de non-conformité ou demande de
modification de non-conformité. L'exigence qui fait
NCR l'objet de la discussion
Des actions correctives sont mises en œuvre en
réponse aux réclamations des clients
Des actions préventives sont mises en œuvre en
CAPA réponse à l'identification de sources potentielles
Dans le domaine du génie logiciel, la gestion de la
configuration des logiciels (SCM ou SWCM)
consiste à suivre et à contrôler les modifications
apportées aux logiciels. Les pratiques de GCA
comprennent le contrôle des révisions et
SCM l'établissement de lignes de base.
SDN Note sur la livraison de logiciels
Subsides. S'éloigner de la tâche
Nombre de jours pendant lesquels vous vous êtes
Glissement éloigné de la tâche
Produit défectueux Le produit présente des défauts
L'âge du défaut (en temps) est la différence de
temps entre la date de signalement d'un défaut et la
date actuelle (si le défaut est encore ouvert) ou la
date à laquelle le défaut a été corrigé (si le défaut
Âge du défaut est déjà corrigé).
Défaut latent Défaut caché
La gestion du portefeuille de produits est la gestion
centralisée des processus, des méthodes et des
PPM technologies utilisés par les chefs de projet.
 Rapports d'examen des performances des
PPR programmes
MRM Gestion des ressources marketing