Чи потрібно вимагати тестування від програмістів? [зачинено]

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

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

Я тут абсолютно не в порядку?

Будь ласка, надайте мені аргументи на будь-яку думку.

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

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

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

Особисто я вважаю, що у вашому випадку вам слід замислитись над тестом прийняття тестів:

• У вас подарована чорна скринька, і ви очікуєте, що вона поводитиметься певним чином.
• Ви не заплатите, поки це не зробите.
• Напишіть одиничні тести з поведінкою, яку вам потрібно побачити, і якщо вони не вдається, вони повинні виправити це.

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

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

Мене дивує, наскільки поширене таке мислення. Автоматизовано, так. Одиничне тестування (поодинці), немає. Існує спосіб більш автоматизованого тестування програмного забезпечення, ніж одиничні тести. Що з інтеграцією, системною, функціональною, якісною? Чомусь люди схильні думати: "Гаразд, ми маємо належні тестові одиниці. З тестуванням, називайте це ввечері п'ятниці!" . Тестування одиниць - лише початок.

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

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

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

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

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

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

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

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

Ви навіть можете написати тести або хоча б специфікації тесту.

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

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

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

Ваше завдання - пояснити та переконати людей - набагато важчі навички!

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

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

Примусове автоматичне тестування на когось не досягне бажаних результатів, як в своїх коментарях зазначили @Joachim Sauer та @Telastyn. Для багатьох людей автоматизоване тестування блоків - це величезний зсув у їхньому мисленні. Тому що багато людей пишуть код, який працює, але не дуже перевіряється. Я можу написати веб-сторінку ASP.NET, де вся логіка, запити до бази даних, бізнес-правила, об'єкти тощо знаходяться в коді позаду. Чи буде сторінка працювати? Так. Чи перевіряється це за допомогою автоматизованого тестування одиниць? Абсолютно не. Якщо постачальник не має автоматизованого тестування одиниць, тоді знадобиться досить зусиль, щоб навчитися правильно писати одиничні тести і в результаті цього вивчити, переписати або перефабрикувати свій код, щоб зробити його легше перевірити. Цілком ймовірно, що вони перейдуть на вас цією ціною.

Справа в тому, що постачальник дає вам товар, будь то .dll або програма Windows, і ви очікуєте, що він буде працювати 99% часу. Звичайно, тут і там є помилки, але здебільшого це має працювати. Це обґрунтоване сподівання, особливо якщо постачальник хоче зберегти ваш бізнес. Якщо це чорна скринька, то не дуже важливо, як вони змушують її працювати, вони можуть використовувати людську хвилю тестерів або кімнату, повну мавпи, випадково вдаряючи ключі. Поки це працює. Але їм потрібно було б надати вам якусь іншу документацію про те, як ним користуватися.

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

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

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

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

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

Цю статтю про придбання користувацького програмного забезпечення я вважаю досить корисною: http://blog.8thlight.com/paul-pagel/2012/06/20/entrepreneurs-guide-to-buying-software.html

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

Погодьтеся з іншими, що вимагають одиничних тестів, це призведе до тестування заради тестування; щось, що дуже суперечить тому, що ти хочеш.

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

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

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

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

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

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

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

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

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

Моя порада для вашої ситуації - шукайте вендерів, які вважають за краще писати код з одиничними тестами, і вибирайте їх серед вендерів, які не пишуть код за допомогою об'єднаних тестів. Якщо керівництво заплатить за це, поставте в контракт автоматизовані тести, але ТОЛЬКО, якщо ВІДПОВІДНИК ВИКОРИСТОВУЄТЬСЯ НА ПИСМУВАННЯ КОДУ З ОДНИМИ ТЕСТАМИ.

Давайте спочатку розберемо пріоритети ...

У вашій ролі замовника ваша головна проблема - не тестування одиниць

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

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

• Яка прийнятна кількість одиниць тестів?

Чи повинно бути 10 тестів? Як щодо 100 тестів? Як щодо 1000 тестів? Насправді на початку досить складно визначити, скільки тестів вам знадобиться. Дійсна кількість насправді невизначена ... як проблема зупинки ... але ми не вирішуємо цю проблему.

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

• Який прийнятний рівень покриття коду?

"100%, звичайно!" ви б подумали. На жаль, цей показник вводить в оману; навіть якщо ви мали 100% покриття коду, ви справді впевнені що все працює так, як очікувалося? Можна мати 100% покриття, але цього не робити.

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

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

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

Вам знадобиться більш високий рівень тестування

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

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

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

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

Дещо сумно, що програмне забезпечення з відкритим кодом з відкритим кодом постачається разом з тестами, але професійний розробник програмного забезпечення не може, правда?

То коли я, як замовник, переймаюся тестуванням одиниць?

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

Як ви знаєте, що продавці не пишуть одиничні тести.

Можливо, керівництво і постачальник мали зустріч, і продавець сказав, що код коштує $ X, а одиничні тести коштують $ Y. Менеджмент пощипування Пенні сказав, що ми просто хочемо код.

Продавець вирішив все-таки написати одиничні тести (через якість) і просто не поділитися ними з вами (через конкурентну перевагу).

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

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

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