Залишаючи навмисні помилки в коді, щоб тестери могли знайти

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

1. Незадовго до того, як продукт перейде до якості, команда розробників додає деякі навмисні помилки у випадкових місцях у коді. Вони належним чином створюють резервну копію оригінального, робочого коду, щоб переконатися, що ці помилки не постачаються разом із кінцевим продуктом.
2. Про це також повідомляють тестери. Тож вони будуть важко перевірятись, бо знають, що є помилки, і що їх виявлення може вважатися ознакою некомпетентності.
3. Якщо помилка (навмисна чи інша) виявлена, про них буде повідомлено команду розробників, яку потрібно виправити. Потім команда розробників додає ще одну навмисну ​​помилку у відповідний розділ коду перед тим, як продукт перейде до QA другого рівня. Керівник проекту каже, що тестер повинен думати як розробник, і він / вона повинен очікувати нових помилок у розділах, де були внесені зміни.

Ну, так воно і йде. Вони кажуть, що такий підхід має такі переваги.

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

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

Деякі роз’яснення:

1. Вони належним чином створюють резервну копію оригінального коду в керуванні джерелом.
2. Коли тестер виявляє навмисну ​​помилку, команда розробників просто ігнорує її. Якщо тестер виявить ненавмисну ​​(оригінальну) помилку, команда розробника спочатку перевіряє, чи викликана вона якоюсь із навмисних помилок. Тобто команда розробників спочатку намагається відтворити це на початковому робочому коді та намагається виправити це, якщо зможе.
3. Просто ігноруйте питання взаємозв'язку між QA та командою розвитку. Я спеціально задав це питання програмістам , а не на робочому місці . Вважайте, що між QA та командою розробників є хороше взаємозв’язок, і вони проводять спільну вечірку після робочого часу. Керівник проекту - це приємний, старий джентльмен, який завжди готовий підтримати обидві команди (Godsend).

Це звучить абсолютно горіхово. Він витрачає багато зусиль на дуже сумнівну користь, і практика, здається, ґрунтується на деяких несправних приміщеннях:

• Цей QA не буде працювати важко, якщо вони не знають, що їх перевіряють щодня (що не може бути корисним для моралі)

• Що в програмному забезпеченні для QA недостатньо ненавмисних введених помилок

• Завдання QA полягає у пошуку помилок - це не так; це забезпечити якість програмного забезпечення

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

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

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

Ну, виходячи з того, що я дізнався:

1. Це не співбесіда чи школа;
2. Тестери не діти;
3. Це не гра;
4. Це витрачає гроші компанії.

QA не тільки для того, щоб знайти помилки, а й турбуватися про те, наскільки інтуїтивно зрозуміла система, яка крива навчання для користувача, зручність використання та доступність загалом. Наприклад: "Чи неприємна система ?", "Чи користувач сліпий, а кольори - червоний і зелений?" Вони також повинні скаржитися.

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

тл; д-р

Це не лише помилки, тестери повинні виростати з цього вузького зору.

Погана ідея.

З точки зору тестера: "Отже, вони будуть важко перевірятись, бо знають, що є помилки, і якщо їх не знайти, це може вважатися їх некомпетентністю". В основному, розробки заграють код. Мало кому подобається виконувати роботу, яка в кінцевому рахунку є безглуздою (бо помилки відомі заздалегідь), але все одно впливає на їх сприйняття. Якщо є відчутні покарання за те, що вони не знаходяться в пастках, - тим більше. А чи знаєте ви, що тестери процвітають у пошуку помилок? Це звучить як токсичне конфронтаційне середовище; QA повинен бути задоволений, якщо код, який вони вивчають, є високоякісним. Хоча якщо їх оплатить помилка ... http://thedailywtf.com/articles/The-Defect-Black-Market

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

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

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

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

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

3. Я б міг уявити, що це просто навчає ваших тестерів мислити, як ваші розробники (тобто як Том додав би помилку), що, ймовірно, робить їх менш ймовірними знайти помилки, про які Том не думав.

Редагувати

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

Завершити редагування

Існує поважна причина перевірити, чи тестування / перевірка справді працює. Дозвольте навести приклад з виготовлення, але принцип той же.

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

Тепер ви повинні подумати про те, як сам тест може вийти з ладу. Наприклад, деяка кількість бруду або іншого сміття може заблокувати датчик, і він завжди повідомляє "ОК" і ніколи не зупиняє машину. Також характер датчика полягає в тому, що приймач включається, коли промінь потрапляє на нього, тому залежно від типу встановленого датчика, електрично ви отримуєте вхід "ВКЛ", коли датчик не заблокований . Це означає, що якщо кабель був розірваний або втрачено живлення цього датчика, або вхід не вдався, логіка вашої програми буде читати "OFF", і це означатиме "заблоковано" або "ОК".

Щоб зафіксувати ці режими відмов у тесті, ми зазвичай вставляємо другу перевірку, щоб переконатися, що датчик насправді розблокований протягом другої частини циклу. Таким чином ми перевіряємо, що тест насправді все ще працює (якнайкраще).

Аналогічно, існує багато способів відмови QA-відділу. Можливо, автоматичні тести не запускалися, і звіт переглядає стару копію даних тесту. Можливо, хтось не робить свою роботу правильно. Тестування відділу контролю якості - справа розумна.

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

Чесно кажучи, я б назвав цю поведінку відверто неетичною та непрактичною. Прем'єр-міністру потрібна серйозна перекваліфікація, якщо не припинення.

• Це демонструє принципове нерозуміння поняття забезпечення якості . Тестери не повинні думати як розробники: вони повинні думати як кінцеві користувачі. Вся причина у наявності QA-команд полягає в тому, що розробники за своєю суттю занадто близькі до коду; QA повинен підтримувати достатню відстань від коду, щоб вони могли зловити те, що пропустили чорти.
• Це витрачає зусилля з забезпечення якості . Якщо припустити, що ці помилки не банальні - дивіться нижче, коли вони є - це означає, що QA витрачає час і ресурси на дослідження вже відомих речей, коли вони могли витратити ці зусилля на пошук того, що не відомо.
• Це витрачає зусилля розробника . Щоб QA люди могли ловити ці нетривіальні помилки, розробники повинні спочатку їх записати. Для цього потрібні додаткові зусилля, витрачені не просто на кодування помилок, а й на розгляд програмних вимог та дизайну.
• Це наражає виробництво на непотрібний ризик . Лише питання часу, поки зміни не злиються належним чином.
• Якщо він не робить вищезазначене, то це безглуздо . Якщо всі відомі помилки тривіальні, вони не зловить нестандартних працівників: вони будуть ловити лише людей, які взагалі не працюють. Є кращі способи зробити це.
• Це отруює робоче середовище . Ваші тестувальники якості - професіонали. Вони повинні бути довірено бути професіоналом , поки не актуальна причина підозрювати інакше. Коли є підстави підозрювати інакше, замість цих ігор з розумом має бути належне розслідування. Все інше вбиває мораль.

Серйозно. Навіть якщо параноя прем'єр-міністра виявиться обґрунтованою в даному конкретному випадку, це не той, хто має будь-який бізнес, який керує тестерами.

Особисто я відчуваю себе незручно з таким підходом.

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

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

Крім того, тестер витратить багато часу на тестування коду, який насправді не випускається. Як тільки навмисні помилки будуть видалені, все-таки слід зробити повний повторний тест, на мою думку. У цьому вся суть тестування. Що - то змінюється, що - небудь , і ви повторно перевірити всі . Гаразд, я знаю, що це ніколи не відбувається на практиці, але це те, що регресійне тестування.

Отже, загалом, не переконаний.

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

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

Скажімо, у найпростішому випадку ви посилаєте 100 помилок і вони є представником повного діапазону реальних помилок (я знаю, навряд чи, але я спрощую). Ви не кажете QA, що ви це робите, щоб не зіпсувати експеримент. Наприкінці процесу контролю якості скажімо, що вони знайшли 60 із 100 посіяних помилок (та інших реальних помилок). Тепер ви знаєте, що QA знаходить 60% помилок.

Ви можете продовжити це, підрахувавши кількість знайдених справжніх помилок QA та застосувавши число підроблених помилок. У нашому прикладі, якщо QA знайшов 200 справжніх помилок, то можна зробити висновок, що їх було знайдено лише 60%, тому залишається 133.

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

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

Це показник , і його не слід захоплювати як мотиваційний інструмент управління.

Погана ідея.

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

Такий спосіб мислення поєднує в собі те, що QE - це лише ручні тестери, не мотивовані зрозуміти фактичний код, що перевіряється.

Я старший QE, і це звичне питання в більшості організацій, в яких я працював.

Я б сказав погана ідея.

Перший: Програмісти збираються витрачати час на введення навмисних помилок у код та певні зусилля, щоб зберегти хорошу версію. Хоча, мабуть, тестувальники повинні тестувати все, включаючи функції із посадженою помилкою, коли вони знайдуть її, вони, ймовірно, повинні будуть повернутися та повторно запустити тест, щоб перевірити, чи справді це помилка (а не тестер, що тестер заплутався якимось чином). Як мінімум, тестери збираються витрачати час на написання посаджених клопів. Тоді програмістам доводиться витрачати час на виправлення помилки, яку вони посадили. Це багато зусиль, які можна витратити, намагаючись написати хороший код і написати справжні помилки.

Друге: воно надсилає чітке повідомлення тестерам, що програмісти та / або керівництво думають, що вони не виконують свою роботу, і до них треба ставитися як до дітей. Я не уявляю, що це добре для моралі. Як програміст, якщо мені дали неоднозначні чи суперечливі характеристики для програми і довелося витратити купу часу на їх роз'яснення, а потім, витрачаючи години чи дні, мій начальник сказав мені: "О так, я навмисно викладаю суперечливі твердження в характеристики просто для того, щоб переконатися, що ти їх справді читаєш ", я думаю, я був би дуже роздратований. Якщо це траплялося регулярно, це може бути достатньо, щоб змусити мене шукати іншу роботу.

У реальному житті всі помилки, окрім самих тривіальних змін, БУДУТЬ помилки. У мене ніколи не було проблем із тестуваннями тестувальників, тому що перший проект коду, який їм дали, був настільки часто 100% ідеальний. Мені доводилося стикатися з ледачими тестерами, які не роблять адекватної роботи, але їм це не вдалося, тому що програмісти були такими досконалими. Найкращий тестуючий чоловік, з яким я коли-небудь працював, одного разу сказав мені, що для нового випуску програмного забезпечення він поставив собі особисту мету знайти 100 помилок. Гаразд, чи 100 є реалістичним числом, залежить від того, наскільки великий продукт і наскільки масштабні зміни, але в нашому випадку він майже завжди вдавався досягти цієї мети. Іноді йому доводилося розтягувати речі, як-от називати неправильно написане слово в повідомленні «помилка», але ей, це все-таки потрібно було виправити.

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

Я не вважаю це поганою ідеєю. Існує дуже багато речей, над якими я б міркував, що краще працювати:

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

2. Майте кілька команд з якості, які можуть змагатися. Вам, звичайно, потрібно знайти розумну метрику. Однозначно не просто кількість випусків. Фактор врахування ступеня вираженості дефекту або ділової цінності запропонованих удосконалень (як визначено зацікавленими сторонами) повинен допомогти.

Важко сказати, чи QA "достатньо хороший". У довгостроковій перспективі простіше і, можливо, ще краще знайти шляхи, щоб QA "постійно покращувався".

Тим не менш, слід пам’ятати про одне питання, якщо ви вводите навмисні помилки: як ви знаєте, що «правильний» код коли-небудь насправді був правильним в першу чергу? Після 2-ї якості ви видаляєте всі навмисні помилки, які не були виявлені. Немає способу знати, що ви не просто заміняєте їх кодом, який порушено іншим чином, або що ви не вмикаєте порушену поведінку, яка раніше була недосяжна (перебільшений приклад: деякий діалог не відкривався через навмисну ​​помилку, але діалогове вікно порушено - ви просто не дізнаєтесь, оскільки тестери не змогли його побачити).

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

Це називається тестуванням на мутацію . Ідея полягає у використанні програмного забезпечення для автоматизації створення невеликих змін у вихідному коді (звані мутантами). Зміни покликані створити різну поведінку, наприклад, ми могли б змінитися

if x < 10:
    print "X is small!"

в

# we flipped the inequality operator
if x > 10:
    print "X is small!"

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

Мені подобається ідея. Невже генерал Паттон сказав: "Чим більше ти потієш у мирі, тим менше кровоточиш у війні".

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

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

Крім того, ви можете отримати уявлення про те, наскільки хороші ваші тестери, що не є малою користю.

Існує не підстава для винагороди чи покарання за власними заслугами, а за результатами поведінки, на яку ви орієнтуєтесь. І іноді бувають ненавмисні наслідки. Це мета, щоб утримати команду QA від розмахування чи змусити когось із менеджерів відчути, що він насправді щось сприяє, не розуміючи, що він просто заважає.

Позитивний результат - Команда QA працює більше, щоб знайти помилки. Хтозна, може, вони бачать це як виклик. Це товариська гра. Або вони просто роблять, бо за ними спостерігають (ефект Хоторна?).

Негативний результат - Вони, можливо, не працюватимуть більше і виявлять помилку. QA розглядає це як дрібну та змагальну. Тож зараз вони переходять до пошуку приводу гіпер-помилок і повертають всілякі дріб'язкові проблеми. Цей шрифт не відображається належним чином, коли я знімаю екран і перетворюю його у формат PDF та переглядаю його на 500%.

No Impact - звук для мене так не має ніякого значення, то чому б це турбувати? Ви просто ризикуєте витрачати час і дратувати людей.

Ми всі могли погодитися, що це не спрацює 90% часу. Це не приносить користі для інших 10%. Перевірте речі на собі. Чи задоволені клієнти випуском, який містить навмисні помилки коду? Чи впливає це на мораль працівників та продуктивність праці в інших сферах? Збільшити оборот? Ви нам кажете.

Виходячи із світу, де розробники очікують, що вони самі писатимуть і запускатимуть тести, цей «тестуючий» «QA» силос, який ви посилаєтесь, лякає і бентежить мене, тому я спробую відповісти з цієї точки зору. Як осторонь, кваліфіковані інженери із забезпечення якості, з моєї точки зору, (як це добре описано у відповіді @ SparK), повинні зосередитись на більш важливих питаннях забезпечення впевненості, що програмне забезпечення повністю задовольняє історії користувачів та має загальну "якість" (стосовно домен, для якого призначене програмне забезпечення), а не полювання на помилок.

Що мене сюди привернуло, - згадка @ JamesMcleod про "ін'єкцію дефектів" у коментарях до цього питання. Насправді я думаю, що розробники думають, як вони могли б вводити помилки в систему - це чудова ідея для глибокого орієнтування на концепцію оборони. Жодної помилки ніколи не повинно бути достатньо, щоб безконтрольно знищити всю систему (без чіткого діючого ведення журналу), викликати будь-які пошкодження даних або самі по собі виявити вразливість безпеки.

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

Пов'язаний варіант - використання прапорів функцій для навмисного вимкнення особливостей конкретних компонентів для вивчення того, як інші компоненти справляються з цим. Я також хотів би дуже рекомендую прочитати безкоштовну книгу / статтю "Навчання у перших респондентів: коли ваші системи повинні працювати", де описано таке масштабне тестування програмної інфраструктури, яку повинна використовувати команда Обами для виборів 2012 року.

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

Завданням QA є перевірити додаток щодо історій користувача, які він реалізує. Вони повинні перевірити потік, користувальницький інтерфейс тощо і гарантувати, що користувач може зробити все, що повинен зробити, максимально зручним і доступним способом. Роблячи це, звичайно, вони можуть натрапити на помилки, але це побічний ефект того, що вони роблять, а не те, що вони роблять. Пам'ятайте, що QA означає забезпечення якості, а не забезпечення помилок.

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

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

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

І все-таки - знання - це сила, і без цієї методики ви ще менше уявляєте якість своєї кодової бази. Якщо ви можете реалізувати це з повагою та з правильних причин, я б сказав "Чому ні?"

Ще одне, про що ніхто ще не згадував: тестування на мутацію .

Тут автоматичний інструмент бере ваш вихідний код і свідомо вставляє в нього помилки. (Наприклад, видаліть випадковим чином обраний оператор, змініть І на АБО чи інше.) Потім він запускає ваш повний набір тестів і перевіряє, чи проходять тести.

Якщо всі тести пройдуть, то є дві можливості:

• Те, що було змінено, нічого не робить. Іншими словами, у вас мертвий код.
• Зміна внесла помилку, яку ваш тестовий набір не сприймає. Вам потрібно більше тестів.

Зауважте, що на відміну від вашої пропозиції, все, що я описав вище, є автоматизованим . Ви не витрачаєте час розробників на вставлення безглуздих помилок вручну. І ви не витрачаєте час тестерів на пошук відомих помилок. Єдине, що ви використовуєте, це машинний час, який значно дешевший. (Машинам не нудно робити те саме тестування 20 000 разів. Люди перестають дбати через деякий час!)

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

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

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

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

Потім ви можете навмисно порушити виробничий код, щоб переконатися, що тести все ще працюють.

Існує кілька рівнів, на яких це можливо:

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

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

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

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

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

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

Тестер, який не приймає тестування коду безпосередньо з сховища, робить це неправильно. (1)

Розробник, який перевіряє відомий несправний код у сховище, робить це неправильно. (2)

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

(1) Тому що вам потрібно документувати, яку версію ви протестували. Ви можете перевірити версію з тегом Git-хешу чи номером версії SVN, "код, який мені дав Джо", не є.

(2) Тому що ви просто цього не робите, поза тестовим драйвером, який очікує збою.

Це спроба найкоротшого можливого приводу "крок ліфта", який повинен мати негайний сенс як для розробників, так і для тестувальників, і для управління.

Я рекомендую проти навмисного введення помилок у КОЖНУ складову, яку ви надсилаєте до QA.

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

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