1 / 39

USER ACCEPTANCE TESTING

USER ACCEPTANCE TESTING. 16-09-2013. WHAT IS UAT. User Acceptance Test aims to ensure that the new development meets the business requirements with acceptable for the end users quality. TYPES OF UAT. New development validation

merv
Download Presentation

USER ACCEPTANCE TESTING

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. USER ACCEPTANCE TESTING 16-09-2013

  2. WHAT IS UAT User Acceptance Test aims to ensure that the new development meets the business requirements with acceptable for the end users quality.

  3. TYPES OF UAT New development validation This type of UAT aims to validate that the new development meets the business requirements and works as expected Non-regression test The non-regression test aims to verify that after the implementation of the new development, the existing software functionalities have not been compromised. Regression test Regression test is any type of software testing that seeks to uncover new software bugs in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.

  4. UAT ORGANIZATION – ROLES AND RESPONSIBILITIES PROJECT MANAGER   UAT COORDINATOR  IT PROJECT MANAGER UAT TEAM MEMBER

  5. UAT ON 1 PAGE IC1 IC2 IC3 Mandate is Decided. Preparation is authorized Scoping Contract is validated. Project authorized Start of Construction Phase Start of Users Acceptance Tests Result assessment is validated. Closure authorized Go Live PROCESSES ACTIVITIES PREPARATION PHASE ELABORATION PHASE CONSTRUCTION PHASE TRANSITION PHASE POST PROJECT 6 7 A B 8 9 10 11 12 13 C 15 D 16 17 18 19 20 1. Analyze general BRD 2. Estimate the UAT duration/cost 3. Create UAT preparation plan 4. Outline UAT execution plan 5. Write UAT quotation document 6. Outline UAT strategy UAT quotation Preliminary Analysis UAT preparation plan 10% test book • 1. Analyze detailed BRD/FSD • 2. Create test book • 3. Give feedback for the test book • 4. Create UAT execution plan • 5. Present plan to the stakeholders • 6. Create UAT strategy • 7. Validate UAT strategy • 8. Send UAT strategy 45% UAT execution plan UATPreparation UAT Strategy defects register 5% defects report 1. Announce UAT kick-off 2. Authorize UAT work packages 3. Execute work package 4. Deliver work packages 5. Log test results 6. Report progress 7. Defects/Issues management 8. Announce sign-off progress report 40% UATExecution test book updated UAT kick-off UAT sign-off Planning the UAT pre-analysis Calculating the UAT cost Planning the UAT preparation Planning the UAT execution UAT Planning UAT Preparation Start Date Starting date of UAT preliminary -analysis UAT Execution Start Date Update UAT Preparation End Date UAT Quotation delivery date UAT Execution Duration Estimate UAT Execution End Date Update Preparation kick-off Project kick-off UAT kick-off Validation of the general BRD (v.1) Validation of the FSD Start of QA (Internal IT) tests End of UAT

  6. DEFECTS MANAGEMENT PROCESS Milestones Defect is sent Defect Is detected Defect is validated Defect is rejected/ accepted Defect is fixed Defect is delivered Defect is retested Defect is closed Time Frame UAT EXECUTION Execute test cases Activities: 1. Write a defect report 2. Validate defect 3. Register defect 4. Send defect to IT PM 5. Accept/Reject defect 6. Fix defect 7. Deliver the fixed defect 8. Retest defect 9. Close defect 10. Update defect register Write defect report Validate the defect Register defect Send defect Issue management Reject defect Accept defect Fix defect • Deliver the fixed defect Retest the defect • Close the defect Update defect register • IT project manager • Receive defect • Accept/Reject defect • Deliver defect for retest • UAT coordinator • Validate defect • Send defect to IT • Issue management • Close defect • Update defect register • UAT team member • Execute test cases • Report defect to UAT coordinator • Retest defect • Inputs • Test book/log • Defect register template • Defect report template • Outputs • Defect report • Defect register Templates Defect report Defect register

  7. UAT ISSUES MANAGEMENT PROCESS Milestones UAT Issue Is detected/ Defect is rejected UAT issue is validated UAT issue report is sent UAT issue is rejected/accepted UAT issue is solved UAT issue is delivered UAT issue is validated UAT issue is closed Time Frame UAT EXECUTION Execute test cases Activities: 1. Write UAT issue report 2. Validate the UAT issue 3. Register UAT issue 4. Send UAT issue to PM 5. Accept/Reject UAT issue 6. Solve the UAT issue 7. Deliver UAT issue for validation 8. Validate the UAT issue solving 9. Close the UAT issue 10. Update UAT issue register Write UAT issue report Validate the UAT issue Register UAT issue Send UAT issue Reject UAT issue Accept UAT issue Solve the UAT issue • Deliver the UAT issue Validate the UAT issue solving • Close the UAT issue Update UAT issue register • UAT team member • Write UAT issue report • Send UAT issue report to UAT coordinator • Validate the UAT issue solving • UAT coordinator • Receive UAT issue report • Validate UAT issue • Register issue in UAT issue register • Send issue to project manager • Inform for UAT issue solving • Close the UAT issue • Update UAT issue register • Project manager • Receive UAT issue from UAT coordinator • Accept/Reject the UAT issue • Solve the UAT issue • Deliver the UAT issue for validation • Inputs • Test book/log • UAT issue register • Outputs • UAT issue report • UAT issue register updated Templates UAT issue register UAT issue report

  8. HOW TO CREATE TEST BOOK STEP BY STEP

  9. STEP 1: ANALYZE BUSINESS REQUIREMENTS (1/2) Direct Telesales Consultant shall be able to create and submit application using Jetix Application Form. The purpose is to fill in data and submit eligible application to enable granting decision. Application shall not be eligible for submitting if the mandatory fields (1, 2, 3) are not filled in. ACTIONS: • Identify concerned processes • Identify concerned JetIX positions • Identify concerned system modules • Identify changes • Identify concerned products

  10. STEP 1: ANALYZE BUSINESS REQUIREMENTS (2/2) • Concerned JetIX positions: • Direct Telesales Consultant • Concerned processes: • Create application • Submit application • Concerned system modules: • Application Form module (Backend) • Business Requirement: • BR.1.2. - Direct Telesales Consultant shall be able to create and submit application using Jetix Application Form. The purpose is to fill in data and submit eligible application to enable granting decision. Application shall not be eligible for submitting if the mandatory fields (1, 2, 3) are not filled in. • Business requirement ID: • It is used for test scenarios and cases naming (Requirement ID BR.1.2 and scenario ID S1, S2…) • Changes: • New controls • Concerned products: • Credit Classic • Credit Plan • Employer Loan Secured/Non Secured

  11. STEP 2: DESCRIBE THE TEST SCENARIOS (1/2) ACTIONS: • Identify all situations, coming from the real business processes, concerned in the business requirements and group them by a common criteria: • Concerned process • Concerned changes

  12. STEP 2: DESCRIBE THE TEST SCENARIOS (2/2) • Scenarios by concerned process: • Test the possibility to create application in Application Form module • Test the possibility to submit application in Application Form module • Concerned JetIX positions: • Direct Telesales Consultant • Concerned processes: • Create application • Submit application • Concerned system modules: • Application Form module (Backend) • Business requirement: • BR.1.2. - Direct Telesales Consultant shall be able to create and submit application using Jetix Application Form. The purpose is to fill in data and submit eligible application to enable granting decision. Application shall not be eligible for submitting if the mandatory fields (1, 2, 3) are not filled in. • Business requirement ID: • It is used for test scenarios and cases naming (Requirement ID BR.1.2 and scenario ID S1, S2…) • Changes: • New controls • Concerned products: • Credit Classic • Credit Plan • Employer Loan Secured/Non Secured • Scenarios by concerned changes: • Test the possibility to submit eligible application in Application Form module • Test the possibility to submit non-eligible application in Application Form module

  13. STEP 3: DESCRIBE THE PURPOSE OF THE TEST CASE (1/2) ACTIONS: • Identify all specific and unique situations, based on the scenarios and all other criteria: • Create all possible variations and combinations between the concerned processes, products, changes, JetIX positions, based on the criteria from the scenario

  14. STEP 3: DESCRIBE THE PURPOSE OF THE TEST CASE (2/2) • Test the possibility of Direct Telesales Consultant to submit a JetCredit Plus application, with filled fields 1,2,3 • Test the possibility of Direct Telesales Consultant to submit a Credit Plan application, with filled fields 1,2,3 • Test the possibility of Direct Telesales Consultant to submit a EMPL application, with filled fields 1,2,3 • Test the possibility of Direct Telesales Consultant to submit a EMLN application, with filled fields 1,2,3 • Test the possibility of Direct Telesales Consultant to create a JetCredit Plus application • Test the possibility of Direct Telesales Consultant to create a Credit Plan application • Test the possibility of Direct Telesales Consultant to create a Employer Loan Secured application • Test the possibility of Direct Telesales Consultant to create a Employer Loan Non-Secured application • Test the possibility to create application in Application Form module • Test the possibility to submit application in Application Form module

  15. STEP 4: DEFINE THE PREREQUISITES What are prerequisites: The prerequisites are the conditions which are necessary to be done before test case execution in order to be sure that there is no reason expected result to be not met. There are the inputs for the test case execution. • Tips for prerequisites definition: • After defining the test case purpose, the prerequisites should be defined. The following questions that may be useful are: • Is a user account needed? If, yes – for what position? • Is customer’s EGN needed? If yes – for what type of client: new/repeat, with/without history, with/without delay, with active/inactive credits, etc.? • Is a specific credit needed? If yes – from which product? In what status? DPD = ? without/with financed or monthly insurance, with/without payments?, etc. • Is some event needed to happen? • Is time simulation needed? Example:

  16. STEP 5: DEFINE TEST STEPS Definition: Test steps are a detailed sequence what have to be done in order to achieve the expected result of a certain test case. Steps need to be precise, non ambiguous and easy to follow. • Tips for test steps definition: • When writing test steps it is necessary to specify the sequence of each action. The points that should be specified are: • The system where the user should log in • The position which the user should be logged-in with • The access path which the user should follow • The functionalities (buttons, links, etc.) names which the user should select Example:

  17. STEP 6: DEFINE TEST DATA SET • Definition: • Test data is the data which has been specifically identified and will be used in test case execution. Note that test data set is not necessary for all test cases. • Tips for test data set definition: • Once the test cases are written, test data characteristics for each test case should be defined according to the UAT principles: • Assign one and the same test data for more than one test case when it is possible • Prioritize the execution order of those test cases where one and the same test data is assigned • Make a file where the test data can be easily tracked • Prepare test data set before launching the UAT • Before start executing the test steps, check if test data distributed to the test case are actually eligible for it Example: PMO@bnpparibas-pf.bg

  18. TRACEABILITY RULES Definition Traceability aims to facilitate the management of the requirements, scenarios and test cases during UAT Requirement ID is defined in BRD or FSD and the scenario ID is based on it. Once the scenario ID is defined, it is input for test case ID defining. Formula: REQUIREMENT ID + LETTER “S” + NUMBER OF THE SCENARIO = SCENARIO ID where “S” means Scenario SCENARIO ID + LETTERS “TC” + NUMBER OF TEST CASES = TEST CASE ID where “TC” means Test case Example: BRD : BR.1.2. Direct Telesales Consultant shall be able to create and submit application using Jetix Application Form. The purpose is to fill in data and submit eligible application to enable granting decision. Application shall not be eligible for submitting if the mandatory fields (1, 2, 3) are not filled in. • Scenario: Test the possibility to create application in Application Form module • Test case purpose: Test the possibility of Direct Telesales Consultant to create a JetCredit Plus application Scenario ID = BR.1.2. + S + 1 = BR.1.2.S1 Test case ID = BR.1.2.S1 + TC + 1 = BR.1.2.S1TC1

  19. STEP 7: DESIGN TEST CASES Scenario description: Describe shortly the scenario, generated in Step-3 Test case purpose: Describe the specific business situation, purpose of the test case, defined in Step-4. Test steps: What exactly shall be done by whom, where and in what sequence in order to meet the expected result Scenario ID: It should be simple and easy for tracking. For each business requirement it should exists at least one test scenario. Test case ID: This is the unique number of each test case, formed from the business requirement number and scenario ID. Prerequisites: What is necessary and has to be done before test case execution. It could be a user account, specific credit, etc… Expected result: What is the expected result by user point of view in order to accept the test case result

  20. FROM BUSINESS REQUIREMENT TO TEST CASES Practical exercise PMO@bnpparibas-pf.bg

  21. ANALYZE BUSINESS REQUIREMENT Business Requirement 1. Автоматично попълващи се полета при задаване на определени критерии При попълване на полето ЕГН в SharePoint от попълващия заявката автоматично да се попълват полетата: • Име на отчетното лице – стойността на полето Име на отчетното лице ще е равна на стойността на поле „Име” от ТРЗ сорса.Форматът е текстови и съдържанието не може да бъде коригирано нито от попълващия, нито от одобряващите заявката; • Позиция – полето е текстово и стойността му е равна стойността в полето „На длъжност” от ТРЗ сорса. Полето се попълва автоматично и съдържанието не може да бъде коригирано нито от попълващия, нито от одобряващите заявката; • Отдел – полето е текстово и стойността му е равна на стойността в полето „Отдел” от ТРЗ сорса. Полето се попълва автоматично и съдържанието не може да бъде коригирано нито от попълващия, нито от одобряващите заявката; • Офис – полето е текстово и стойността му е равна на стойността в полето „Офис/Магазин” от ТРЗ сорса. Полето се попълва автоматично и съдържанието не може да бъде коригирано нито от попълващия, нито от одобряващите заявката. • Стойностите на изброените по-горе полета ще се извличат от сорс, който ще съдържа информация за отчетното лице съгласно ТРЗбазата и съответните на конкретно ЕГН стойности. Legend: Requirement ID Functionalities Fields Positions Systems Controls PMO@bnpparibas-pf.bg

  22. DESCRIBE THE TEST SCENARIOS • Scenarios by fields: • BR.1S1 Validate the properties of field “Име на отчетното лице“ • BR.1S2 Validate the properties of field “Позиция“ • BR.1S3 Validate the properties of field “Отдел“ • BR.1S4 Validate the properties of field “Офис“ • Scenarios by field properties: • BR.1S1 Validate the automatic filling of the fields “Име на отчетното лице“, “Позиция“, “Отдел“, “Офис“ • BR.1S2 Validate the content of the fields “Име на отчетното лице“, “Позиция“, “Отдел“, “Офис“ • BR.1S3 Validate the controls of the fields “Име на отчетното лице“, “Позиция“, “Отдел“, “Офис“ • BR.1S4 Validate the format of the fields “Име на отчетното лице“, “Позиция“, “Отдел“, “Офис“ PMO@bnpparibas-pf.bg

  23. DESCRIBE THE PURPOSE OF THE TEST CASES • BR.1S1 Validate the properties of field “Име на отчетното лице“ • BR.1S1TC1 Validate the automatic filling of field “Име на отчетното лице“ upon filling correct EGN in SharePoint – Expense report • BR.1S1TC2 Validate the content of prefilled field “Име на отчетното лице“ in SharePoint – Expense report • BR.1S1TC3 Validate the format of prefilled field “Име на отчетното лице“ in SharePoint – Expense report • BR.1S1TC4 Validate the impossibility to modify the prefilled data in field “Име на отчетното лице“ in SharePoint – Expense report • BR.1S1 Validate the automatic filling of the fields “Име на отчетното лице“, “Позиция“, “Отдел“, “Офис“ • BR.1S1TC1Validate the automatic filling of field “Име на отчетното лице“upon filling correct EGN in SharePoint – Expense report • BR.1S1TC2 Validate the automatic filling of field “Позиция“upon filling correct EGN in SharePoint – Expense report • BR.1S1TC3Validate the automatic filling of field “Отдел“upon filling correct EGN in SharePoint – Expense report • BR.1S1TC4 Validate the automatic filling of field “Офис“upon filling correct EGN in SharePoint – Expense report

  24. TEST CASES • BR.1S1TC3 Validate the format of prefilled field “Име на отчетното лице“ in SharePoint – Expense report • BR.1S2TC2 Validate the automatic filling of field “Позиция“upon filling correct EGN in SharePoint – Expense report PMO@bnpparibas-pf.bg

  25. PRACTICAL EXERCISE Show us what you’ve learned!

  26. PRACTICAL EXERCISE (1/3) Instruction: Read the BRD and test cases, following the steps 1. Analyze business requirements • 3. Describe the purpose of the test case • Identify all specific and unique situations, • based on the scenarios and all other • criteria: • Create all possible variations and combinations between the concerned processes, products, changes, JetIX positions, based on the criteria from the scenario • Identify concerned functionalities • Identify concerned fields • Identify concerned positions • Identify concerned systems • Identify concerned controls • 2. Describe the test scenarios • Identify all situations, coming from the real business processes, concerned in the business requirements and group them by a common criteria: • Concerned process • Concerned changes • 4. Design the test cases • Scenario ID • Scenario description • Test case ID • Test case purpose • Prerequisites • Test data set • Test steps • Expected result

  27. STEP 1: ANALYZE BUSINESS REQUIREMENTS (ANSWERS) • BR.1.2. Ръчно попълващи се полета от служител • Дата на плащане на заявка – Попълва се датата, на която служителят желае да му се плати отчетът. Датата трябва да има възможност да се попълва ръчно във форматмм/дд/гггг или използвайки календар в Shp. Датата на плащане трябва да е поне 2 дни след датата на изпращане на заявката (Например: ако датата на изпращане на заявка е 01.04.2013, най-ранната възможна дата за плащане трябва да е 03.04.2013). В случай, че това правило не е изпълнено, е необходимо да се появява предупредителен текст: „Датата на плащане трябва да е поне два дни след датата на изпращане на заявката”. В случай, че правилото, описано в тази част е изпълнено => продължаване на нормалния процес на изпращане и одобрение на заявка. Полето се попълва от изпращача на заявката в New form и може да бъде променяно единствено от отдел Clearing в Edit form. Legend: Requirement ID Functionalities Fields Positions Systems Controls

  28. PRACTICAL EXERCISE (2/3) • BR.1.2. Ръчно попълващи се полета от служител • Дата на плащане на заявка – Попълва се датата, на която служителят желае да му се плати отчетът. Датата трябва да има възможност да се попълва ръчно във форматмм/дд/гггг или използвайки календар в Shp. Датата на плащане трябва да е поне 2 дни след датата на изпращане на заявката (Например: ако датата на изпращане на заявка е 01.04.2013, най-ранната възможна дата за плащане трябва да е 03.04.2013). В случай, че това правило не е изпълнено, е необходимо да се появява предупредителен текст: „Датата на плащане трябва да е поне два дни след датата на изпращане на заявката”. В случай, че правилото, описано в тази част е изпълнено => продължаване на нормалния процес на изпращане и одобрение на заявка. Полето се попълва от изпращача на заявката в New form и може да бъде променяно единствено от отдел Clearing в Edit form.

  29. PRACTICAL EXERCISE (3/3)

  30. PRACTICAL EXERCISE – MY PROPSAL (1/4)

  31. PRACTICAL EXERCISE – MY PROPSAL (2/4)

  32. PRACTICAL EXERCISE – MY PROPSAL (3/4)

  33. PRACTICAL EXERCISE – MY PROPSAL (4/4)

  34. STEP 1: ANALYZE BUSINESS REQUIREMENTS (ANSWERS) • BR.2. Визуализация на формата на отчет за текущи разходи • Колоните „Начин на плащане на документ” и „Номер на кредитна карта” и полето „Сума, платена с кредитна карта” е необходимо да са видими при попълване, преглед и принтиране единствено и само при заявки за ЕГН-тата, притежатели на кредитни карти, съгласно сорс за кредитни карти. Във всички останали случаи е необходимо полето „Сума, платена с кредитна карта” да не се появява, а в логиката на всички формули да придобива стойност 0,00 лв, а под поле „Вид разход” и „Стойност на поле вид разход” и над табличната част с информация за документа, който се отчита, да се появяват две фиксирани полета: • „Начин на плащане”; „В брой” (стойността на полето „Начин на плащане”) Legend: Requirement ID Functionalities Fields Positions Systems Controls

  35. PRACTICAL EXERCISE – ADDITIONAL (1/2) • BR.2. Визуализация на формата на отчет за текущи разходи • Колоните „Начин на плащане на документ” и „Номер на кредитна карта” и полето „Сума, платена с кредитна карта” е необходимо да са видими при попълване, преглед и принтиране единствено и само при заявки за ЕГН-тата, притежатели на кредитни карти, съгласно сорс за кредитни карти. Във всички останали случаи е необходимо полето „Сума, платена с кредитна карта” да не се появява, а в логиката на всички формули да придобива стойност 0,00 лв, а под поле „Вид разход” и „Стойност на поле вид разход” и над табличната част с информация за документа, който се отчита, да се появяват две фиксирани полета: • „Начин на плащане”; „В брой” (стойността на полето „Начин на плащане”)

  36. PRACTICAL EXERCISE – ADDITIONAL (2/2)

  37. PRACTICAL EXERCISE (ADDITIONAL) – MY PROPOSAL (1/3)

  38. PRACTICAL EXERCISE (ADDITIONAL) – MY PROPOSAL (2/3)

  39. PRACTICAL EXERCISE (ADDITIONAL) – MY PROPOSAL (3/3)

More Related