Як я можу почати тестування в тестуванні антикультури? [зачинено]

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

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

Але з TDD та його неправдою я збираюся закінчити багато тестового коду прямо разом із виробничим кодом. Наші системи управління версіями (усі централізовані) не організовані для зберігання тестового коду. Мені доведеться знайти місце для всього цього на своїй робочій станції.

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

Я особисто робив це з чималим успіхом. Ключові фактори успіху:

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

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

Я б запропонував прочитати розділ Принца Макіавеллі про те, як запровадити зміни, перш ніж робити що-небудь.

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

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

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

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

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

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