Чому дозволяти / не дозволяти розробникам перевіряти власну роботу

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

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

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

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

Розробник знає, як працює їх код, і потрапить у звичку тестувати свій код відповідно до цих знань.

Розробнику буде важко видалити себе з розуму "як це працює", на відміну від "як це має працювати".

Через це краще надати комусь із високим ступенем об’єктивності тестування програми, тобто QA або Test Engineers

Тести на тест на розрив, прості. Цей тип ухилу необхідний, щоб дійсно з'ясувати пробки шоу.

Розробники ПОВИНЕН перевірити свою роботу. Це мається на увазі відповідальність.

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

Зазвичай розробники використовують мережі з величезними отворами для лову помилок. В результаті врятуються менші клопи.

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

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

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

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

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

Розробники повинні перевірити власний код.

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

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

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

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

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

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

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

Як розробник, який несе відповідальність за власний код, вам слід перевірити його. Does the feature work as expected?Якщо відповідь "так", ви закінчили.

Чому б вам не робити тестові справи?

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

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

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

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

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

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

Техніки та навички тестування теж дуже різні.

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

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

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

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

Наступний крок - завдання QA, щоб дізнатися, що розробники не бачать, коли ми пишемо код. Розробник мислить на більш високому рівні, але користувач може не думати на тому ж рівні. Коли розробник тестує свій фрагмент і мусить ввести якийсь текст у текстове поле, він завжди може ввести повний рядок, що думає, користувач також зробив би це. Користувач може зробити це теж, але випадково, коли він вводить у текст спеціальний символ, як% & $ ^, і який порушує програму, це не виглядає добре для кінцевого користувача. Розробник не може і не буде думати про всі можливості, які можуть статися, тому що він не навчений мислити так. Якщо мова йде про QA (тестер), вони завжди думають про те, що може зробити користувач, щоб зламати цю програму і спробувати все дурне в книзі, а не користувачі дурні, але ми нічого не повинні залишати випадковістю.

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

Нарешті, ми повинні пройти UAT (User Acceptance Test), щоб побачити, чи є те, що ми очікували. Як правило, хоча вимоги проходять через БА, кінцева особа може не точно знати, як це виглядає, і він / вона може подумати, що це не те, що вони очікували, або вони могли б хотіти додати щось інше, щоб воно виглядало краще або з якоїсь причини вони могли зірвати цілий шматок, як вони думають, шматок не піде з уже наявними функціоналами.

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

Зазначені коментарі викликають чудові бали.

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

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

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

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

Під час тестування програміст побачить текстове поле з позначкою "Кількість" та введе "1". Потім досвідчений програміст зробить подальший тест зі значенням "2".

Користувач побачить текстове поле з позначкою "Кількість" та введе "~~ єдиноріг ROX !!! ~~". Досвідчений користувач також спробує "-12 1/2".

Сподіваємось, тестер буде десь там, щоб попередити програміста про те, що користувач переживає, коли робить це.

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

Ще одна причина - час. Для великих проектів, які будуються поетапно, команда розробників побудує Етап 1. Потім тестувальники перевірятимуть його під час створення Етапу 2 та усунення недоліків Етапу 1. Це триває на всіх етапах, тому етап, який тестується, є попереднім, який був побудований.

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

Тести не обов'язкові для розробника. Розробник повинен перевірити написаний ним код. Як ще можна бути впевненим, що завдання було успішно виконано? Вам або потрібно написати якісь тести автоматизації (unittests) або виконати завдання перевірки "чи машина робить те, що я хочу це зробити" manuall (використовуючи GUI, викликаючи команду в командному рядку чи будь-що інше).

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

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

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

Причини, можливо, розробник може зробити остаточний тест

• Існує достатня кількість інших тестових покриттів ... Єдині тести існують, середовище тестування інтеграції існує і використовується, тестування інтерфейсу, дослідницьке тестування і т. Д. І т.д. проходять через"
• Набір тестових випадків, написаних професійним SQA / Tester, існує для того, щоб хтось (розробник) міг / повинен чітко дотримуватися
• В іншому випадку ризик відмови функції / продукту / модуля був зменшений до низьких рівнів (нехай професіонал перевіряє зони високого ризику, а «новачок» перевіряє нижчий ризик)
• Реальність бізнес-ситуації полягає в тому, що випускати товар з потенційними дефектами краще, ніж затягувати випуск
• Розробник, про який йде мова, насправді є дуже кваліфікованим тестером і здатний подумки змінити ролі
• Ця зміна - це виправлення помилок, зроблене розробником на місцях, коли сайт клієнта вимикається або іншим чином втрачає дохід через відключення системи (патч, який буде повернутий в офіс і протестований / випущений у контрольованій версії ASAP )

Причини розробник не повинен робити тестування

• Ще щось

Загалом, здається, ви на правильному шляху атаки на реальне рішення - нехай експерт SQA генерує тестові справи ...

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

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

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

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

Час, коли ІТ-індустрія рухається до більш професійного ставлення та застосовує процедури для запобігання тестуванню власного коду.

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

• Тестування - це рутинне обслуговування, і я зазвичай використовую аналогії для порівняння . Наприклад, аналогія зміни автомобільного масла. Ніколи не потрібно «міняти свою олію». Але ти все одно робиш це регулярно. Те саме для чищення зубів. Існує причина, що ви їх підтримуєте щодня - вони не збираються ламати "сьогодні", це все про завтра і майбутні дні та інвестування.

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

• Коли що-небудь колись перерва у виробництві, робимо дві речі:

  1. Скажіть "хм, чи є у нас тест на це " як перший коментар.
  2. Зробіть будь-яке виправлення, включаючи тести для проблеми , спочатку відтворити, ніж виправити.

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

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

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