Lviv Direction QADay 2023 (Experience) ОКСАНА ТРОЯН «Щоб рейки зійшлись в одній точці: від кількості до якості. Як команда тестерів може вплинути на продукт?» telegram: https://t.me/+IJODE0i4X65kNjcy fb: www.fb.com/goqaevent fb: www.fb.com/qaday.org linkedin: https://www.linkedin.com/company/goqa/ Сайт: www.qaday.org

1. Щоб рейки зійшлись в одній точці:
від кількості до якості.
Як команда тестерів може вплинути на продукт?
Oksana Troian
Associate & Technology Manager
Quality Assurance в GlobalLogic

2. Зміст виступу
1. Команда
2. Комунікація
3. Клієнт
4. Клієнторієнтованість
5. Контроль якості
6. Критерії оцінки проекту
• Process Metrics
• Product Metrics
• Project Metrics
7. Корисні посилання

3. Доповідач
ОКСАНА ТРОЯН
Associate & Technology Manager
Quality Assurance в GlobalLogic
• 9 років досвіду роботи в IT-індустрії:
• 2 рокиManual QA у компанії GlobalLogic (медичний проект);
• 1рік Automation QA у компанії GlobalLogic (медичний проект);
• 2 роки QA Manager у компанії Qartrock (візуалізація даних);
• 2 роки PM assistant у компанії GlobalLogic (медичний проект).
• 2 роки PM у компанії GlobalLogic (освітній проект, телевізійна платформа).
• Тechnology Manager у львівській філії GlobalLogic з 2018р.;
• Викладач курсів “Manual QA” та ISTQB в компаніях:
• GlobalLogic;
• Logos IT-Academy;
• Quality Assurance Group.
• к.т.н, кафедри АСУ НУ”ЛП”;

4. Команда
Якщо хочеш йти швидко — іди сам, якщо хочеш дійти далеко — йди з іншими.
надійна команда -> надійні проекти -> надійні клієнти!!!
Ефективна команда допомагає досягати більшого, якіснішого, більш прогресивного
результату в найкоротший проміжок часу з фокусом на довгострокову перспективу.

5. Основні ознаки сформованої команди:
1.Самоорганізація.
Команда відповідає за все, що відбувається навколо неї,
та самостійно може ухвалювати всі рішення, які її стосуються.
Щоб підтримувати самоорганізацію в команді, потрібні довіра
та відкритість.
2.Цілісність.
Кожен член команди вважається передусім цілісною
особистістю, з усіма позитивними якостями та недоліками,
а не лише механізмом для виконання певної частини роботи.
3.Еволюційна мета.
Проект це те чим команда живе. Свобода приведе до хаосу,
якщо немає спільного вектора, у якому команда працює
та розвивається.

6. Комунікація
Секрет ефективного проєкту — відкрита і ефективна комунікація. Управління комунікацією в
проєкті вимагає ретельного планування, організації та контролю всіх комунікативних процесів.
Ефективна комунікація забезпечує, те що всі учасники проєкту розуміють свої завдання,
очікування та графік. Забезпечує належну комунікацію між усіма членами команди, а також
між командою проєкту та стейкхолдерами. Якісна передача інформації допоможе уникнути
непорозумінь та забезпечить якісне виконання проєкту.

7. Комунікація
Ключовим етапом в успішній реалізації проєктів є ефективна комунікація та чітка
документація у розподілених командах. Завжди потрібно робити вибір, часом
компромісний, між метою проєкту, складністю бізнес-вимог, нефункціональними вимогами
до продукту, питаннями комунікації в команді.
Важливо пам’ятати:
1.Люди не читають думок;
2.Будь-які зміни потребують детального планування;
3.Не толерувати те, що погано працює;

8. Клієнт
Наші клієнти, як правило, видатні експерти у своїй ринковій ніші, і можуть розповісти про неї дуже багато.
Це люди з широким світоглядом, які виявляють живий інтерес до діджиталу та розуміють його потенціал.
Деякі клієнти приходять до нас, маючи на увазі лише загальну ідею продукту, а деякі - з ТЗ різної якості та
рівня опрацювання.
1. Важливо вміти поставити себе на місце замовника та навчитися
дивитися на проект його очима;
2. На етапі збору вимог важливо зібрати якнайбільше даних;
3. Не зайвим буде затвердити бриф безпосередньо у клієнта;
4. Хорошою практикою є демонстрація клієнту демок;
5. Іноді замовнику варто нагадати про кінцевих користувачів;
6. Створити корисне рішення для бізнесу можна лише у тісній
співпраці зі стороною клієнта.

9. Клієнторієнтованість
Тестер — це багатофункційний спеціаліст. І чим глибше QA розуміє продукт, тим він крутіший.
Треба перевіряти різноманітні кейси й обов’язково все документувати, розбиратися в технічній частині
продукту, чітко уявляти структуру компанії та зони відповідальності, орієнтуватися, які задачі виконують
інші команди, що створюють продукт, брати участь у загальній комунікації, не боятися запитувати
й уточнювати, навіть якщо це прямо не стосується технічної частини продукту.
QA повинен:
• розуміти, яка команда чим займається та за який функціонал відповідає
на кожному етапі;
• розуміти, у кого про що запитувати;
• дотримуватися зручної всім системи комунікації, сповіщень про баги;
• комунікувати з сапортом і повідомляти про зміни в продукті й функціоналі;
• цікавитися, які проблеми найчастіше виникають у юзерів, аналізувати
проблемні місця продукту.

10. Контроль якості
Показники контролю якості:
1.Якість тестової документації;
2.Час на виявлення та виправлення помилок;
3.Охоплення тестових випадків;
4.Надійність тестів;
5.Розподіл дефектів.
Якість тестової документації — міра того, наскільки ефективно
тестова документація відображає вимоги до програмного
забезпечення, описує тести та результати їх виконання.
Оцінити документацію можна за такими критеріями:
1. Наочність;
2. Структурованість;
3. Доступність;
4. Актуальність.

11. Контроль якості
Product documentation описує продукт, який розробляють, та містить
інструкції щодо виконання різних завдань з ним. Загалом це вимоги,
технічні характеристики, логіка та мануали. Два основних типи product
documentation:
•System documentation — документи, що описують саму
систему та її частини. Це Requirement documents, Design
decisions, Architecture descriptions, Program Source code, and
Testing documents.
•User documentation — це інструкції, які підготовлені переважно
для кінцевих користувачів продукту та команди підтримки. Це
Tutorials, User guides, Troubleshooting manuals, Installation,
Reference manuals.
Process documentation описують процес. Можуть бути Standards, Project
plans, Test schedules, Reports, Meeting notes тощо.
Технічна документація – містить повний опис логіки конкретної частини продукту, що розробляється і варіанти, сценарії використання предмета
розробки користувачами.
Усю документацію можна розділити на дві основні категорії:
1.Product documentation;
2.Process documentation;

12. Критерії оцінки проекту
Критерії оцінки проекту потрібні для:
1.Інформування клієнта про прогрес;
2.Вдосконалення продукту та виявлення прогалин;
3.Оптимізування процесів;
4.Діагностування помилок;
5.Прийняття рішень щодо покращення продукту.
Process Metrics: допомогою можна підвищити ефективність процесу SDLC;
Product Metrics: стосується якості програмного продукту;
Project Metrics: може бути використаний для вимірювання ефективності проектної команди або будь-яких інструментів
тестування, які використовуються членами групи;

13. Product metrics
1. Test Case Preparation Productivity (Продуктивність підготовки тест-кейсів)
використовується для розрахунку кількості підготовлених тест-кейсів та зусиль (Effort), витрачених на їхню підготовку.
Test Case Preparation Productivity = (Num of Test Case) / (Effort spent for Test Case Preparation);
2. Test Design Coverage (Охоплення тестового дизайну) відсоток покриття тест-кейс вимог.
Test Design Coverage = ((Total number of requirements mapped to test cases) / (Total number of requirements)*100;
3. Test Execution Productivity (Продуктивність виконання тестів) визначає кількість тест-кейсів, які можуть бути виконані за годину.
Test Execution Productivity = (Num test tests executed) / (Effort spent for execution of test cases);
4. Test Execution Coverage (Покриття виконаних тестів)
призначене для вимірювання кількості виконаних тест-кейсів порівняно з кількістю запланованих тест-кейсів.
Test Execution Coverage = (Total num of test cases executed / Total num of test cases planned to execute)*100;
5. Test Cases Passed/Failed/Blocked (К-ть успішних/неуспішних/заблокованих тест кейсів)
для вимірювання відсотка пройдених успішно/неуспішно/заблоковано тест-кейсів.
Test Cases Pass/Failed/Blocked = (Total no. of test cases passed/failed/blocked) / (Total no. of test cases executed)*100;

14. Process metrics
1. Error Discovery Rate (Рівень виявлення помилокйсів) використовується для визначення ефективності тест-кейсів.
Error Discovery Rate = (Total number of defects found /Total number of test cases executed)*100;
2. Defect Detection Percentage (Відсоток виявлення дефектів) відношення кількості дефектів, які були знайдені на предрелізній
стадії із загальною кількістю дефектів перед та пострелізній стадії.
Defect Detection Percentage= Total number of ‘pre-release’ bugs / Total number of ‘pre-release+post release’ bugs;
3. Defect Fix Rate (Рівень виправлення дефектів) допомагає дізнатися якість продукту з строни усунення дефектів.
Defect Fix Rate = (Total num of Defects reported as fixed - Total num of defects reopened) / (Total num of Defects reported as fixed +
Total num of new Bugs due to fix)*100;
4. Defect Density (Щільність Дефектів) кількість дефектів на одиницю або весь продукт, спринт, функцію, об’єм вихідного коду.
Defect Density = Total number of defects identified / Actual Size (requirements);
5. Defect Leakage (К-ть пропущених багів) показує скільки ми протустили дефектів і їх просочилось в реліз
Defect Leakage= ((Total bug on prod)/ (Total bug found )*100;

15. Project Metrics
Завдання цього набору метрик оцінити наскільки якісно тестувальники виконують свої завдання,
визначити рівень компетенцій і зрілості команди QA. Володіючи таким набором показників можна
порівнювати команду з нею ж самою у різні моменти часу або з іншими, зовнішніми групами тестування.
1. Швидкість роботи (velocity) команди QA;
2. Реальний час роботи команди;
3. Задоволеність клієнта командою;
4. Відгуки користувачів про продукт;
5. Стороння експертиза.
"Ви не можете контролювати те, що не можете виміряти“
Том Демакро

16. Підсумок
1. Технічна документація допомагає в перспективі;
2. Чітка специфікація, чіткі інструкції: менше запитань, менше мітингів, більше результатів;
3. Щоб потрапити в десятку, своєчасно отримати потрібний результат і виправдати очікування,
необхідно розписувати, чого прагнете, або змінювати процес розробки та й продукт загалом;
4. Командна робота передбачена у всьому: від планування до кінцевих user guides;
5. QA-інженер має колосальний вплив на процес розробки технічної документації;
6. Команда тестування — найближча до кінцевого результату; ні замовник, ні менеджери не можуть
так сильно зрозуміти «біль» та «радість» від користування продуктом;
Впливайте на якість вашого продукту!!!

17. Корисні посилання
1. Software Test Metrics – Product Metrics & Process Metrics
2. What Metrics Should You Be Using?
3. Different Software Quality Metrics used by Expert Test Managers
4. Лояльні й мотивовані QA-спеціалісти: як їх розпізнати та виховати
5. Найбільш важливі метрики QA
6. Види документації у роботі тестувальника
7. Шляхи покращення тестування ПЗ
8. Навіщо дотримуватися документування на проєкті і хто це повинен контролювати

18. Дякую за увагу!!!
Oksana Troian
Associate & Technology Manager
Quality Assurance GlobalLogic
LinkedIn
Facebook
Telegram