Изображение с сайта 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 лет назад описанные проблемы еще не были решены в русскоговорящем ИТ-сообществе, как мне казалось. Может быть, сейчас ситуация изменилась?
Комментарии (22)
RomanYakimchuk
17.07.2016 20:45Одной из причин НЕ внедрения тестов может быть бизнес. Тестирование увеличивает стоимость разработки, в ближайшей перспективе, в несколько раз. Это оплачивает клиент. Возможно, иногда можно продать продукт без тестов, в то время как с тестами нельзя. Впоследствии внедрить тесты в такой продукт может быть очень сложно.
powerman
17.07.2016 21:44Если тестировать только то, что действительно нужно тестировать, и делать это правильно (читай — не писать хрупкие юнит-тесты, которые постоянно ломаются и нуждаются в непрерывной поддержке) — то не в несколько раз. По моему опыту на разработку нормальных юнит-тестов (с покрытием 80-90%) нужно примерно столько же времени, сколько и на разработку кода, который они тестируют. Таким образом время (стоимость) непосредственного написания кода удваивается, но в общей стоимости проекта написание кода это далеко не 100%, так что в финале стоимость разработки увеличивается примерно в 1.5 раза.
Причём это стоимость разработки первой версии — а как только начинается поддержка этой версии (и юзеры с новыми багами и разработка нового функционала) оказывается, что код нормально покрытый юнит-тестами поддерживать значительно дешевле, так что с этого момента начинается сокращение разницы в стоимости разработки, и через несколько месяцев обычно оказывается, что к этому моменту стоимость разработки проекта с тестами уже меньше, чем без тестов. Конечно, окупить тесты таким образом и даже начать на них экономить можно только в проектах, которые активно развиваются и поддерживаются.
А вот если тесты писать не уметь, и в результате писать их слишком много и/или слишком хрупких — тогда да, ничего кроме раздувания стоимости разработки в разы не получится.
RomanYakimchuk
18.07.2016 10:56и через несколько месяцев обычно оказывается, что к этому моменту стоимость разработки проекта с тестами уже меньше, чем без тестов
Абсолютно верно.
то не в несколько раз
Может быть вы правы, и добавьте еще приемочные тесты, не говоря про интеграционные тесты, обучение тестировщиков, аналитиков. И все это можно умножить на специфику продукта.powerman
18.07.2016 11:21Я и хотел бы всё это добавить, но как реалист обычно счастлив уже когда есть хотя бы нормальные юнит-тесты.
mx2000
17.07.2016 21:50в переводе на мир материальных товаров это звучит так: соберите мне кастомный автомобиль. Краштесты не нужны, обкатка не нужна. Просто соберите. Да, гарантия тоже не нужна.
Отсутствие тестов на код не оставляет шансов на изменение скоупа продукта как в ходе разработки, так и после нее, и делает багфиксинг неприемлемо дорогим.
Maxik77
18.07.2016 10:29+1Так и не понял — на чём автор основывает свою статью? Можно ли увидеть где-нибудь увидеть методы исследования, цифры опросов разработчиков и ПМ?
Или всё это одно большое IMHO? Ну так нужно так и писать тогда: «по моему мнению, в компаниях, в которых я работал, автоматическое тестирование развито слабо», вместо безаппеляционного мнения, преподносимого как.истина в последней инстанции.
Я вот работал в компании, которая автоматические тесты пишет с 90х годов. Что дальше, моё мнение против мнения автора?
Тем более, для внедрения TDD/BDD и изобретать ничего не нужно, в современных средах разработки достаточно добавить тестовый проект. На самом деле это единственно возможный способ убедиться что твой собственный код отвечает всем требованиям, других способов попросту не существует. Любой программист так и или иначе всегда делал отдельные маленькие проекты, в которых пробовал новые идеи. Ну так вот — место таким проектам — в тестах!mx2000
19.07.2016 20:04зачем выделять отдельный проект, когда достаточно сделать git checkout -b?
RomanYakimchuk
20.07.2016 09:59Может быть это имеет смысл чтобы разбить «кухню». На одной стороне продукт, который пишут разработчики. На другой стороне группа тестирования, которая не вникает в исходники проекта, не вклинивается в процессы разработки продукта, и эту группа параллельно разработке покрывает продукт приемочными тестами.
Maxik77, зачем в вашем случае понадобилось выносить тесты в отдельный проект?Maxik77
21.07.2016 05:35Separation of concerns.
Без разницы кто пишет тесты. Место тестам — в отдельном проекте и отдельной области видимостиVolCh
21.07.2016 06:43Место тестам — в отдельном проекте
Зачем тратить лишние ресурсы на связывание двух проектов?Maxik77
21.07.2016 07:59Вы серьёзно всё это пишете? Т.е. вы реально тесты деплоите в продакшн? Со всеми зависимостями тест-фреймворка?
Первый раз вообще о таком ужасе слышу.VolCh
21.07.2016 08:53Лично я нет, из проекта на продакшен сервера деплоится только то, что нужно для продакшена, но кроме этого в проект входят тесты, документация, конфиги для различных окружений и т. п. Но вообще есть практики девопс, когда конечный артефакт (например докер-образ) содержит и тесты, которые прогоняются после деплоя уже на продакшене, перед тем как подключать/переключать развернутые инстансы к балансерам/роутерам. И даже есть практики периодического прогона тестов прямо на продакшене, чтобы определить когда инстанс не работает.
Maxik77
21.07.2016 09:31Как именно деплоится только то, что нужно для продакшена? Скриптовый язык какой-то?
Как раз рилиз диплой подразумевает, что там нет всех этих левых зависимостей, которые неизбежно тянутся за тестами, да и самих тестов нет, которые неизбежно раздувают результирующий бинарник. К тому же тесты могут обладать сайд-эффектами, т.е. код работает только в присутствии тестов, что является очень неприятной фичей.
На CI деплоится весь солюшен, который с нуля собирается и прогоняются тесты. Потом собирается инсталлятор, пекеджи и т.д.
Именно так всё работает во всех C/C++/C# проектах, в которых я участвовал.
В скриптовых языках возможно это и не так актуально, так как зависимости все грузятся на этапе пре-компиляции или вообще в рантайме.RomanYakimchuk
21.07.2016 10:03Скажу за приложения на JavaScript.
а) У нас есть инструменты для запуска проектных задач через командную строку (таск-раннеры, Gulp, Grunt). Сами задачи пишем сами. Например, задачей может быть сборка проекта, или его отдельных компонентов, тестирование, деплой, генерация документации, эспорт документов, и прочее. Как-правило есть задача на сборку продукта для продуктива (склейка списка исходников, минификация, и прочее), и на выходе получается или папка с исходниками для прода, или архив.
б) У нас есть пакетные менеджеры, для установки внешних зависимостей в проект. Они позволяют разделять девелоперские зависимости от зависимостей самого продукта.
В JavaScript приложениях мы можем держать всё в одном проекте, и не смешивать одно в другое.Maxik77
24.07.2016 08:01Я понимаю, что для скриптовых языков — это не так актуально. В языках же где на выходе — бинарник, это большое NO NO.
В модулях на джаваскрипте что я видел — тесты вынесены в отдельную директорию, и релиз на выходе в поддиректории dist. Никакой особой проблемы с этим не вижу, просто особенность инструментария и языка.
Вот что я реально видел — это тесты положены в ту же папку, что и сорс файл, только у него суффикс _test.java, они даже в одном пространстве имён находятся и потом собираются в один .jar. Вот это реально бред, так делать нельзяVolCh
24.07.2016 15:03В том же джаваскрипте это (тесты в одной папке с продакшен кодом и ресурсами) тоже имеющая место быть практика, имеющая вполне логичное объяснение: изоляция модуля/компонента от остального кода, всё что касается этого модуля/компонента лежит в одной папке и может быть легко скопировано в другой проект или выделено в отдельную библиотеку/фреймворк. Насчёт одного бинарника именно в джаве не скажу, мало с ней знаком, но на си/плюсах есть практика генерировать два бинарника — собственно продакшен-реди код и тестовый бинарник, который динамически линкуется с первым, используя его как библиотеку. Как вариант — вынос подавляющего большинства продакшен кода в библиотеку, оставляя в непосредственно исполняемом бинарнике по сути лишь «main», и создание второго исполняемого бинарника, у которого main принадлежит тестовому фреймворку.
vyatsek
18.07.2016 10:29+1Статья ни о чем. Много воды смысла нуль. Автоматизированное тестирование и TDD тоже надо применять с умом. Почему вы не раскрываете деталей и условий когда это хорошо и когда плохо?
Разрабатывать по TDD? Иди поучи свою жену щи варить. Что нам говорит TDD, сначала пишем тест. Он не проходит. Имплементируем функционал — проходит. Такой подход иррационален. Зрелый продукт внутри представляет собой иерархическую структуру с компонентами и слоями, которые в свою очередь тоже покрыты тестами. TDD двойное покрытие. Учитывая что бизнес логика меняется, то со временем придется еще поддерживать и тесты.
Как на мой взгляд должно производиться тестирование. Чем важнее и «базовее» компонент, тем лучше он должен быть покрыт тестами. TDD хорошо подходит для некоторых фич фреймворков.
Интеграционное тестирование хорошо подходит для критических вещей всего продукта.
Автоматизацию надо начинать с рутинных или приемочных тестов, без которых продукт выпускать смысла нет. В идеале можно использовать DSL подход, и прямо в требовании писать сценарий на DSL для тестирования.
Например проводник винды: select menu «File», submenu «New». Keyboard «My Folder». Check: Explorer.FolderExists("%PATH%\My Folder").
Например у нас в приложении есть большое количество независимых окон, автоматизировали сценарий открытия окна, пока кодом, следующий шаг выделить DSL и дать возможность тестерам писать DSL.VolCh
18.07.2016 11:39Зрелый продукт внутри представляет собой иерархическую структуру с компонентами и слоями, которые в свою очередь тоже покрыты тестами. TDD двойное покрытие.
TDD предполагает юнит-тестирование каждого компонента и слоя изолированно, без двойного покрытия.
VolCh
Нужно понимать, что применение таких методологий как TDD предполагает, что автотесты пишут разработчики, а не тестировщики. Это методологии программирования и кодирования, а не разработки готового продукта, в которую вовлечено множество людей от ПМов и техписателей до админов и техподдержки. Разработчики же зачастую относятся к внедрению TDD-like как взваливанию на них обязанностей тестировщиков.
Плюс полноценное внедрение подобных методологий требует наличие развитых DevOps процедур и технологий, внедрение которых часто тоже ложится на разработчиков. То есть они воспринимают это как перекладывание на них ещё и обязанностей опсов-админов.
Tagakov
TDD действительно не то, что должны делать тестировщики. Их задача писать функциональные тесты и, если хвататет квалификации, интеграционные. TDD не TDD, но разработчики испокон веков занимались тестированием, запуская свой код и проверяя как он работает, юнит-тестирование это скорее формализация этого процесса.
VolCh
Разработчики привыкли, что базовое тестирование функциональности — это полностью их зона ответственности, никто их не ограничивает в ней, не диктует и не проверяет объёмы, форму, инструменты и даже саму необходимость тестирования. Это с одной стороны. С другой — привыкли, что результат их работы (читай — то, что коммитится в репозиторий) — основной код, максимум конфиги для него.