Недалекое прошлое: этюд о проблемах автоматизации тестирования
Изображение с сайта familyexpert.ru
На фоне постоянных разговоров о глобальной информатизации, стремительном развитии ИТ-сферы и, в частности, технологий разработки программного обеспечения, возникают размышления о гармоничности этого развития. Если разработка ПО семимильными шагами движется в сторону DevOps, автоматизации инструментария и продолжает движение, правда уже не так активно, в сторону Agile, то куда движется автоматизированное тестирование?
Хотя самому факту автоматизации тестирования в прогрессивных компаниях СНГ можно было найти подтверждение, но это подтверждение, на поверку, оказывалось формальным. Как говорится, и «да, и нет». По крайней мере, так было несколько лет назад.
Бытует мнение, что до сих пор далеко не во всех компаниях понимают, зачем вообще нужно автоматизированное тестирование. А если предположить, что такое положение вещей не меняется на фоне общего прогресса в разработке ПО, то возникают сомнения в гармоничном развитии направления автоматизированного тестирования. Возможно, такое отставание имеет место не во всех странах, где активно ведется разработка софта.
Конечно же, многое зависит от направлений, в которых применяется данный вид тестирования. В случае с веб-разработкой ситуация, на мой взгляд, проще: несколько лет назад всех покорил Selenium, который живет и здравствует по сей день. Также относительно комфортно устроились автотесты в сфере десктопной разработки ARM, AБС с базами данных: вспоминается простой инструмент 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 лет назад описанные проблемы еще не были решены в русскоговорящем ИТ-сообществе, как мне казалось. Может быть, сейчас ситуация изменилась?
Комментарии (3)
17 июля 2016 в 12:49
0↑
↓
Нужно понимать, что применение таких методологий как TDD предполагает, что автотесты пишут разработчики, а не тестировщики. Это методологии программирования и кодирования, а не разработки готового продукта, в которую вовлечено множество людей от ПМов и техписателей до админов и техподдержки. Разработчики же зачастую относятся к внедрению TDD-like как взваливанию на них обязанностей тестировщиков.Плюс полноценное внедрение подобных методологий требует наличие развитых DevOps процедур и технологий, внедрение которых часто тоже ложится на разработчиков. То есть они воспринимают это как перекладывание на них ещё и обязанностей опсов-админов.
17 июля 2016 в 13:02
0↑
↓
TDD действительно не то, что должны делать тестировщики. Их задача писать функциональные тесты и, если хвататет квалификации, интеграционные. TDD не TDD, но разработчики испокон веков занимались тестированием, запуская свой код и проверяя как он работает, юнит-тестирование это скорее формализация этого процесса.17 июля 2016 в 13:20
0↑
↓
Разработчики привыкли, что базовое тестирование функциональности — это полностью их зона ответственности, никто их не ограничивает в ней, не диктует и не проверяет объёмы, форму, инструменты и даже саму необходимость тестирования. Это с одной стороны. С другой — привыкли, что результат их работы (читай — то, что коммитится в репозиторий) — основной код, максимум конфиги для него.
