The document is a presentation by Yuriy Malyi on simple QA audits. It begins with introducing the speaker and his company. It then provides definitions of audits from standards and discusses common reasons organizations conduct audits. The presentation outlines the audit process and focuses on auditing areas like product management, project management, Scrum management, QA processes, and configuration management. It presents points systems to rate compliance in these areas and shows results of applying this to a sample project.

1. Software quality assurance days
18 Международная конференция
по вопросам качества ПО
sqadays.com
Москва. 27–28 ноября 2015
Юрий Малый
Comodo. Одесса, Украина
QAПростой аудит

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

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

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

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

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

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

8. 1) Наведение прозрачности
2) Понимание реальной ситуации
3) Метрирование в определенной системе
4) Анализ результатов
5) Применение корректирующих воздействий
6) Снятие последующих метрик
7) Контроль «не деградации»
Простой QA аудит

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

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

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

12. Простой QA аудит
Point Product Management Comply Point
3 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

13. Простой QA аудит
Point Project Management Comply Point
5 Project roadmap follows product roadmap Yes 5
5 Traceability of the product features (EPIC) is established Yes 5
4 Risk register created per release No 0
4 Project Risk Register updated weekly Yes 4
3 Risk register is reviewed with team Regularly No 0
0 Integration Plan prepared N/A 0
4 Establish strategic training needs No 0
5 Project Specifications up to date Yes 5
1 Procurement Plan prepared No 0
1 Vacation Plan prepared No 0
3 Project status report prepared weekly Yes 3
5 Version and Release dates identified and compatible with product roadmap Yes 5
4 Project Calendar reflects all release dates, milestones etc. Yes 4
3 Release Notes created for each release No 0
1 Project has a organized confluence page Yes 1
1 All links are up to date Yes 1
1 All people working on project are listed on the home page Yes 1
1 All people working on project are assigned to mailing lists Yes 1
2 Communication Matrix prepared Yes 2
5 Prioritization Technic used and Product Backlog prioritized Yes 5
5 All items in backlog have an estimate No 0
5 Product Backlog in a manageable size Yes 5
1 Team have all people with a sufficient mix of skills to build a potentially shippable product increment Yes 1
3 All items in sprint plan have VERSION Yes 3
3 Team does not over Commit (10% tolerance) Yes 3
5 There is no Critical and Major bugs in Backlog Yes 5
3 Release Signoff process is applied No 0
83 Total 71% 59

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

15. Простой QA аудит
Point QA Comply Point
5 Every User Story has at least one User Acceptance Test No 0
1 Defects have summary Yes 1
1
Defects 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 1
1 Defects have Priority Yes 1
1 Defects have Component Yes 1
2 Defects have bug category No 0
2 TestRail is used Yes 2
2 Test cases created for each User Story (Preconditions, Test Steps, Expected Result) No 0
5 Test case automation is part of test case development Yes 5
1 Test cases executed with a defined Test Run Yes 1
1 Old test runs archived Yes 1
1 Failed test cases associated with a Defect/Bug No 0
2 Informal tests are executed in Dev. Test Environment Yes 2
2 Formal Tests (UAT, Smoke, Regression) are executed in Staging Environment Yes 2
1 QA plan up to date No 0
3 Test plan up to date No 0
2 Analysis of the bugs from the prod. environment No 0
2 Analysis of the bugs from the Staging environment (UAT, Smoke, Regression) Yes 2
1 All team members have been informed about Comodo Development and QA process Yes 1
3 Estimation of test case count No 0
40 Total 50% 20

16. Простой QA аудит
Point CM Comply Point
2 Development Environment is ready Yes 2
2 Source control environment is ready Yes 2
3
GIT 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

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

18. почта : yuriy.malyi@gmail.com
скайп : yura_clasic
Простой QA аудит