Ефективні методи забезпечення якості

Працюючи в «Ефективно», я брав участь у більш ніж 30 різних проектах. Усі вони були абсолютно різні: веб-і мобільні, великі та маленькі, складні та прості. Ми будували проекти з нуля, додавали нові можливості та підтримували існуючі проекти.

У процесі забезпечення якості, тестуванні, управлінні та розробці було багато складних випадків, і зараз, здається, наша команда пройшла Per Aspera ad Astra.

В даний час, здається, нічого особливого не було зроблено, але, порівнюючи Ефективне час від часу, я можу сказати, що ми зробили величезний крок вперед. Аналізуючи помилки, були побажання та пропозиції команди, я підготував наступний список найкращих практик для забезпечення якості. Мета цього списку - допомогти молодим командам зрозуміти, що може бути для них корисним, не витрачаючи багато часу на дослідження. Для деяких досвідчених це може виглядати як переосмислення велосипедів :) Ось ми і ідемо!

Розумійте бізнес-цілі та уточнюйте критерії прийняття

Це наріжний камінь проекту, і його слід з’ясувати до початку розробки. Команда проекту повинна зрозуміти, що потрібно робити, хто є цільовою аудиторією / споживачем функцій та як зрозуміти, що нічого не залишається робити.

Розуміння бізнес-цілей допоможе вам відповісти на запитання на кшталт "Що нам потрібно робити і хто буде ними користуватися?" Критерії прийняття допоможуть зрозуміти, чи відповідає функція бізнес-цілям чи ні. Зі свого досвіду можу сказати, що цілі бізнесу та критерії прийняття повинні бути підтверджені клієнтом або представником клієнта. Крім того, на основі чітких та прозорих бізнес-цілей та критеріїв прийняття кваліфіковані компанії, що розробляють програмне забезпечення, що надають аутсорсинг, можуть вдосконалити бізнес-ідею або запропонувати краще рішення.

CI / CD - Постійна інтеграція / Постійне впровадження

Звучить знайомо ... Чи не так? Однією з тенденцій у сучасній розробці програмного забезпечення, головна перевага якої з точки зору команди QA - це те, що ми можемо легко отримати збірку з найновішими функціями або виправленнями.

Під час циклу розробки наша команда розробників може мати безліч гіт git, пов'язаних з різними можливостями, але лише одна гілка містить найновіший код. Інструмент CI перевіряє цю гілку, і коли код змінюється, він створює нову збірку і надає їй доступ до визначеної служби дистрибуції.

Ми спробували TeamCity та Jenkins. Обидва ці чудові інструменти. У TeamCity є прекрасніший інтерфейс користувача, але Дженкінс абсолютно безкоштовний, тому ми вибрали Дженкінса.

Послуги з розподілу додатків

Загалом, схоже, що нічого особливого, але під кришкою безперервна інтеграція з налаштованими службами розгортання додатків дає вам найпростіший і найшвидший спосіб отримати останню версію на будь-якому тестовому пристрої чи середовищі, яке ви хочете. Добре завантажувати збірку через USB на один пристрій. Але що робити, якщо вам потрібно перевірити збірку за допомогою 10 різних пристроїв? В тім-то й річ.

Для мобільних проектів ми спробували кілька різних сервісів, таких як HockeyApp, Beta за тканиною (колишні Crashlytics), Test Flight від Apple, Play Console від Google. Звичайно, є більше служб, але вони були обрані як найпопулярніші. Тепер я голосую за тестову консоль Flight and Play, оскільки ці сервіси є гнучкими, підтримуються внутрішні та зовнішні функції тестерів, офіційні послуги від Apple і Google, а також від тестерів потрібна лише електронна пошта. Єдине обмеження тут полягає в тому, що вам потрібен обліковий запис розробника Apple і Google, який коштує 25 $ для Google (одноразовий платіж) і 99 $ для Apple (щорічно).

Інші сервіси, такі як HockeyApp або Beta, мають певні труднощі з додаванням нових тестерів до проекту, особливо на iOS. Зважаючи на безпеку Apple від тестерів, потрібно надати UDID своїх пристроїв розробнику, і розробник повинен додати ці UDID до проекту. Оскільки ми ділимося розробками розробників з нашими клієнтами (які зазвичай мають багато різних пристроїв і регулярно їх змінюють), усі ми втомилися від цієї діяльності з збирання UDID. Ось чому ми обрали тестову консоль Flight and Play.

Для веб-проектів все трохи простіше, оскільки ми використовуємо спеціальне середовище тестування, яке оновлюється інструментом CI при зміні гілки розвитку.

Тестувальна документація

Протягом багатьох років наша команда з контролю якості розібрала чотири найцінніші документи, якими можна поділитися з клієнтами або зацікавленими сторонами:

  • Підтримувані платформи
  • План тесту
  • Випробування / Контрольні списки
  • Примітки до випуску

Підтримуваний документ про платформи повинен бути підготовлений якомога раніше, коли проект починається та підписується з клієнтом. Він повинен містити інформацію про підтримувані конфігурації апаратного та програмного забезпечення, відомі обмеження та обмеження. Він також базується на пристроях цільової аудиторії, оскільки ринки пристроїв у різних країнах різні.

Підписуючи це з нашими клієнтами, ми гарантуємо, що перша версія продукту прекрасно працює над переліченими конфігураціями, до того ж ми повідомляємо клієнтам про те, що продукт може працювати на інших конфігураціях, але можуть з’явитися деякі проблеми. І якщо продукт і цільова аудиторія будуть рости, ми зможемо проаналізувати та впровадити додаткову підтримку платформ. Надалі цей документ дозволить нам зосередитися на визначених платформах у розробці та виправлення.

План тесту також повинен бути підготовлений на початку та поділитися з замовником. Цей документ повинен містити всі типи тестування, які будуть використовуватися при розробці продукту з описаною метою для кожного типу. У плані тестування команда з контролю якості повинна вирішити, що вони використовуватимуть для тестування, тестування чи контрольних списків. Зазвичай це залежить від тривалості проекту та функціональної складності. Підтримувані платформи також повинні бути пов'язані з планом тестування. І, нарешті, план тесту повинен містити інформацію про заплановані тестові дії за датами, що слідують за розробкою проекту та графіком випуску.

Тестові приклади / контрольні списки - обов'язкова річ для кожного проекту. Звичайно, на підготовку цих результатів потрібен певний час, і це може зайняти додатковий час для підтримки цієї документації, але це дає вам якийсь стовбур дерева, і використовуючи цей стовбур, ви можете легко уявити та створити нові сценарії тестування, просто додавши гілки до ваш багажник. Пізніше ви можете поділитися підготовленими тестовими випадками з командою UAT на стороні клієнта або з бета-тестерами або навіть показати тестові випадки команді розробників проекту. Команда розробників може використовувати тестові випадки як частину вимог, і це дійсно може допомогти їм уникнути деяких проблем.

В компанії Effective ми спробували багато TMS (Система управління тестами) і вибрали TestRail як один з найпопулярніших, настроюваних, швидких та зручних інструментів для управління тестовими справами та управління тестами. Використання TestRail дозволяє нам легко оновлювати тестові справи та контрольні списки. Для нас цей інструмент чудово підійде, але альтернативи є ще дуже багато. Основна порада тут - використовувати належну TMS, а також не використовувати Документи та електронні таблиці Google для тестових випадків та тестових журналів :)

Примітки до випуску - це документ, підготовлений нашою командою із забезпечення якості для клієнтів і містить фактичну інформацію про проект. Які функції були виконані в конкретному спринті, що ще триває, які відомі проблеми, де і як можна скласти демо-версію. Ми завжди готуємо нотатки до випуску спринтом та випуском. Це надає нашим клієнтам додаткову прозорість щодо прогресу розвитку.

Дослідницьке тестування

Заключна річ, яку не слід забувати - дослідницьке тестування. Основна мета цього тестування - краще зрозуміти ваш продукт і подивитися на нього з точки зору користувача. Поєднуючи дослідницьке та сценарійне тестування (під сценарієм тестування я маю на увазі тестові випадки або використання контрольних списків), поєднуючи сприйняття продукту тестером та користувачем, пам’ятаючи бізнес-цілі, ви можете зробити продукт, над яким ви працюєте, максимально досконалим.

У рамках дослідницьких випробувань ми також використовуємо підхід до тестування рою. За допомогою тестової консолі Flight and Play ми запрошуємо зовнішніх тестерів, які, як правило, є ефективними працівниками, які не входять у проект і можуть виконувати функції бета-тестерів. Це дозволяє нам оглянути товар з точки зору користувача та звернути увагу на зручність використання.

Підсумок кращих практик щодо забезпечення якості:

  • Розумійте бізнес-цілі
  • Зробити чіткі критерії прийняття
  • Знайте підтримувані вами платформи
  • Підготуйте план тестування
  • Скористайтеся тестовими кейсами / контрольними списками
  • Використовуйте безперервну інтеграцію + безперервне розгортання
  • Оновлення тестових справ / контрольних списків
  • Поділіться нотатками до випуску зі своїми клієнтами
  • Ніколи не забувайте про дослідницьке тестування

Дякуємо за прочитане! Не соромтесь коментувати, якщо хочете дізнатися більше, не погоджуєтесь або маєте якісь питання :)