Простой qa аудит

Software quality assurance days18 Международная конференция по вопросам качества ПОsqadays.com

Москва. 27–28 ноября 2015

Юрий МалыйComodo. Одесса, Украина

Простой QA аудит

ФИО: Малый Юрий ИвановичКомпания: COMODOПозиция: QA managerСтаж в IT: 10 лет


• Сколько здесь тестировщиков?• Сколько здесь менеджеров/тим лидов?• Сколько здесь програмистов?• Сколько здесь эйчаров?


Аудит– систематический, независимый и документированный процесс получения свидетельств аудита и объективного их оценивания с целью установления степени выполнения согласованных критериев аудита (ISO 19011:2011 «Руководство по аудиту систем менеджмента»)


Аудит – независимая оценка программных продуктов и процессов, проводимая уполномоченным лицом, с целью оценить их соответствие требованиям.(Словарь-справочник терминов нормативно-технической документации)


1) Проблемы качества2) Проблемы процесса3) Необходимость унификации4) Желание развиваться и улучшаться5) Необходимость повышения уровня

зрелости компании/проектов


1) Наведение прозрачности2) Понимание реальной ситуации3) Метрирование в определенной системе4) Анализ результатов5) Применение корректирующих

воздействий6) Снятие последующих метрик7) Контроль «не деградации»


1) Управление проектом2) Скрам-процессы3) Обеспечение качества4) Конфигурация окружения5) Менеджемент продукта



Point Product Management Comply Point3 Product vision ready Yes 3

2 Product vision confirmed Yes 2

3 Product Roadmap ready Yes 3

2 Product Roadmap confirmed Yes 2

3 Product Roadmap up to date No 0

3 Product features listed and detailed Yes 3

3 Participating grooming meetings No 0

3 Participating review meetings Yes 3

3 Participating Sprint Planning 1 meetings Yes 3

5 Using Prioritizing method for backlog prioritizing Yes 5

5 Regular backlog prioritizing Yes 5

35 Total 83% 29


Point Project Management Comply Point5 Project roadmap follows product roadmap Yes 55 Traceability of the product features (EPIC) is established Yes 54 Risk register created per release No 04 Project Risk Register updated weekly Yes 43 Risk register is reviewed with team Regularly No 00 Integration Plan prepared N/A 04 Establish strategic training needs No 05 Project Specifications up to date Yes 51 Procurement Plan prepared No 01 Vacation Plan prepared No 03 Project status report prepared weekly Yes 35 Version and Release dates identified and compatible with product roadmap Yes 54 Project Calendar reflects all release dates, milestones etc. Yes 43 Release Notes created for each release No 01 Project has a organized confluence page Yes 11 All links are up to date Yes 11 All people working on project are listed on the home page Yes 11 All people working on project are assigned to mailing lists Yes 12 Communication Matrix prepared Yes 25 Prioritization Technic used and Product Backlog prioritized Yes 55 All items in backlog have an estimate No 05 Product Backlog in a manageable size Yes 51 Team have all people with a sufficient mix of skills to build a potentially shippable product increment Yes 13 All items in sprint plan have VERSION Yes 33 Team does not over Commit (10% tolerance) Yes 35 There is no Critical and Major bugs in Backlog Yes 53 Release Signoff process is applied No 0

83 Total 71% 59


Point Scrum Management Comply Point3 Every User Story is written in the following way: “As <PERSONA>, I want <WHAT> so that <WHY>“. No 03 Regular daily scrum meetings Yes 32 In Daily Scrum Meeting team talk about only scrum agenda No 03 Regular SP1 meetings Yes 33 Regular SP2 meetings Yes 35 Regular grooming meetings No 02 Do team use poker card planing for estimation points No 02 Regular review meetings Yes 22 Regular retrospective meetings Yes 22 Meeting Minutes created after Retrospective Meeting No 02 Meeting Minutes created after Grooming Meeting No 03 Team uses physical scrum board No 03 Solution Design Spec. created and modified iteratively Yes 32 User Stories are expressed in Independent, Negotiable, Valuable, Estimatable, Small and Testable No 03 Every User Story has Acceptance Criteria and refers to Definition of Done (DoD) No 04 Person who will accept the US is identified Yes 44 Every US is demonstrated at the end of sprint No 04 Story dependencies are identified No 01 Current sprint page up to date Yes 11 Old sprint pages are archived Yes 11 Team have a sprint backlog Yes 13 All items in sprint plan have an estimate Yes 32 Every Big User Story has task/s Yes 21 Well defined DoD No 02 Test Reports up to date Yes 22 Tasks and US's In review and Done state have comment/s Yes 25 Progress reflection to JIRA board (Board Management) Yes 51 Continuous Sprints Yes 11 Meaningful Sprint Naming No 02 No Additional User Stories Can Be Added to the Sprint No 02 Well defined Sprint Goal Yes 23 Code Review for New feature development Yes 33 Unit Testing for New feature development Yes 30 Integration Test for New feature development N/A 01 Tasks take no longer than one working day No 03 On Time Code Freeze No 03 Acceptance criteria for Sprint achievement No 0

89 Total 52% 46


Point QA Comply Point5 Every User Story has at least one User Acceptance Test No 01 Defects have summary Yes 1

1Defects have description? (Preconditions, Environment / Device/ OS, Test Steps, Expected Result, Actual, Result, TestRail link (Related Test Cases) Screen Shots) No 0

1 Defects have Affected version Yes 11 Defects have Priority Yes 11 Defects have Component Yes 12 Defects have bug category No 02 TestRail is used Yes 22 Test cases created for each User Story (Preconditions, Test Steps, Expected Result) No 05 Test case automation is part of test case development Yes 51 Test cases executed with a defined Test Run Yes 11 Old test runs archived Yes 11 Failed test cases associated with a Defect/Bug No 02 Informal tests are executed in Dev. Test Environment Yes 22 Formal Tests (UAT, Smoke, Regression) are executed in Staging Environment Yes 21 QA plan up to date No 03 Test plan up to date No 02 Analysis of the bugs from the prod. environment No 02 Analysis of the bugs from the Staging environment (UAT, Smoke, Regression) Yes 21 All team members have been informed about Comodo Development and QA process Yes 13 Estimation of test case count No 0

40 Total 50% 20


Point CM Comply Point2 Development Environment is ready Yes 2

2 Source control environment is ready Yes 2

3GIT branching model is adapted (Development in dev-branch, releases in master branch) Yes 3

3 Continuous Integration (CI) is up and running No 0

2 Test Environment is ready Yes 2

2 Staging Environment is ready Yes 2

2 Deployment Strategy is ready Yes 2

3 CM plan up to date Yes 3

3 CM plan is reviewed with team Yes 3

3 Running Unit test in CI No 0

0 Running Integration Test in CI N/A 0

3 Running Functional Test in CI No 0

3 Ready for Continuous Delivery No 0

31 Total 61% 19

почта : [email protected]скайп : yura_clasic


mailto:[email protected]

Простой qa аудит

Education