Проведення тестування підрозділів у компанії, яка цього не робить

Керівник розробки програмного забезпечення моєї компанії просто "подав у відставку" (тобто звільнився), і ми зараз розглядаємо вдосконалення практики розробки нашої компанії. Ми хочемо впровадити тестування одиниць у всьому програмному забезпеченні, створеному з цього моменту.

Відгук розробників такий:

• Ми знаємо, що тестування цінне
• Але ви завжди змінюєте характеристики, щоб було марною витратою часу
• І, ваші терміни настільки жорсткі, що ми не маємо достатньо часу для тестування

Відгуки від генерального директора такі:

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

Як розробники отримують специфікації зараз? Слово уст або слайд PowerPoint. Очевидно, це велика проблема. Моя пропозиція така:

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

Що ж, якщо ви коли-небудь були в компанії, яка опинилася в цій ситуації, як ви вирішили проблему? Чи підходить цей підхід розумним?

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

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

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

Паралельно з цим розпочніть обговорення найкращого способу уточнення та документування вимог та перетворіть їх на тести прийняття високого рівня. Це більш тривалий процес послідовного вдосконалення, який може легко зайняти роки, щоб досягти кращого, стабільного стану всієї організації. Одне здається досить впевненим у вашому описі: намагатися виправити постійно мінливі вимоги, написавши великі специфікаційні документи наперед, просто не вийде . Натомість рекомендується рухатись до більш спритного підходу, з частими випусками програмного забезпечення та демонстраціями користувачам та безліччю дискусій про те, чого вони насправді хочуть. Користувач має право будь-коли змінити свою думку щодо вимог - однак кожна зміна має свою вартість (у часі та грошах). Розробники можуть оцінити вартість кожного запиту на зміну, що, в свою чергу, дає змогу користувачеві / власнику продукту приймати обґрунтовані рішення. "Безумовно, ця зміна функції була б непоганою ... але якщо вона затримає випуск цієї іншої важливої ​​функції, і коштуватиме це багато, давайте введемо її у відставання зараз".

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

Мій досвід із здійснення переходу

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

Нещодавно мені запропонували використовувати тестові розробки, і я виявив, що це повне одкровення. Зараз я твердо переконаний, що не маю часу не писати одиничні тести .

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

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

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

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

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

Моя порада

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

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

Натомість я б рекомендував починати з малого та використовувати правило хлопчика-скаута :

Завжди залишайте кемпінг чистішим, ніж ви знайшли.

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

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

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

Підсумок

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

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

Отже .. спочатку специфікації та документально підтверджені характеристики, які не змінюються (ну, не відразу). Ви повинні подивитися, як це зробити. Я рекомендую веб-сайт, на якому користувачі можуть завантажувати характеристики або вводити їх безпосередньо. Ви також можете пов’язати це з відстежувачем помилок та керівництвом про хід проекту.

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

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

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

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

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