13-15 февраля с 17 до 19 часов по московскому времени проходила онлайн конференция для специалистов по автоматизации тестирования – Auto ConfeT&QA. Организаторы собрали докладчиков из России, Украины и Беларуси, которые представили на суд слушателей 10 докладов. Уровень организации был достаточно высоким, докладчикам помогали подготовиться к выступлению, репетировали с ними доклады, делали ревью презентаций. В результате все выступили достойно.
Я тоже принимал участие в качестве докладчика с докладом «TDD c помощью функциональных тестов на WebDriver». Я давно хотел выступить на данную тему и как раз представилась неплохая возможность это сделать. TDD (Test Driven Development) является популярным подходом среди разработчиков. Сначала пишется тест, а только потом на основании этого теста пишется реализация. Эта практика дает много преимуществ, позволяя сосредоточиться на небольшом аспекте функциональности и автоматизировать проверку правильности его реализации. Таким образом, разработчик сразу думает о вариантах использования и реализует минимальный необходимый функционал.
TDD можно применять не только на уровне модульных тестов, но и на уровне функционального тестирования. Это дает возможность задуматься о структуре и особенностях функциональности еще до ее реализации. Вам не придется мучиться в попытках протестировать приложение, которое не задумывалось для тестирования (сложные локаторы, непонятная структура страниц, запутанные связки элементов). В качестве сопутствующего эффекта, TDD позволяет сократить время на ручную проверку разработчикам и автоматизировать 100% функциональных тестов.
Многим понятны преимущества TDD, но они не знают с чего начать. Некоторым кажется, что написание теста до появления реализации вообще невозможно. В своем докладе я рассказал не только о преимуществах и особенностях данного подхода, но и на примерах продемонстрировал, как работать с TDD на практике. Были рассмотрены варианты распределения ролей, техники написания тестов и особенности их использования. В качестве основного инструмента для тестирования использован WebDriver.
Доступен слайдкаст доклада:
Так как я показывал живую демонстрацию, то посмотреть доклад в полном объеме можно на видеозаписи:
Лично мне понравилось несколько докладов. Отлично выступил Алексей Баранцев на тему “Разработка стратегии автоматизации”. Леша очень опытный докладчик, особенно в онлайн режиме. Доклад был насыщен полезными советами, которые помогут многим начать автоматизировать и снизить риски провала.
Яркий и живой доклад получился также у Ольги Киселевой, которая выступала первый раз. У нее была очень спорная тема “Можно ли писать автотесты на родном языке?”, которая вызвала много споров и дискуссий. Но сам доклад никого не оставил равнодушным.
Еще я для себя отметил доклад “Обходные пути в автоматизированом тестировании”, с которым выступал Дмитрий Жарий. Не всегда получается жить в идеальном мире и к нему приходится приспосабливаться. Именно о таких способах обходить препятствия и рассказывалось в докладе. Просто и со вкусом.
Остальные докладчики тоже молодцы. Спасибо всем за подготовку и потраченное время!
Организаторы проводили голосование среди участников за лучший доклад на конференции. Результаты опубликовали сегодня. С отрывом в один голос я занял второе место после Алексея Баранцева. Леша благородно отказался от приза по причине причастности к организации конференции. В результате, первый приз достался мне – игровая приставка Xbox 360 + сенсор Kinect. Я несказанно рад этому факту! Значит, мои усилия были интересны людям и приносят пользу. А теперь мое выступление принесло пользу и мне лично. 😉
Я буду с удовольствием выступать в очередной онлайн конференции из этой серии – Chief ConfeT&QA. На этот раз с докладом “Жизнь без тестировщиков: миф или реальность?”. Не подумайте, я не против тестировщиков. Наоборот – я за то, чтобы они занимались интересной работой и приносили большую пользу проекту. Подробности можно будет услышать на моем выступлении.
Участники задавали достаточно много вопросов после доклада. Ниже вы можете найти мои ответы:
Вопрос: Какими средствами CI докладчик пользуется (советует пользоваться) наряду с TDD?
Лично я уже давно почти везде пользуюсь TeamCity (http://www.jetbrains.com/teamcity/). Отличный UI, множество уникальных фичей, отличная интеграция с различными IDE, поддержка для практически всех известных мне инструментов, классная архитектура и т.д. Бесплатная версия подойдет для большей части проектов и не вызовет проблем или нехватки чего-то. На втором месте Jenkins (http://jenkins-ci.org/). Основной аргумент за него – бесплатный с огромным сообществом, а это значит куча плагинов под все, что только можно придумать. Но UI достаточно беден и нужно конфигурировать плагины самостоятельно.
Вопрос: А если ошибки возникнут потом при эксплуатации? Те тесты, которые не предусмотрели в “чек-листе”, согласованном с клиентом?
То, что мы не предусмотрели, не могло быть реализовано. Оно должно быть реализовано как отдельная доработка. А там действует все тот же TDD. На любой баг или недоработку сначала пишем тест, а потом уже начинаем работу…
Вопрос: По факту все же получается, что тест пишется паралельно с реализацией?
В большей части случаев (из моего опыта) тесты написать проще, чем реализацию функциональности. Поэтому тесты появляются достаточно быстро, но не полностью до начала разработки. Зато их обсуждение происходит перед началом работ, а этого хватает для получения практически всех преимуществ.
Вопрос: А какую test management system посоветуете?
В идеале – никакую. Я уже говорил о дублировании усилий на поддержку тестов и тест кейсов. Я вижу этот процесс как полную автоматизацию, поэтому предлагаю избегать использования test management систем. Они заведомо склоняют нас к дублированию.
Вопрос: Авто тесты лучше писать до разработки приложения или после и кто должен за это отвечать?
Конечно же их лучше писать до разработки. В этом и есть подход TDD. Таким образом вы сможете получить весь спектр преимуществ, о которых я упоминал в докладе.
Вопрос: Что делать если UI достался от legacy проекта?
Legacy код будет проблематичным для всех, включая тестировщиков. Но TDD заставляет работать над проблемами всей командой. Разработчики будут помогать победить проблемы. Вам придется разработать с течением времени тонкую прослойку над вашим нетестируемым UI и в будущем будет на порядок легче.
Вопрос: Опиши детальнее возможности инструмента testdox.
TestDox – это очень простой, но удобный инструмент. Он ставится как плагин к IDE и позволяет разбирать названия тестовых методов на слова. Таким образом можно включать гораздо больше полезных данных в название теста, причем писать просто на английском языке, избегая особенностей языка программирования (подчеркиваний, camel case и прочих). Поддерживается редактирование, список тестов, создание новых тестов. Таким образом, данный плагин приближает вас на шаг к тестам в качестве документации. Остается только подключить мозг. 🙂
Вопрос: Что ты думаешь по поводу BDD?
BDD – отличная практика, которая является подмножеством TDD. Вместо тестов рекомендуется начинать с поведенческих шаблонов приложения, причем оформлять их в человеческом виде (в основном предложениями английского языка). Не всегда дополнительные расходы времени на специализированный инструмент действительно оправданы. Если никто со стороны бизнеса не заглядывает в эти тесты, то возможно стоит перейти на уровень технических тестов с DSL.
Вопрос: Прокомментируй еще раз рекомендации с чего начать.
Начать стоит с того, чтобы осознать четко для себя зачем и почему стоит работать по TDD. После этого стоит донести свои мысли и идеи до всех членов команды. Причем не то, что вы собираетесь работать по TDD, а то, какие преимущества могли бы получить все от этого. Если у вас получится это сделать, то все будут хотеть применить TDD. А потом дело лишь в стратегии. Вам нужно найти удобный момент и начать внедрение. Поддержка команды поможет вам сделать это достаточно быстро (я имею ввиду начать). А дальше у вас будет освобождаться все больше времени за счет 100% автоматизации новой функциональности и вы сможете укрепить свои позиции. И не забудьте подготовиться морально к тому, что придется поломать мозг, как свой так и коллег. 🙂 Удачи!
