Чи повинні розробники брати участь у етапах тестування?

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

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

Дякуємо, що поділилися своїми думками.

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

(Тільки наперед, це не дублікат програми. Чи повинні програмісти допомагати тестерам у розробці тестів? Це говорить про підготовку тесту, а не про тест виконання, де ми уникаємо наслідків розробників)

Дивлячись на ваше запитання дуже буквально ("задіяний"), моя єдина відповідь - абсолютно однозначна

ТАК

Devs ніколи не повинен мати остаточного слова щодо власного коду.

Але, Devs повинні бути залучені до тестування роботи інших дияволів. Це робить дві речі:

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

Нарешті, чому б ви не використали якомога більше очей? Ви рідко можете дозволити собі пройти процес найму та борту на борту, щоб привезти на борт додаткових QA людей на борт. Отже, де ви знайдете зайві очі, які вам потрібні? Або ви намагаєтесь пробити час стиснення з тим самим числом якості, яке ви мали весь час? Навіть якщо розробники витрачають 20% свого часу на тестування та 80% виправлення будь-яких помилок, все-таки більше уваги на додаток, ніж у вас раніше. Автоматизоване тестування дає лише певний рівень впевненості, і воно ніколи не буде 100%.

http://haacked.com/archive/2010/12/20/not-really-interested-in-lean.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+haacked+%28you%27ve+been+HAACKED%29

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

Принципова відмінність тестування філософії між розробниками та Qs полягає в цьому: програміст зазвичай тестує свою програму, щоб довести, що його код працює ("позитивне" тестування). QA може і робить це, але також має додатковий упор на з'ясування того, що не працює , намагаючись зламати програмне забезпечення (використовуючи "негативне" тестування).

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

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

Що ж стосується тестування, то існує 3 типи.

Чорний ящик, сірий ящик і білий ящик.

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

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

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

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

ТЕСТУВАННЯ БЛОКУ є обов'язковим для всіх розробників

Інформацію про те, як це можна використати на вашу користь, прочитайте наступні посилання, якщо ви працюєте на C ++:

• Швидке ознайомлення з Рамкою тестування Google C ++
• Інструменти тестування блоку C / C ++ з відкритим кодом, частина 1: Ознайомтесь із рамками тестування підсилювального модуля Boost
• Інструменти тестування блоку C / C ++ з відкритим кодом, частина 3: Ознайомтеся з CppTest

НЕ МОЖЕ ШТО ЛЮДИНА QA МОЖНА ЗРОБИТИ ЦЕ ТЕСТИ. У ЖОДНОМУ РАЗІ.

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

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

Ви пишете:

Проблема полягає в тому, що через проблеми з ресурсами (*) фази тестування занадто довгі і часто скорочуються через часові обмеження. Тому що розробники не роблять цього. Одна з найбільших інтернет-компаній, що постачають найкращі найстабільніші продукти, взагалі не використовує тестери. Вони використовують лише автоматичне тестування, все це роблять самі розробники. Результати - x10 кращі продукти, ніж коли розробник залишає тестування "тестерам".

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