Недалеке минуле: етюд про проблеми автоматизації тестування


Изображение з сайту familyexpert.ru

На тлі постійних розмов про глобальної інформатизації, стрімкий розвиток ІТ-сфери і, зокрема, технологій розробки програмного забезпечення, виникають роздуми про гармонійність цього розвитку. Якщо розробка ПО семимильними кроками рухається в бік DevOps, автоматизації інструментарію і продовжує рух, правда вже не так активно, в бік Agile, то куди рухається автоматизоване тестування?

Хоча самому факту автоматизації тестування в прогресивних компаніях СНД можна було знайти підтвердження, але це підтвердження, на перевірку виявляється формальним. Як кажуть, і «так, і ні». Принаймні, так було кілька років тому.

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

Звичайно ж, багато чого залежить від напрямків, в яких застосовується даний вид тестування. У випадку з веб-розробкою ситуація, на мій погляд, простіше: кілька років тому всіх підкорив Selenium, який живе і живе донині. Також відносно комфортно влаштувалися автотесты у сфері десктопної розробки ARM, АБС з базами даних: згадується простий інструмент NUnit, очевидне застосування якого зводилося до автоматичної прогоні одних і тих же запитів до БД після змін, зроблених розробником. Напевно, хто-то ще згадає якісь вдалі приклади впровадження автотестів зі щасливим кінцем або хоча б зі щасливим початком.


Изображение з сайту qatestlab.com

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

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

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


Избражение з сайту mishka.by

Подібні історії, безумовно, відбувалися не тільки з тестуванням, але часто саме воно сприймалося, як «гальмо» для розробників. Почасти це пов'язано з ситуаціями, коли керівництво приймало на роботу тестувальників з більш низькою кваліфікацією, ніж у розробників. Причиною було не тільки бажання керівництва заощадити на зарплатах, але і об'єктивний факт – Внз СНД в більшості своїй не постачали на ринок таких фахівців, як тестувальники. А автоматизація тестування вимагає досить високої кваліфікації і в програмуванні, і в тестуванні, що ще більше ускладнює ситуацію.

Таким чином, в ІТ-індустрії (принаймні, в межах СНД) склалося уявлення про те, що кваліфікованих тестувальників, здатних займатися автоматизацією тестування, ще менше, ніж кваліфікованих розробників, здатних вирішувати нетривіальні завдання. Якщо багато низькокваліфіковані програмісти не досягли високого рівня, так як не змогли знайти «себе» (або просто в силу своєї ліні), то у тестувальників в СНД було об'єктивно менше можливостей отримати високу кваліфікацію. Мова не тільки про Вузи, але і про стажування, корпоративному навчанні, підвищенні кваліфікації, просунутих російськомовних спільноти тестувальників – все це кілька років тому було розвинене слабо. Можливо, зараз ситуація змінилася на краще.

Як би там не було, треба зробити знижку на те, що тестування як окреме напрям почав розвиватися пізніше, ніж програмування. Якщо розцінювати появу таких методологій, як TDD (Test Driven Development), BDD (Behaviour Driven Development) в якості чергової спроби «відіграти» це відставання, то довгий час вони успішніше всього існували у вигляді гарних ідей.


Изображение з сайту blog.andolasoft.com

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

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

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


Изображение з сайту pp.vk.me

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

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

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


Изображение з сайту 13min.ru

Інша категорія «першопрохідців» – стартапи, яким нічого втрачати. Вони збирають потужну команду і пробують те, що «ще ніхто не робив до нас». Однак їхні проекти далеко не завжди достатньо складні і масштабні, щоб окремо приділяти увагу особливим технологіям тестування. Тому знову вирішальну роль і імпульс до розвитку отримують методи ефективного програмування.

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

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

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

****

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


Изображение з сайту gearmix.ru

5 років тому описані проблеми ще не були вирішені в російськомовному ІТ-співтоваристві, як мені здавалося. Може бути, зараз ситуація змінилася?
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.