Beruflich Dokumente
Kultur Dokumente
Test Manuel Durgasoft
Test Manuel Durgasoft
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.
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é
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
Test de charge
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.
L'histoire
Proposition Signer la fin
Estimations
Temps et coût
Réunion de
C1 C2 C3
lancement
2 ans 1,5 an 1 an
Hiérarchie des projets ou hiérarchie des désignations ou hiérarchie des rôles
LE CYCLE DE VIE DU
DÉVELOPPEMENT LOGICIEL (SDLC) :
Il se compose des phases suivantes,
1) Phase de demande :
Rôles:Analyste commercial
Responsable de l'engagement
Chef de projet
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.
MaintenancePhase TAT
Correction des
Client
Délai d'exécution bogues, CR
BA/PM/TL
3 Bugs
(Amélioration)
3 CR Entreprise
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.
1) Applications Web
2) Applications de bureau
3) Applications mobiles
Environnement/système:
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.
La couche base de données est chargée de stocker les données sous forme de
tableaux.
Ex: MS SQL, My SQL, ORACLE
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
DB DB DB
DBL
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:
Pour une application Web, nous devons la tester uniquement sur le client.
(BL)
Serveur + DBL
Applica
tion
M1 M2 M3
PL
a. Applications natives
b. Applications Web
c. Applications hybrides
a. Applications natives :
b. Applications Web:
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.
Q :Qui est responsable des tests ? À quel niveau l'ingénieur de test sera-t-il impliqué dans les
tests ?
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".
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.
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.
a.Tests alpha
b. Bêta-test UAT
Alpha testing Beta testing (UATCS)
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".
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 ?
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.
Avantages :
Il est très facile de mettre en œuvre le projet car il s'agit d'une exécution
séquentielle.
Inconvénients :
mois
2) Modèle Spiral :
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.
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.
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 :
4) Modèle de poisson :
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.
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.
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)
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.
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".
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.
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".
En effectuant des tests de bout en bout, nous pouvons réaliser des tests au niveau de
l'intégration.
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.
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é :
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é.
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é").
Tester l'application sans effectuer aucune action est connu sous le nom de test
statique.
Tester l'application en effectuant une action est connu sous le nom de test
dynamique.
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.
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.
Description
7. Lâcher d'adultes, d'enfants et de nourrissons 1. Quelle est la différence entre
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 :
2. Documents de référence
3. Éléments du test
4. Stratégie d'essai
5. Environnement de test
9. Tests d'automatisation
1. L'objectif :
L'objectif principal du plan de test sera décrit ici. Il contient l'étendue des tests.
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 :
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.
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.
6. Test réussi/échec/critères :
a. Bloqueur
b. Très élevé
c. Haut
d. Moyen
e. Faible
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
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.
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
Absence d'évaluation par les pairs Suivi Examens par les pairs
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.
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 :
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.
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.
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é.
3. Deviner l'erreur
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.
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.
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.
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.
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.
6) Rapport :
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 :
Titre du bug/résumé :
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 :
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
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
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 ?
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
Haut - P3
Moyen - P4
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.
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é.
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
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 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.
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.
BugZilla :
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.
Étape 2) Entrez maintenant vos données personnelles pour vous connecter à Bugzilla.
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
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éé.
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.
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.
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