1. Cahier de recette(CDR)
1.1. Ref : 7. [Processus StarDust] Processus de création des référentiels de tests 1.0.1
1.2. cas de test complet/optimisé
1.3. cas de test
1.3.1. design technique
1.3.2. description principle
1.3.2.1. precise
1.3.2.2. objective
1.3.3. elements
1.3.3.1. description
1.3.3.2. comportement attendu
2. manual test execution
2.1. the build is ready
2.2. QA environment is ready
2.3. checklist
2.3.1. The QA Software Testing Checklists (Sample Checklists Included) — Software Testing Help
2.4. smoke and sanity test
2.4.1. Smoke testing and sanity testing - Quick and simple differences — Software Testing Help
2.5. execution
2.6. maintenance of test cas or script
2.6.1. ajustment
2.7. bug report and tracking
2.8. test report
2.8.1. defect
2.8.2. metric
2.8.3. How to Report Test Execution Smartly – [Download Status Report Template] — Software Testing Help
2.9. other elementa
2.9.1. team size
2.9.2. cycle
3. Plan de test
3.1. Ref1 : 7. [Processus StarDust] Processus de création des référentiels de tests 1.0.1
3.2. ref2: How to Write a Test Plan Document from Scratch (A Real Test Plan for Download) - Software Testing Training on a Live Project Day 3 — Software Testing Help
3.3. ref3: 7-Step Practical Implementation of Manual Testing Before Production Release — Software Testing Help
3.4. scope/périmètre
3.4.1. requirement
3.4.2. backward compatibility
3.4.2.1. the existing functions related to this change which need to be tested
3.4.3. platform
3.4.4. test métier
3.4.5. test non-métier
3.4.6. device/terminaux
3.5. testers
3.5.1. who is to do what
3.6. test effort estimation/estimation de charge/schedule
3.6.1. Software Test Estimation Techniques (Test Effort Estimation Complete Guide) — Software Testing Help
3.7. entry criteria
3.7.1. when to start testing
3.8. exit criteria
3.8.1. when to stop
3.8.1.1. no critical, major defect
3.8.1.2. too many defects in mid-way
3.9. limitiation
3.10. deliverables/livrables
3.10.1. what document are going to produce at what time frame
3.11. tool
3.11.1. what tools are going to be used for manage test case, defect etc, ex: jira
3.12. cas particulier
3.12.1. multi-langues
3.12.1.1. un terminal pour chaque langue
3.12.2. multi-design
3.12.2.1. un terminal pour chaque langue
3.12.3. multi-OS/support
4. Production&Testing activity
4.1. system developement life cycle(SDLC)
4.1.1. Requirement gathering
4.1.1.1. tool to document
4.1.1.1.1. MS word
4.1.1.1.2. Jira
4.1.1.1.3. Trello
4.1.1.2. role
4.1.1.2.1. business analyst
4.1.1.2.2. product manager
4.1.2. requirement discussion
4.1.2.1. all questions are answered, all
4.1.2.2. roles
4.1.2.2.1. PM, UX, Dev, Tester
4.1.2.3. output
4.1.2.3.1. systeme/product specification document/user story
4.1.3. designing
4.1.3.1. Dev: decide development approche
4.1.3.2. UI: prototype
4.1.3.3. test: test plan
4.1.4. development phase
4.1.4.1. development
4.1.4.2. code review
4.1.4.3. unit test
4.1.5. test phase
4.1.5.1. several round
4.1.5.1.1. small feature part
4.1.5.1.2. end to end test
4.1.5.1.3. sanity/smoke round
4.1.5.2. veiller aux correction
4.1.6. business analyst review
4.1.7. shipment/release
4.2. system test life cycle(STLC)
4.2.1. test plan
4.2.1.1. role: test leader
4.2.1.2. output: test plan document
4.2.1.3. phase: product design
4.2.2. design
4.2.2.1. role: analyste de test
4.2.2.2. output: test case, script in case of automation
4.2.2.3. phase: product design
4.2.3. execute
4.2.3.1. role: testeur
4.2.3.2. output: test report
4.2.3.3. phase: test
5. Rôles au sein de l'équipe de QA chez StarDust
5.1. Responsable de production
5.1.1. le management de l’équipe de production
5.1.2. l’ensemble des projets
5.1.3. la validation des congés
5.1.3.1. le prévenir en cas d'absence
5.2. Chef de produit (CDP)
5.2.1. interface entre production et client
5.2.2. analyse le risque des projets, valider sa faisabilité
5.2.3. Planifier les opérations
5.3. Test leader
5.3.1. Référent entre l'équipe de test et CDP
5.3.1.1. remonter les problèmes et les risques au CDP
5.3.1.2. répondre aux questions des testeurs
5.3.2. S'assurer la qualité des résultats, le respect des instruction
5.3.2.1. harmoniser les résultats
5.4. Analyste de test
5.4.1. Tâches et missions
5.4.1.1. élaborer le cahier de recette, les matrices de scénarios et les matrices fonctionnelles
5.4.1.2. estimer le charge et le temps de la rédaction
5.4.1.3. rendre compte au CDP de toutes les opérations et événement liés à la recette
5.4.2. Entrants
5.4.2.1. le mail d'instruction
5.4.2.2. story-board
5.4.2.2.1. l'enchaînement des pages/navigation
5.4.2.2.2. un aperçu graphique
5.4.2.3. spécifications fonctionnelles
5.4.2.3.1. faire le tri entre les informations pertinentes
5.4.2.4. backlog
5.4.2.4.1. agile
5.4.2.5. fichier de wording
5.4.2.6. application pre-test
5.4.2.7. faire le listing des éléments fournis, notifier le CDP en l'absence des documents manquants
5.4.3. Livrables
5.4.3.1. les matrices de scénarios
5.4.3.2. les matrices fonctionnelles
5.4.3.3. le cahier de recette
5.4.3.4. plan de test
5.4.4. Ref: 2. [Processus StarDust] Rôles et tâches de l'Analyste de Test 1.1.0
5.5. Testeur
5.5.1. Détecter/identifier les anomalies
5.5.2. Remonter les anomalies
5.5.3. Veiller aux corrections
5.6. Ref: 1. [Processus StarDust] Organisation et rôles dans l'équipe de production v1.3.1 (1)
6. Outil
6.1. mind mapping
6.1.1. Ref: 12. [Processus StarDust] Mind Mapping - EN COURS - Création des scénarios de test 1.0.0
6.1.2. mind mapping des fonctionnalité
6.1.3. mind mapping des scénarios
6.1.3.1. page bouchon
6.1.3.1.1. le point de convergence
6.1.3.1.2. ne contient pas de fonctionnalité
6.1.3.2. page noeud
6.1.3.2.1. le point de divergence
6.1.3.2.2. contient tous types de contenues
6.2. QC
6.3. Jira
7. automation test
7.1. why automation
7.1.1. execution of repeated case saves time and money -> high ROI
7.2. framework
7.2.1. definition
7.2.1.1. guidelines, coding standards, concepts, processes, practices, project hierarchies, modularity, reporting mechanism, test data injections etc. , coding standard,
7.2.2. advantage
7.2.2.1. the ease of scripting, scalability, modularity, understandability, process definition, re-usability, cost, maintenance etc.
7.2.3. application scenario
7.2.3.1. team work
7.2.4. type
7.2.4.1. module based testing frameworking
7.2.4.1.1. separate an application into modules
7.2.4.2. Library Architecture Testing Framework
7.2.4.2.1. separate an application into modules by function
7.2.4.3. Data Driven Testing Framework
7.2.4.3.1. store test data and expected output in external database
7.2.4.4. Keyword Driven Testing Framework
7.2.4.4.1. extract the action as keyword and store it in external databases
7.2.4.5. Hybrid Testing Framework
7.2.4.5.1. hybrid of several frameworks mentioned above
7.2.4.6. Behavior Driven Development Framework
7.2.4.6.1. cucumber
7.2.5. ref: Most Popular Test Automation Frameworks with Pros and Cons of Each – Selenium Tutorial #20 — Software Testing Help
7.3. java
7.3.1. basic syntax
7.3.1.1. case sensitive
7.3.1.2. public static void main(String args[])
7.3.1.2.1. starts from main method
7.3.2. identifier
7.3.2.1. name of class, method and variable
7.3.2.2. start with letter or $ or _
7.3.2.3. data type
7.3.2.3.1. primitive data type
7.3.2.3.2. reference/object data type
7.3.2.3.3. literal
7.3.3. modifier
7.3.3.1. include the keyword in the definition of variable, method, class, precede the rest of the statement
7.3.3.2. access modifier
7.3.3.2.1. public
7.3.3.2.2. protected
7.3.3.2.3. default
7.3.3.2.4. private
7.3.3.3. non-access modifier
7.3.3.3.1. static
7.3.3.3.2. final
7.3.3.3.3. abstract
7.3.3.3.4. synchronized/volatile
7.3.4. operators
7.3.5. enums
7.3.5.1. restrict a variable to have one of only a few predefined values.
7.3.6. object oriented
7.3.6.1. class
7.3.6.1.1. first letter of class name is upper case
7.3.6.1.2. file name = class name
7.3.6.1.3. template/blueprint of object
7.3.6.1.4. package
7.3.6.1.5. import
7.3.6.2. object
7.3.6.2.1. instance of class
7.3.6.2.2. creating
7.3.6.3. inheritance
7.3.6.3.1. subclass derive from superclass
7.3.6.4. interface
7.4. web
7.4.1. selenium
7.4.1.1. advantage
7.4.1.1.1. web-based
7.4.1.1.2. multiple OS
7.4.1.1.3. multiple browsers
7.4.1.1.4. multiple programming language
7.4.1.1.5. multiple framework
7.4.1.1.6. open source
7.4.1.2. components
7.4.1.2.1. core
7.4.1.2.2. IDE
7.4.1.2.3. remote control
7.4.1.2.4. WebDriver
7.4.1.2.5. Grid
7.4.1.3. framework
7.4.1.3.1. TestNG
8. Bug management
8.1. terms
8.1.1. en: defect/bug/issue/incident/error/fault
8.1.2. fr: anomalie/bug/défaut/erreur/bogue
8.2. types
8.2.1. functionnal
8.2.1.1. missing requirement
8.2.1.2. incorrectly working requirement/inconsistence
8.2.2. graphique
8.2.3. wording
8.3. metric
8.3.1. Pass Percentage of the Test cases
8.3.2. Critical defects percentage