Як обговорювати тестові завдання в англійській мові

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

Ключовий словник

** Покриття коду ** — метрика, що описує відсоток рядків коду, гілок або функцій, виконаних пакетом тестів, використовується як приблизний показник того, наскільки багато коду використовується тестами. “Покриття кодом становить 78%, але ця цифра приховує значні прогалини в нашому модулі обробки платежу.”

** Критичний шлях ** — основна послідовність функціональних можливостей, які повинні працювати правильно для того, щоб система виконувала свою основну мету, пріоритет для тестування незалежно від загальних кількостей покриття. “Навіть при 100% покритті в інших місцях, ми розглядаємо критичний шлях вилучення як вимагає як тестування блоків, так і тестування від початку до кінця, без винятків.”

** Піраміда тестів ** — модель, яка описує рекомендовану пропорцію типів тестів у здоровому наборі: багато швидких тестів модулів, менше тестів інтеграції і невелика кількість повільних тестів end- to- end. “Наша піраміда тестування зараз перевернута — у нас набагато більше крихких тестів end-to-end, ніж тестів модулів, тому набір є повільним і нестабільним.”

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

** Флакі тест ** — тест, який проходить і провалюється непослідовно без будь- яких змін до основного коду, підриває довіру до тестового набору в цілому. “Ми не додаватимемо нових можливостей до цього модуля, поки не виправимо вже існуючі там неякісні тести — неякісний набір є гіршим, ніж жодного набору.”

** Регресійний тест ** — тест, написаний спеціально для підтвердження того, що раніше виправлена вада не з’ явиться знову у майбутніх змінах. “Кожен виправлений вада у цьому сховищі потребує супутнього регресійного тестування перед об’ єднанням — без винятків.”

** Тестування на основі ризику ** — стратегія тестування, яка визначає пріоритетність тестування на основі ймовірності і впливу невдачі, а не націлена на однорідне покриття по всій кодовій базі. “Ми приймаємо тестування, засноване на ризику - служба розрахунків отримує ретельне покриття, в той час як внутрішній інструмент адміністрування отримує легше тестування, враховуючи його нижчий радіус вибуху.”

Звичайні фрази

• «Не будемо розглядати відсоток покриття як саму мету — це проксі, і помилкове.»
• «Цей модуль знаходиться на критичному шляху, тому йому потрібна більша кількість тестів, незалежно від загальних цілей»
• «У нас є реальний прогал покриття тут, а не просто низька кількість — ніхто не підтвердив сценарії невдачі»
• «Листкові тести розмивають довіру до набору; давайте стабілізуємося, перш ніж додавати більше»
• «Я б скоріше поставив мету, засновану на ризику, ніж загальну вимогу 80% покриття по всій службі»
• «Давайте додамо регресійний тест для цієї конкретної помилки, перш ніж ми закриємо квиток»

Приклади висловлювань

Як запропонувати ціль покриття на груповій нараді:

• “Замість того, щоб наказувати 90% покриття скрізь, я б запропонував підхід, заснований на ризику: 90% або більше на платіжному і автентифікаційному коді, і нижчий, більш гнучкий бар для внутрішніх інструментів. Це зосереджує наші зусилля з тестування, де невдача насправді зашкодить нам.”*

Пояснення прогалини в покритті менеджеру:

• “Наша загальна кількість покриття виглядає здоровою на рівні 82%, але це середнє значення є вводячим у оману — воно приховує справжній прогалину у тому, як ми тестуємо помилки і повторюємо логіку. Я б хотів приоритизувати заповнення цього прогалини, перш ніж ми додамо покриття в інших місцях, оскільки це область більшого ризику. ”*

Відкидання пакету тестів flaky: “Перед тим, як ми вкладемо кошти в подальшу розширення покриття, я думаю, нам потрібно вирішити проблему нерівності в нашому існуючому пакеті. В даний час, близько 15% тестових запусків не вдається з причин, не пов’язаних з фактичними змінами коду, що означає, що команда почала ігнорувати невдачі - це більший ризик, ніж будь-який прогалину покриття. “

Професійні поради

• Не слід розглядати ** код покриття ** як єдиний значуще число в ізоляції - завжди парувати його з частинами кодової бази, які насправді покриті, оскільки 80% покриття концентрується в коді низького ризику набагато менш цінним, ніж 60% концентрується на критичний шлях.
• Використовуйте “критичний шлях”, щоб обґрунтувати вищу позначку тестування для конкретного коду, а не стверджувати про однорідно високе покриття по всій базі коду - це більш переконливо і ресурсоефективніше.
• Підніміть ** тріщини тестування ** як проблему довіри, а не просто технічне дратування — набір команди не довіряє забезпечує менш реальний захист, ніж менший, надійний.
• Рамки тестування стратегії розмови навколо ** тестування, засноване на ризику ** при обговоренні пріоритетів з менеджером або власником продукту - це переформатує обговорення з “скільки тестування” до “де тестування має найбільше значення”

Практичні вправи

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

Розширення вашого словника: адресування цілей покриття з точністю

Раніше ми досліджували, як ефективно обговорювати цілі тестування з вашою командою - зосереджуючись на ясності, контексті і спільному розумінні того, як виглядає «хороший». Але для розробників, які вивчають професійну англійську, особливо тих, чия перша мова не є англійською, нюанси виражання цих ідей можуть бути викликом. Це не просто про те, що ви хочете 80% покриття; це про те, щоб сформулювати * чому * ця цифра важлива і як вона пов’язана зі зменшенням ризику, підтримкою і загальною якістю продукту. Давайте розглянемо деякі специфічні слова та фрази, призначені для людей, для яких мова не є рідною, зосередившись на практичних сценаріях, з якими ви можете зіткнутися під час перегляду коду або обговорення команди.

Поширена пастка - це використання надто нечітких термінів. Замість того, щоб просто сказати: «Ми потребуємо більше тестів», розгляньте можливість обмежити їх вимірюваними цілями. Наприклад, під час опису запитів на витягування для нової можливості ви можете сказати: « Ця PR має на меті досягти 75% покриття рядків у основній логіці потоку автентифікації користувача, з пріоритетом на тести, які покривають критичні шляхи і краї випадків, визначені у нашій оцінці ризиків. » Зауважте використання « покриття рядків » — стандартної метрики — поряд з обґрунтуванням, заснованим на попередній оцінці. Іншою корисною фразою є «граничні умови», які при правильному використанні можуть уникнути плутанини навколо дизайну тесту. Сказати «ми повинні перевірити межові умови» може бути дуже по-різному інтерпретовано різними людьми. Замість цього ви можете сказати: « Давайте переконаємося, що у нас є тести, які охоплюють нижню і верхню межі вхідних параметрів, а також неправильні вхідні дані ». Цей варіант є більш точним і звертає увагу на певну техніку тестування.

Крім того, вивчення того, як ввічливо відкидати надто амбітні цілі охочення, має вирішальне значення. Якщо старший інженер пропонує 95% покриття для невеликого модуля, ви можете відповісти: « Це цікава мета! Можемо ми обговорити компроміс між досягненням такого рівня покриття і зосередженістю наших зусиль на тестах, які демонстративно зменшують найвищі ризики, пов’язані з цим компонентом? Можливо, ми можемо визначити пріоритети тестових випадків на основі матриці ризиків. ” Цей підхід визнає пропозицію, одночасно підкреслюючи розмову до більш прагматичної оцінки. Уникайте фраз на кшталт «Це занадто високо!», оскільки вони можуть звучати відверто. Замість цього, зосередьтеся на тому, чому це може бути складним або менш ефективним. Пам’ятайте, що демонстрація впевненості у своєму розумінні принципів тестування є ключем.

І, нарешті, не вагайтеся попросити про пояснення. Якщо ви не впевнені у використанні терміну, наприклад, « покритий гілка », ввічливо запитайте про пояснення: « Чи можете ви розібратися, що означає « покритий гілка » у цьому контексті? Я хочу переконатися, що я повністю розумію, як це пов’язано з нашою стратегією тестування. ” Показувати готовність навчатися і роз’яснювати непорозуміння високо цінується в будь-якому професійному середовищі. Це цілком прийнятно, навіть заохочується, щоб запитати про приклади ефективних тестових випадків, які збігаються з бажаною метрикою покриття.