Чи програмісти погані тестери?

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

Джоель про програмне забезпечення - П'ять перших (неправильних) причин у вас немає тестерів (акцент у мене)

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

І в цьому питанні одна з найпопулярніших відповідей говорить (знову ж таки, мій акцент):

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

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

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

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

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

Чому програмісти погано тестуються:

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

Чому програмісти добре тестуються:

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

Чому програмісти погані тестери:

• Програмісти коштують дорожче, ніж тестери (у переважній більшості випадків).
• Мислення є принципово іншим: "Створіть (працюючий) продукт" проти "Ця річ не виходить у двері з будь-якими (невідомими) помилками в ній."
• Тестери, як правило, будуть більш ефективними - тобто виконують більше випробувань за один і той же час.
• Програмісти спеціалізуються на програмуванні. Фахівці з QA спеціалізуються на тестуванні.

Я думаю, що програмісти погано тестують власний код .

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

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

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

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

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

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

Але я не думаю, що це те, про що ви говорите, і я впевнений, що це не те, що означає Джоел Спольський - це частина, що залишається, власне практичне ручне тестування: перетворення документа на вимоги та функціональну специфікацію тестовий сценарій, а потім ретельно виконати цей скрипт проти готового продукту.

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

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

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

Чому? Ну, я не впевнений, чому це так, але, можливо, це тому, що ми хочемо, щоб матеріал працював. Або ми просто хочемо вже перейнятися тестуванням тієї чи іншої функції.

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

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

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

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

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

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

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

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

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

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

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

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

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

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