Привіт, Хабре!
У нас нова важлива тема – якісна розробка IT-продуктів. Ми часто говоримо на HighLoad++, як зробити навантажені сервіси швидкими, а на Frontend Conf — класний інтерфейс, який не гальмує. У нас регулярно є теми про тестування та DevOpsConf про об'єднання різних процесів, включаючи тестування. А про те, що можна назвати якість загалом, і як над ним комплексно працювати, ні.
Виправимо це на - Будемо розвивати культуру думати про якість кінцевого продукту для користувача на кожній стадії розробки. Звичку не зациклюватися на своїй зоні відповідальності та асоціювати якість не лише з тестувальниками.
Під катом поговоримо з головою програмного комітету, керівником тестування в Тінькофф.Бізнес, творцем російськомовної QA-спільноти Анастасією Асєєвою-Нгуєн про стан галузі QA та місію нової конференції.
- Настя Привіт. Розкажи, будь ласка, про себе.
Анастасія: Я керую тестуванням у банку, відповідаю за дуже велику команду — нас понад 90 осіб Ми маємо важливу бізнес-лінію, ми відповідаємо за екосистему для юридичних осіб.
Я навчалася на мехматі і спочатку хотіла стати програмістом. Але коли у мене з'явилася цікава пропозиція, я вирішила спробувати себе у ролі тестувальника. Як не дивно, це виявилося моїм покликанням. Нині всю свою роботу я бачу саме у цій галузі.
Я затятий представник дисципліни Quality Assurance. Мені не байдуже, які продукти створюються, як ставляться до якості у компанії, у команді та, у принципі, у процесі розробки.
Для мене очевидно, що спільнота у цьому напрямі недостатньо зрілапринаймні в Росії. Не завжди ми розуміємо, що забезпечення якості — це не лише факт тестування додатка на відповідність вимогам. Мені хотілося б змінити цю ситуацію.
- Ти вживаєш слова Quality Assurance та тестування. В очах обивателя ці два терміни дуже часто перетинаються. Чим вони відрізняються, якщо копати глибоко?
Анастасія: Скоріше, не відрізняються. Тестування – частина дисципліни Quality Assurance, це безпосередня діяльність – сам факт того, що я щось тестую. Видів тестування насправді дуже багато, і за різні види тестування відповідають різні люди. Але у нас у Росії, коли з'явилася хвиля аутсорсерів, які постачають тестувальників у компанії, тестування звелося до єдиного виду.
Найчастіше обмежуються лише функціональним тестуванням: перевіряють, що те, що накодували розробники, відповідає специфікації і все.
— Розкажи, будь ласка, які є ще дисципліни забезпечення якості? Що ще, окрім тестування, сюди входить?
Анастасія: Quality Assurance - це, в першу чергу, про створення якісного продукту Тобто ми запитуємо, які атрибути якості повинен мати наш продукт. Відповідно, якщо ми це розуміємо, можемо зіставити, хто впливає ці атрибути якості. Неважливо, розробник, проджект-менеджер чи продуктолог - це людина, яка впливає на розвиток продукту, на його беклог, на його стратегію.
Тестувальник краще починає усвідомлювати свою роль. Він розуміє, що його завдання не лише тестувати на відповідність вимогам, а й тестувати вимоги, ставити під сумнів формулювання, що походять від продуктолога, розкривати всі неявні вимоги та очікування клієнта. Коли ми поставляємо нову функціональність нашому клієнту, ми повинні дійсно задовольнити його очікування та вирішити його біль. Якщо ми думатимемо про всі атрибути якості, клієнт буде задоволений і розумітиме, що компанія, чиїм продуктом він користується, дійсно дбає про його інтереси, а не працює за принципом «аби випустити фічу».
— Здається, те, що ти зараз описала, це завдання продуктолога. Це, в принципі, не про тестування і не якість — це взагалі про product management, ні?
Анастасія: В тому числі. Quality Assurance - це не дисципліна, за яку відповідає одна конкретна людина. Зараз є популярний напрямок у тестуванні, підхід, який називається Agile тестування. У його визначенні прямо звучить, що це командний підхід до тестування, який включає певний набір практик. За реалізацію цього підходу відповідає вся команда, навіть не обов'язково щоб у команді був тестувальник. Вся команда орієнтована те що, щоб доставити цінність клієнту, і щоб ця цінність відповідала його очікуванням.
— Виходить, що якість перетинається чи не з усіма навколишніми дисциплінами, накладаючи рамки на все довкола?
Анастасія: Правильно Коли ми замислюємося про те, що хочемо створити якісний продукт, ми починаємо думати про різні атрибути якості. Наприклад, як перевірити, що ми справді зробили фічу, яка потрібна нашому клієнту.
Тут випливає такий вид тестування, як UAT (User Aceptance Testing). На жаль, у Росії він рідко практикується, але іноді присутній у SCRUM-командах як демо для кінцевого клієнта. У закордонних компаніях це досить поширений вид тестування. Перед тим, як відкрити функціональність для всіх клієнтів, ми спочатку робимо UAT, тобто запрошуємо кінцевого споживача, який проводить тестування та одразу дає фідбек — чи справді продукт відповідає очікуванням та вирішує біль. Тільки після цього відбувається масштабування на решті клієнтів.
Тобто ми орієнтуємося на бізнес, кінцевого клієнта, але при цьому не забуваємо про технологію. Від технологій теж дуже залежить якість продукту. Якщо у нас буде погана архітектура, ми не зможемо швидко випускати фічі та відповідати очікуванням клієнта. Може бути багато багів при спробі масштабувати або при спробі зробити рефакторинг ми можемо щось зламати. Це все впливатиме на задоволеність клієнта.
З цієї точки зору, архітектура має бути такою, щоб ми могли писати чистий код, який дозволить швидко вносити зміни та не боятися, що ми всі розламаємо. Щоб ітерації доопрацювання не розтягувалися на кілька місяців просто тому, що у нас так багато легасі, і потрібно робити тривалі етапи тестування.
— Усього вже задіяні розробники, архітектори, продуктологи, продакт-менеджери, самі тестувальники. Хто ще задіяний у процесі забезпечення якості?
Анастасія: Тепер уявимо, що ми вже доставили клієнту фічу Очевидно, за якістю продукту потрібно стежити, і коли він уже у продакшені. На цьому етапі можуть проявитись ситуації з неочевидними сценаріями, так звані баги.
Перше питання — як ми працюємо з цими багами після того, як випустили продукт? Як ми, наприклад, реагуємо на навантаження? Клієнт буде дуже задоволений, якщо сторінка завантажується більше 30 секунд.
Тут вступає в гру експлуатація або, як зараз називають, DevOps. За фактом це люди, які відповідають за експлуатацію продукту, коли він уже на продажі. Сюди входять різноманітні види моніторингу. Є навіть підвид тестування - тестування на проді, коли ми дозволяємо собі щось не тестувати до викочування і тестуємо це відразу на проді. Це низка заходів з погляду організації інфраструктури, які дають змогу швидко відреагувати на інцидент, вплинути на нього, виправити.
Інфраструктура також важлива. Часто бувають ситуації, коли під час тесту неможливо переконатися, що у нас справді все те, що ми хотіли б дати клієнту. Викочуємо на прод - і починаємо ловити неочевидні ситуації. А все тому, що інфраструктура у тесті не відповідає інфраструктурі на проді. Звідси випливає новий вид тестування. тестування інфраструктури. Це різні конфігурації, налаштування, міграція бази даних і т.д.
Звідси виникає запитання, можливо, команді потрібно використовувати інфраструктуру як код.
Я вірю, що інфраструктура безпосередньо впливає на якість продукту.
Сподіваюся, на конференції буде доповідь із реальним кейсом. Напишіть нам, якщо готові на своєму досвіді розповісти, як інфраструктура, як код, впливає на якість. Інфраструктура як код дозволяє простіше перевіряти всі налаштування та тестувати те, що інакше просто неможливо. Тому процес розробки якісного продукту залучається і експлуатація.
— А що щодо аналітики та документації?
Анастасія: Це відноситься більше до enterprise систем. Коли ми говоримо про enterprise, відразу на думку приходять такі люди, як аналітики та системні аналітики. Іноді їх називають технічними письменниками. Вони отримують завдання написання специфікації і виконують його, наприклад, місяць.
Неодноразово доведено, що написання такої документації призводить до дуже тривалих ітерацій розробки та тривалих ітерацій доопрацювання, тому що в процесі тестування виявляються баги, починаються повернення. В результаті з'являється дуже багато петель, які підвищують вартість розробки. Крім того, це може зробити вразливості. Ми начебто написали еталонний код, але потім внесли зміни, які ламають ідеально продуману архітектуру.
У результаті виходить не зовсім якісний продукт, тому що в архітектурі вже з'явилися латки, код у деяких місцях недостатньо покритий тестами, тому що терміни підтискають, потрібно швидше закрити всі баги. А все тому, що в початковій специфікації не було враховано всіх моментів, які потрібно реалізувати.
Розробники — не шкідники і спеціально не пишуть код з помилками.
Якби ми спочатку продумали специфікацію, в якій були б висвітлені всі необхідні моменти, то все було б реалізовано так, як і потрібно. Але це утопія.
Напевно, написати ідеальну специфікацію на 100 сторінок неможливо. Тому потрібно замислитися про альтернативні способи написання документації, специфікації, постановки завдань, які б наближали нас до того, щоб розробник робив саме те, що треба.
Тут на думку спадають підходи з Agile - користувальницькі історії з aceptance критеріями. Це найбільше застосовується для команд, які розвиваються маленькими ітераціями.
— Що щодо usability-тестування, зручності використання продукту, дизайну?
Анастасія: Це дуже важливий момент, тому в команді є дизайнери Найчастіше дизайнерами користуються як сервісом або відділ дизайнерів, або дизайнер на аутсорсі. Часто зустрічаються ситуації, що як би дизайнер послухав продуктолога і зробив те, що зрозумів. Але коли приступаємо до ітерації, з'ясовується, що насправді зроблено не те, що очікували: дизайнер щось забув, не до кінця продумав поведінку, бо він не в команді і не в контексті, або розробник фронтенд не до кінця зрозумів його макет. Може знадобитися кілька ітерацій лише через те, що є проблема з розумінням дизайну фронтенд-розробником.
Плюс є ще одна проблема. Зараз набирають популярності дизайн-системи. Вони на хайпі, але зиск від них не зовсім очевидний.
Я стикаюся з думкою, що дизайн-системи, з одного боку, полегшують розробку, з іншого боку — накладають дуже багато обмежень на інтерфейс.
У результаті ми робимо не таку фічу, яку клієнт хоче отримати, а таку, яка зручна нам, тому що у нас вже є певні кубики, з яких ми можемо її зробити.
Мені здається, на цю тему варто звернути увагу і замислитись, чи справді у спробі спростити роботу над дизайном ми вирішуємо клієнтський біль.
— Виходить напрочуд багато тем, пов'язаних Quality Assurance. У Росії є конференція, де всі їх можна обговорити?
Анастасія: Є найстаріша конференція з тестування, яка цього року пройде 25-й раз і так і називається — Конференція із забезпечення якості SQA Days В основному на ній обговорюються інструменти та конкретні підходи тестування для функціональних тестувальників. Як правило, у доповідях на SQA Days глибоко розглядаються конкретні області у зоні відповідальності самих тестувальників, але не комплексні заходи.
Це чудово допомагає розібратися в різних інструментаріях та підходах, як тестувати бази даних, API тощо. Але при цьому, з одного боку, не мотивує залучати до створення якіснішого продукту не тільки тестування. А з іншого — тестувальники не стають більш залученими до процесу, щоб думати про глобальну мету продукту та його бізнес-складник.
Я керую великим відділом, проводжу багато співбесід, які насправді дозволяють уявити стан галузі загалом. Як правило, наші хлопці працюють у підприємстві, і у них чітка зона відповідальності. Колеги, які працюють у зарубіжних проектах, використовують різні види тестування: самі можуть робити тестування навантаження, тестування продуктивності, і навіть іноді тестування безпеки (security testing), тому що вони дійсно допомагають команді забезпечувати продукт якістю.
Мені хотілося б, щоб у нас у Росії хлопці теж почали замислюватися про те, що на функціональному тестуванні галузь не закінчується.
— Для цього ми й організуємо нову конференцію QualityConf, яка присвячена якості як цілісної дисципліни. Розкажи про задум докладніше, у чому основна мета конференції?
Анастасія: Ми хочемо створити спільноту людей, зацікавлених робити якісні продукти Запропонувати майданчик, куди вони зможуть прийти, послухати доповіді та вийти після конференції з конкретним розумінням, що потрібно поміняти для покращення якості.
Часто зараз чую запит від консалтингу, що робити, коли є проблеми із тестуванням, з якістю. Коли починаєш спілкуватися з командами, бачиш, що проблема не в самих тестувальниках, а в тому, як збудований процес. Наприклад, коли розробники вважають, що вони відповідальні лише за написання коду, їхня відповідальність закінчується рівно в той момент, коли вони передали завдання на тестування.
Не всі замислюються про те, що погано написаний неякісний код із поганою архітектурою загрожує великими проблемами для проекту. Не замислюються про вартість помилок, про те, що баги, що потрапили в продакшен, можуть вилитися у великі витрати для компанії та команди. Немає культури думати про це. Хочу, щоб на конференції ми почали її розповсюджувати.
Я розумію, що це не інновація. Едвард Демінг, автор 14 постулатів якості, писав про вартість помилки ще у минулому столітті. На цій книзі базується Quality Assurance як дисципліна, але, на жаль, сучасна розробка забуває про це.
— А теми безпосередньо про тестування та інструменти плануєте торкнутися?
Анастасія: Припускаю, що будуть доповіді про інструменти Існують досить універсальні інструменти, за допомогою яких компанії та команди можуть вплинути на продукт.
Всі доповіді глобально будуть об'єднані однією спільною місією: донести до аудиторії, що за допомогою цього підходу, інструменту, методу, процесу та виду тестування ми вплинули на якість продукту та покращили життя клієнта.
У нас точно не буде доповідей про інструмент для інструменту. Усі доповіді, які потраплять до програми, будуть об'єднані спільною метою.
— Кому буде цікаво те, про що ти говориш, кого бачиш як гість конференції?
Анастасія: У нас будуть доповіді для розробників, яким небайдужа доля свого проекту, продукту, системи Аналогічно буде цікаво тестувальникам і, як на мене, особливо менеджерам. Під менеджерами я маю на увазі людей, які приймають рішення та можуть впливати на долю та розвиток продукту, системи, команди у тому числі.
Це люди, які запитують — як підвищити якість продукту, системи. На нашій конференції вони дізнаються про різноманітні комплекси заходів та зможуть зрозуміти, що у них зараз не так, що треба змінити.
Думаю, головний критерій – розуміти, що з якістю щось не так, і хотіти на це вплинути. Напевно, з першого разу достукатися до людей, котрі вважають, що й так зійде, нам не вдасться.
— Як ти вважаєш, індустрія загалом дозріла для того, щоб поговорити не просто про тестування, а про культуру якості?
Анастасія: Я вважаю, що дозріла Зараз багато компаній відходять від традиційного Waterfall-підходу у бік Agile. Йде орієнтація на клієнта, люди в командах справді починають замислюватися над тим, як створити якісний продукт. Навіть у enterprise-компаніях відбувається переорієнтація на підвищення якості.
Судячи з кількості запитів, які виникають у спільноті, я вважаю, що вже час. Не певна звичайно, що це буде масштабна революція, але мені хотілося б, щоб цей переворот у свідомості стався.
- Домовилися! Будемо щепити культуру і перевертати свідомість.
Конференція щодо якісної розробки IT-продуктів відбудеться у Москві 7 червня. Знаєте, з яких етапів складається якісний продукт, у запасі є кейси успішної боротьби з багами на проді, на своїй практиці перевірили популярні методики – нам потрібен ваш досвід. свої заявки до 1 травня, а Програмний комітет допоможе сфокусувати тему загальної цілісності конференції.
Підключайтесь до , в якому обговорюємо питання якості та конференцію, підписуйтесь на , щоб бути в курсі новин програми.
Джерело: habr.com