Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Як за допомогою тестів пришвидшити реліз

Every Company is Now a Tech Company

Привіт! Я Олег і з 2012 року працюю в тестуванні: почав як Manual QA Engineer, але більшу частину кар’єри займаюсь автоматизацією тестування. Веду блог на платформі «Медіум», де пишу нетривіальні статті про тестування українською. Також ви можете знати мене як автора найпопулярнішого коментаря на ДОУ за 2018 рік.

Для мене тестування — це не просто пошук багів і написання тестів. Це процес удосконалення продукту. У цій статті поділюся порадами, як культура розробки, спрямована на якість, у комбінації з комунікацією між учасниками команди та різні типи тестів допоможуть пришвидшити розробку. Або ні. Але мало б допомогти, чесно.

Сьогоднішній бізнес залежить від програмних продуктів. І щоб йти у ногу з часом, розвиватися, компанії мають розвивати свій софт. І бізнес хоче це робити швидко і часто. Двотижневі релізи сьогодні вже неактуальні. Такі гіганти, як Facebook чи Netflix, деплоять на прод по кілька разів на день.

Continuous delivery стає не просто однією з best practices, а важливою бізнес-вимогою. Як таке можливо? Баланс між культурою компанії, комунікацією між учасниками та технічними рішеннями сприяє швидкій розробці нового функціоналу.

Декомпозиція завдань

Завдання, що приходить на розробку, має бути маленьке. Уявімо, що у вас є фіча кошика в онлайн-магазині, на розробку якої йде 5 днів. У Jira ви можете створити одне завдання на 5 днів і працювати над ним. Або ж розділити його на кілька менших. Мені, приміром, не подобається розв’язувати задачі більше як 8-10 годин.

Якщо завдання маленьке, то:

  • оцінювання проходить з мінімальними зусиллями та високою точністю. Що менша задача, то зрозуміліше, що потрібно в ній зробити. У таску на 5 днів ви можете поверхово бачити, що треба виконати, але не врахуєте деталі чи забудете якусь частину. Неодноразово стикався із ситуаціями, коли роботу над фічею оцінювали на три дні, а після розбиття на підзадачі згадали, що треба ще тести або документацію дописати і додали 0.5-1 день. Або навпаки — під час оцінювання задачі на фронтенді дійшли висновку, що спільні компоненти вже реалізовані, і естімейт зменшився з 6 до 2 годин.
  • Відбувається якісніший трекінг прогресу. Команда чітко розуміє, який стан завдання у поточний момент. Якщо є одна задача і вона «висить» три дні у стані in progress, це менш інформативно, ніж те, що робота над двома з п’яти вже завершена. Коли я бачу, що розробник переніс завдання з бекенду в Code Review, розумію, що варто починати оновлювати E2E API тести, фронтенд ще не завершений.
  • Ймовірність, що щось піде не так, зменшується. Менше завдання -> менше розробляти -> менше тестувати -> менше деплоїти. Дрібні зміни простіше тестувати (як вручну, так і автотестами). Краще видно, на що звернути увагу і на що реалізовані зміни можуть вплинути. Отже, локалізувати проблему набагато легше та швидше. Не варто запускати всі тести, а лише ті, які пов’язані з функціоналом, що зазнав змін.

Щоб відповісти на запитання, як саме розбивати завдання, треба спершу зрозуміти контекст команди та проєкту. Мені більше подобається розділяти на бізнес-сценарії, а не технічні процеси: хтось робить фронтенд, а хтось — бекенд. Більше схиляюсь до Full Stack підходу. Тоді зникає проблема комунікацій між FE та BE розробником, коли FE очікує один API, а на бекенді він реалізований по-іншому. Один розробник реалізує API з урахуванням фронтенду краще, бо він його й реалізовує.

Повернемося до прикладу з кошиком в онлайн-магазині. Завдання можна розділити за функціоналом: «Додавання у кошик», «Видалення з кошика», «Оплата», «Очищення кошика». Цей приклад, можливо, банальний, але чудово ілюструє мою ідею.

Головне у цій справі — розбивати завдання на підзавдання, а те, як це зробити, краще визначити самій команді.

Чітке розуміння бізнесу

Ми часто не знаємо, хто наш кінцевий користувач і що йому потрібно. Відповідно, десь докладаємо забагато зусиль. А десь навпаки — не приділяємо уваги тим фічам, якими клієнти активно користуються. Вся команда має розуміти, як люди використовують продукт. Я стикався з ситуацією, коли операції завантаження файлу приділили забагато уваги. І кілька спринтів реалізовували підтримку різних форматів, валідацій, recovery тощо. Але виявилось, що у 99% випадках користувачі обирали лише один формат і перезалити файл для них не було проблемою. Водночас ми не зосередилися на формах, які юзери заповнювали, і в базу потрапляли невалідні дані. Тому:

  • приділяйте увагу всьому бізнеc-процесу, а не конкретним його частинам. Краще швидше реалізувати весь процес, який не працює повністю, ніж одну частину, яка працює ідеально;
  • спілкуйтеся мовою бізнесу. Часто в розмові із замовником чи всередині команди розробники виходять на рівень реалізації і говорять про ендпоїнти, сервіси, репозиторії. Не всім потрібно знати такі деталі. Краще спілкуватись про продукт з погляду користувачів.

Процес тестування

Якщо хочемо релізитись частіше, потрібна впевненість у якості продукту. А для цього треба його протестувати. Новий функціонал, якщо він маленький, можна тестувати вручну. Але оскільки це треба робити на всіх рівнях, на перевірку йтиме все більше й більше часу. Ручні регресії — це дорога в нікуди. Лише баланс тестів на різних рівнях дасть упевненість, що продукт працює так, як очікували.

Автотести — швидкі. Юніт-тести виконуються за секунди, UI можуть одночасно працювати у кількох браузерах і бути відносно швидкими. Вони не йдуть пити каву на кухню, а от ви можете :) Автотести ще й точні: їхнє виконання не змінюється, тест щоразу однаковий, що не завжди скажеш про тест, виконаний вручну.

Хто має тестувати

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

Чому так відбувається:

  • Розробник не розуміє бізнес і тому не знає, як тестувати функціонал. Він чудово знає, як працює код, що у якому класі лежить, які алгоритми використовуються. Але не розуміє продукт з погляду кінцевого користувача. Відповідно й те, як тестувати. І під час імплементації припускається помилок, які ламають бізнес-логіку. Як це вирішити: якщо розробник проводить поверхове тестування, це допомагає краще розуміти бізнес і користувача.
  • Тестування починається до завершення автотестів. Переважно це стосується E2E-тестів, таких як UI, які не запускають після деплою. Як це вирішити: можливо, запускати всі ваші 345 тестів буде зайвим, бо вони виконуються кілька годин. Але якщо вибрати стабільні тести, які покривають основні сценарії та виконуються 10-15 хвилин, то це пришвидшить виявлення дефектів.

Автотести — поняття дуже широке, вони бувають на різних рівнях. Розгляньмо, на яких рівнях і чому треба використовувати тести.

Піраміда тестування

Піраміда тестування — це схема, що розділяє тести за рівнями покриття. З неї ми розуміємо пропорції покриття тестами, час виконання та ціну.

  • Що ширший рівень, то більше тестів потрібно зробити.
  • Ціна підтримки зростає знизу вверх. Ті, що розташовані нижче — дешевші у підтримці.
  • Час виконання падає зверху вниз. Ті, що вище — виконуються довше.

Unit-тести

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

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

Integration-тести

Інтеграційні тести не мають чітких визначень, і навколо них завжди точаться дискусії. Їхня реалізація дуже залежить від системи. У моєму розумінні інтеграційний тест — це white box тест, коли працюємо з кодом системи. Його мета — перевірити взаємодію двох чи більше unit-of-work. Можуть використовуватись зовнішні ресурси: in-memory DB чи щось схоже.

Наприклад, такими тестами можна спробувати тестувати взаємодію DAL та рівня бізнес-логіки. Створюємо фейкову БД для DAL, використовуємо моки для бізнес-логіки і перевіряємо інтеграцію. У всьому іншому ці тести будуть схожі на unit-тести.

Service-тести

У стандартній піраміді тестів цього рівня немає. Unit та integration тести — це white-box тести, тобто вони безпосередньо взаємодіють з кодом. А якщо для тестування підняти лише один сервіс, а не весь продукт, і працювати з ним як з black-box через HTTP чи AMQP? Тоді ми не будемо залежати від сервісу. Потрібно зауважити, що ці тести гарно вписуються у мікросервісну архітектуру, де кожен сервіс незалежний. На жаль, працювати з монолітом буде проблемно, адже підняти лише окрему частину неможливо. У таких тестах легко підставити «фейкові» (спеціально створені для підготовки тестів) ресурси, такі як БД чи Kafka. Наприклад, Kafka піднята у Docker-контейнері чи в окремому хмарному середовищі.

Такі тести не можна використати всюди, але якщо розробляєте мікросервіси чи архітектуру з кількох незалежних або мало залежних сервісів — спробуйте їх. Протестувавши один сервіс ізольовано з фейковими ресурсами, будемо впевненими, що він працює коректно. І якщо так буде з кожним сервісом, можна припустити, що бізнес-логіка працює. Звісно, іноді вилазить проблема — 2 unit tests pass, 1 integration fail. І щоб цього уникнути, є наступні рівні тестів.

Відповідальність за такі тести я б теж покладав на розробників, адже часто компонент чи сервіс є технічним і його нелегко зрозуміти з погляду користувача. Наприклад, коли це Orchestrator Service, що координує роботу кількох сервісів. Його призначення є суто технічним, і без розуміння архітектури неможливо збагнути логіку.

Але також раджу розділяти цю відповідальність з тестувальниками, які проводять рев’ю тестів чи доповнюють їх.

Contract-тести

Чи траплялося у вас, що сервіс, від якого залежите, змінив свій API? Contract-тести запобігають схожим проблемам. Ідея в тому, що в тесті є дві сторони: Provider і Consumer.

Provider — це сервіс, який надає свій API. За допомогою тесту описується контракт — структура HTTP-запиту та відповіді. Consumer — це сервіс чи сервіси, які споживають API від провайдера. Кожен Consumer описує свій контракт. Ці контракти зіставляюся з контрактом провайдера, і, якщо API змінився, тест падає. Такі тести популярні саме у мікросервісних архітектурах. Але підійдуть і системам, де комунікація між компонентами відбувається за допомогою HTTP.

Для реалізації тестів часто використовується фреймворк Packt. У деяких реалізаціях є підтримка не лише HTTP-протоколу, а й AMQP. Якщо у вашій архітектурі провайдер має лише одного споживача, ці тести стають зайвими, бо зусиль на їхню підтримку витрачаєш більше, ніж отримуєш користі. Відповідальність у цьому разі теж за тими, хто пише код.

End-to-end тести

У цю категорію потрапляють тести, що виконують повноцінний сценарій так само, як кінцевий користувач. Переважно тут ми працюємо з системою, яку задеплоїли. Сюди належать як API, так і UI-тести.

Ці тести переважно розробляють і підтримують AQA. Але неправильно покладати на них усю відповідальність. Щонайменше до рев’ю треба залучати розробників, які ознайомлені з тестами та можуть розробляти нові.

Часто на початку проєкту стоїть питання — яку мову програмування обрати? І нерідко є один з двох варіантів: або ту, яку використовував AQA на попередньому проєкті, або ту, якою написаний бекенд. Під час вибору мови програмування потрібно зважати на навички інженерів, які будуть розробляти та підтримувати тести. Якщо розробники готові допомагати з підтримкою E2E-тестів, поцікавтесь, якою мовою їм буде зручніше їх бачити. Не думаю, що Ruby-фахівці будуть дуже раді, що ви почали писати тести на C#. Щоб написати тест чи навіть запустити його, розробникам потрібна буде платформа .NET і Visual Studio. Тому, можливо, краще обрати щось з ближчої до них екосистеми.

Варто по-різному підходити до API-тестів і UI-тестів.

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

За останні роки з’явились нові інструменти для UI-тестування, і WebDriver, можливо, скоро не буде де-факто стандартом для UI-автоматизації. Такі інструменти, як Cypress, Playwright і Puppeteer, завоювали підтримку ком’юніті. Одна з основних переваг — можливість перехоплювати трафік вебзастосунку і змінювати відповіді бекенду. Під час E2E-тестування проблемою стає підготовка та перевикористання тестових даних. Іноді на створення цих даних чи інфраструктури для їхнього автоматичного створення йшло більше часу, ніж на сам тест. Тому можливість змінювати відповідь бекенду допоможе мінімізувати цю проблему. Звісно, не варто цим зловживати, пам’ятайте, що у вас мають бути тести й зі всіма реальними компонентами.

Антипатерни AQA

Тести, що цікаві лише автоматизаторам. Пам’ятаєте бородаті анекдоти про сисадмінів, котрі щось роблять, але ніхто не знає що? Часто AQA стають такими. Вони працюють окремо від команди, пишуть якісь свої тести, самі їх запускають, самі фіксять, і результат нікому не цікавий. Це велика проблема. Тести повинні допомагати всім учасникам команди. Насамперед розробникам.

Уся команда має знати про тести: які вони, де їх знайти, як запустити й де переглянути результат. Це мінімум.

Тести, створені окремо від функціоналу. Мені не подобаються фрази у стилі «у нас автотести відстають від продукту, бо все може змінитись». Якщо все може змінитись, то, може, не варто писати код чи тестувати? Тести треба створювати разом із функціоналом. І важливо, щоб їх можна було легко модифікувати. У такому разі, навіть якщо щось зміниться із часом — це буде легко оновити.

Багато нестабільних тестів. Часто показником є кількісна характеристика, а не якісна. І якщо у вас є 345 тестів і при кожному запуску більша частина з них падає через нестабільність — вигода від автоматизації сумнівна. Краще мати набагато меншу кількість тестів, але стабільних на 99%. Нестабільні тести — це гірше, ніж відсутність тестів, тому що з часом їм перестануть довіряти та заб’ють на них.

Гігантські сценарії. Не варто створювати автотест на десятки кроків. Особливо це стосується UI-тестів, що покривають рідкісний сценарій. Великий тест важко підтримувати, він буває нестабільний і довго виконується. Уникайте таких тестів або оптимізуйте їх за допомогою API чи БД.

Аутсорсинг тест-кейсів. Не варто аутсорсити написання тест-кейсів Manual QA. Це може призвести до того, що ви не будете розуміти бізнес-логіку і писатимете неефективні тести, бо людина, яка писала цей тест-кейс, не знає, як працює автоматизація.

Best practices AQA

Я вважаю, що автоматизація тестування пришвидшує розробку. Але щоб цього добитись, потрібно уникати антипатернів. Натомість варто:

  • приєднати AQA в команду і залучати до всіх активностей;
  • долучати розробників і тестувальників до розробки автотестів. Щонайменше для рев’ю, а краще і до написання нових;
  • не робити 100% покриття коду чи вимог;
  • писати швидкі та стабільні тести;
  • покривати функціонал тестами одразу.

Summary

У цій статті я хотів поділитись досвідом, як наскрізне тестування може поліпшити процес розробки. Не очікуйте, що воно одразу збільшить кількість story point’ів, які ви закриваєте за спринт. Це інвестиція у майбутнє.

На початку впровадження цих змін виникне багато проблем — як технічних, так і людських. Людям складно змінювати погляди, особливо якщо раніше вони не інвестували в тестування. Будьте готові до опору.

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

Отже, найголовніше:

  • Комунікуйте та спілкуйтесь. Залучайте всіх членів команди до релевантних для них дискусій.
  • Пишіть тести.
  • Запускайте ці тести часто.
  • Обмінюйтесь обов’язками та розділяйте відповідальність.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному10
LinkedIn

Схожі статті




30 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Як завжди класна стаття. Плюс, доволі конкретна і без зайвої води.

як саме компанії, які пишуть «з юніт-тестами» мотивують команду писати їх ? Замовника теж треба мотивувати

Компании не пишут «с юнит-тестами» и не должны мотивировать программистов. Все наоборот.

Юнит-тесты — это сугубо внутрення кухня программистов, которая напрямую не должна заботить никого кроме самих программистов. Когда ты нанимаешь хороших строителей, ты не предлагаешь им не носить каски и перчатки, чтобы у тебя был ниже прайс. Это часть их рабочего процесса и безопасности, которая не обсуждается.

Если мне, как инженеру, нужно реализовать логику, и я планирую разбить её на 5 функций и покрыть их юнит-тестами, то это мое личное дело и дело моих коллег-инженеров, с которыми я буду обсуждать это решение во время планирования и код-ревью. Я не буду идти к заказчику или менеджеру и справляться о том, сколько я должен был написать функций и юнит-тестов. Это детский сад — меня наняли, чтобы я отвечал на эти вопросы, а не наоборот.

Касательно оценки. На код-ревью уходит функционал + юнит-тесты, которые должны пройти на CI. Соотвественно, юнит-тесты — это часть общего изменения и оцениваются они как часть реализации.

Оценка будет зависеть от множества факторов. С грамотно построенной архитектурой, чётким разделением ответственности, отделением бизнес-логики в чистых функциях от побочных эффектов — юнит-тестирование не вызывает никаких проблем и занимает не более 20% времени.

Но на практике я никогда не думаю об оценке юнит-тестов в процентном соотношении к реализации, потому что я не рассматриваю их как два независимых куска работы.

Для оценки задачи я просто проговариваю то, сколько примерно будет добавлено новых сущностей, функций, тестов и т.д. Если это неизвестно, то задача не готова к оценке и нужно возвращаться к исследованию.

Понятно, что всё это не относится к мелким аутсорсным халтуркам, типа убийцы убера за 10к баксов. Там заказчик — великий царь, который лучше программистов знает как разрабатывать софт, а юнит-тесты — это проценты, которые PM «продаёт» царю.

Отличная статья! Очень сильно откликается с моим видением процесса.
Хотел только уточнить по пункту

не робити 100% покриття коду чи вимог;

— почему так ? )

100% покриття коду не гарантує те, що все покрито. Рядки коду то покриті, а чи всі вхідні дані ?
Для кінцевих користувачів без різниці скільки і які у вас тести. Тому, краще зосередитись на основних та критичних бізнес сценаріях

Так покриття коду тестами та покриття вимог це різні речі.
Вимоги покрити на 100% більш можливо ніж на 100% код.
Але звісно, залежить від того як саме будуть покриті ті вимоги
Але все одно, вимог то менше ніж вхідних даних на кожну стрічку коду 😉

приєднати AQA в команду і залучати до всіх активностей;

Все пишут давайте мануальщиков приучим к автоматизации, наконец-то нашелся кто-то кто сказал давайте автоматизаторов сделаем мануальщиками.

Я вообще считаю, что деления на мануальщиков и автоматизаторов быть не должно. Есть тестировщик, он должен по максимуму обеспечить тестирование продукта. Если для этого лучше писать автотесты, то он их пишет, если проще и быстрее руками — значит руками.

Если человек не может даже автотесты писать (не говорю о качественном фреймворке) то это просто профнепригодность.

1) не з автоматизаторів зробити мануальщиків, а залучати до командних активностей типу планування і тому подібне. Не раз стикався з тим, що автомейшини живуть дуже окремо, у своєму власному світі
2) взагалі, оцей поділ на мануальщиків та автомейшинів шлях в нікуди. Тестувальник повинен вміти і потестити руками, і написати код. Нажаль, так не є, але варто йти цим шляхом.
3) дуже підтримую розширення відповідальностей. Дев має не лише написати код, він повинен вміти і тестувати. Тестувальник також, має вміти не лише тестувати

Мені здається, що Митець цю тему давно закрив у свєму епічному творі...

трохи не зрозумів, до якого саме твору йде відсилка ? і якої цитати ?

Ми для натхнення оце з майбутнім кумом у Вегасі на об’єкті слухали, коли дебажили керування моторами напередодні демки для представників замовника. А вони там пацани трохи конкретні...

Входять Гаврюша Обізянов і Степан Срака, поглиблені в свої інженерні папки і розрахунки. 
Вони зайобані і закомплексовані.

Гаврюша Обізянов. По нашим даним, якщо будівництво не наєбнеться зараз – воно обов’язково наєбнеться в наступному кварталі.
Степан Срака (налякано). І шо тогда будєт, Гаврюша?
Гаврюша Обізянов (спльовує). Тюрма на хуй!
воно обов’язково наєбнеться в наступному кварталі

власне, ось ці всі тести допомагають відтермінувати наступний квартал

Я б сказав, що вони допоможуть оцінити, чи готуватися до тюрми.

Завжди цікавило, як саме компанії, які пишуть «з юніт-тестами» мотивують команду писати їх ? Замовника теж треба мотивувати, а йому ж, аби дешевше вийшло. Програмісти хочуть писати «як можуть», а не так щоб їх класи були придатні для юніт-тестування. Не можна взяти просто будь-який проект та написати тести — скоріше за все там буде все занадто погано. З цим треба жити з початку. Ну, або взяти велику палку, усіх ...., гноблення, страждання, щоб усі писали юніт-тести та інші, не лінувалися. На додачу тех.документацію теж щоб писали.

аби дешевше вийшло

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

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

Это правда научно-теоретическая. А вот правда жизни:

1. Заказчику пофиг, что будет через полгода-год. Потому что это не собственник, а наемный менеджер со своими KPI. Чтобы получить премию и повышение, ему нужно выполнить план сейчас, а не через год. Поэтому он сделает все, чтобы выполнить краткосрочые задачи в ущерб долгосрочным. Через полгода-год он уже может получить повышение, уйти из компании или перейти на другой проект (и это станет проблемой кого-то другого), закрыть проект, увеличить бюджет проекту и т.д.. В конце-концов, при удобном случае он свалит проблему качества на команду девелоперов и тестировщиков. Поэтому ему плевать, что будет через год, если он не выполнит то, что нужно на ближайший период. И все желающие писать юнит-тесты в ущерб фичам быстро построятся и пойдут известной дорогой

2. Заказчик уже заплатил за юнит-тесты и включил их в контракт. Но ради повышения маржинальности проекта, проектный менеджер выделил меньше людей, чем нужно для этого. Или нанял джунов вместо обещанных синьоров. А фича деливери план прописан в контракте.

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

Юніти-тести пишуть системні програмісти для якоїсь критичної інфраструктури. Їх не треба мотивувати.

Далі все йде від інтеграційних тестів. Те, що валиться, покривається тесткейсами. І так ітерацйно з гори до низу.

Це з мого досвіду.

тут скорее идеологический подход команды (читай тимлида или дев отдела в целом) : время на написание юнит тестов заложено в разработку. и все. Заказчик аксептит время — и если оно его устраивает, то остальное вопрос уже 3ий. Юнит тесты это прежде всего ДЛЯ РАЗРАБОТЧИКОВ, для их уверенности в заврашнем дне (в плане работы имплементации) и для тимлидов — дабы быть уверенным что новый разраб на проекте не сможет задеплоить, если логика будет сломана после его правок (во всяком случае вероятность этого дела возрастает прямо пропорционально качественному написанию юнит тестов...можно же и такие тесты написать, что все будет работать несмотря ни на что:) ).

Добре, скільки на ваш погляд треба «закладати» часу на тести? Як це у ваші практиці — ну , наприклад: обміркували що просто написати 6 міс, а якщо з тестами (вважаємо покриття коду 80%, юніт та інтеграційні, та скоріше за все UI ?) - це буде скільки додати ? +100% ?

если говорить о юнит, то допустим прилетает тикет разрабу — он должен понимать что реализация 80-85% импл логики и 15-20% тесты. Как показывает практика, чем лучше прогр пишет (чистый код с точки зрения граммотности) тем лучше он вписывается в это 15-20%. Чем топортнее разраб тем больше у него времени на тестирование уходит (сюда особенно показательно вписываются любители методов на 100 условных строк). Если говорить про интеграционные — это отдельная парафия, и хорошо бы их не рассматрить с точки зрения работы программиста при имл фичи — их хорошо рассматривать отдельной работы и они прямопропорциональны сложности выбранной логики и кол-во сценариев (интерграционными тестами по хорошему должен заниматься вообще другой человек) — это как раз и есть работа для AQA+DevOps на интересные нетривиальные кейсы в ходе пользовательского тестирования. Еще не стоит забывает про АПИ и лоад тесты — их можно и разрабу поручить — это как показатель стабильности работы кода, особенно последние — порой ребята совсем не задумываются как бд будет рыгать на кучу неоптимизированных запросов и даже немного усложненная кверя может дать значительный просак на уровне 100юзеров допустим. В моей практике хорошая импл получается когда разраб при разработке пишет юниты, покрывает АПИ кейсы (это можно и покрыв контроллер слой, или банально в постмане наколотить коллекцию с тестами), и делает допустим каким то jmeter ом нагрузочное тестирование, и к тикету прикладывает результаты — на ревью все это барахло видно, тогда есть более менее реальный шанс, что если баги и будут зарепорчены, то только в профтыке или недопонимания по реализации бизнес-логики, но не корявости импл.

Вот тут, как правило, кроется противоречие:

писати швидкі та стабільні тести;
покривати функціонал тестами одразу.

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

Куда важнее, как заказчик будет работать с вашей командой. Если у него план зарелизить Х фич в срок и пофиг, что с багами, лишь бы не с критическими, то ни коммуникация с девелоперами ни идеальные фреймворки не помогут.

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

Таки согласен с автором, если поднапрячься и сделать нормальную основу для тестов, никаких противоречий не будет.

Какой фреймворк вам поможет, если функционал релизится с дефектами, влияющими на автоматизацию или с мыслью о том, что мачурити фичей будем занимать позже?

если функционал релизится с дефектами, влияющими на автоматизацию или с мыслью о том, что мачурити фичей будем занимать позже

то страдать. Если заказчик очень хочет трудноподдерживаемое говно — он его получает. Если трудноподдерживаемое говно получилось по вине манагеров которые не смогли в планирование, программистов, которые накодили такого что потом х10 времени на багофикс потратили и надо релизить хоть что-то, тестировщиков, которые не смогли в тестирование и

функционал с дефектами, влияющими на автоматизацию

всплывает в последний момент, когда фиксить его уже больно и некогда, то остается только страдать. Да, тестировщикам после всего этого придется страдать из-за трудностей и объемов регрессионного тестирования. Но такова жизнь. Поэтому

делай хорошо, и все будет хорошо. А если сделал плохо — исправь чтобы было хорошо и дальше делай хорошо

Підписатись на коментарі