Як боротися з розумом "Автоматизація проста"?

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

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

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

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

Постарайтеся навчити їх ЧОМУ це займає так довго, але не так багато, як ви їх втрачаєте в процесі «навчання».

У своїх ролях я стикався з багатьма людьми "х легко", особливо на проектах розвитку. На мій погляд, це три причини:

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

2) Вони прочитали пару книжок і думають, що знають, про що говорять

3) Нарешті, люди припускають, що комп'ютер тестує його швидко, оскільки комп'ютери швидкі.

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

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

Програмне забезпечення - це справа автоматизації речей.

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

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

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

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

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

У «Як бути багатим» Джон Пол Гетті (магнат свого часу) виступав за таке «крос-тренінг». На його думку, продавець, який проводив час на конвеєрі, де вироблявся продукт, зробив би набагато кращу роботу з продажу, а також інженер, який провів день із клієнтами, зробив би кращу роботу з «налагодження».

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

Я не згоден з вашим приміщенням тут.

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

Порівняємо автоматичне тестування та ручне тестування на основі наступного прикладу:

У веб-додатку перевірити функціональність "Змінити пароль" існуючого користувача за допомогою браузера.

Тестування вручну :

• Почніть веб-застосування
• Відкрийте браузер
• Чорт, помилка. Чому? О, я забув запустити базу даних!
• Гаразд, вимкніть веб-застосування
• Запустіть базу даних
• Почніть веб-застосування
• Оновіть браузер
• Хм, який був знову пароль нашого тестового користувача?
• Огляд бази даних
• О, таблиця користувачів порожня! Мені потрібно створити нового користувача.
• Зареєструйте нового користувача у веб-застосунку: Введення імені користувача, пароля, електронної адреси
• Чому я не можу увійти до свого нового користувача? О, мені потрібно натиснути на електронну пошту посилання підтвердження!
• Ну, я дав користувачеві електронний лист на кшталт "test@example.com". Переходимо до бази даних і встановлюємо стовпець "активний" на "так".
• Вхід. Цього разу це працює!
• Хм, що я хотів знову перевірити ...?

Легко? Не зовсім. У процесі є багато можливих підводних каменів.

Швидкий? Ні. Ручна робота вимагає часу.

Тепер спробуємо написати автоматизований тест :

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

Легко? Немає! Нам потрібно було вивчити інструменти, реалізувати їх, виправити деякі помилки в наших тестах.

Швидкий? Немає! Це займає навіть більше часу, ніж тестування вручну.

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

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

Писати автоматизовані тести - це не просто і не швидко, але виконувати їх є.

І це момент, коли вкладений час повертається.

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

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

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

2 +2 = 4 - один з найпростіших фрагментів коду, який розуміють усі; І ви можете бачити, як це легко зрозуміти. Але це не означає, що це "легке" рівняння. Рівень абстракції, необхідний для досягнення простого рівняння, досить складний. Те саме відбувається з методологією тестування програмного забезпечення та програмного забезпечення. Рівень абстракції, який вимагає фрагмента коду, вимагає багато роботи.

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

У цього питання є дві сторони.

На вашій стороні вам здається, що ви думаєте, що ви робите гарну роботу, і що група "Автоматизація проста" не знає, про що вони говорять.

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

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

Як боротися з автоматизацією - це просто розум

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

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

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