testomat.io управление авто тестами1. Введение
Нет, вы не ослышались, речь действительно пойдет про бутерброды. Все дело в том, что я хочу поделиться своими рецептами по
приготовлению фреймворка для
автоматизации функционального тестирования веб-приложений с нуля на базе
Selenium. Так причем же все-таки бутерброды? Все очень просто,
фреймворк, о котором я вам расскажу, имеет название ButerbroD. Данный
фреймворк был разработан в компании Logic Software, в которой я имел честь работать, для тестирования нашего флагманского продукта Easy Projects .NET.
Почему мы так решили обозвать свой фреймворк автоматизации, спросите
вы? Дело в том, что он содержит несколько уровней абстракций, так
сказать, представляет собой многоуровневое или многослойное приложение.
При анализе архитектуры у кого-то из ребят в команде возникла ассоциация
с бутербродом, на мой взгляд вполне логичная. С тех пор данное название
закрепилось за фреймворком, писать решили по-модному – ButerbroD. К
слову, данный фреймворк удалось внедрить на проекты в компании Paralect, в которой на данный момент я тружусь – оригинальное название фреймворка удалось сохранить.
Бутерброды гораздо приятней или, даже эффективней 
, употреблять вместе с вкусным гарниром. Точно также сам факт наличия
фреймворка автоматизации тестирования, даже если он очень и очень крут,
сам по себе большой пользы не приносит. Ведь нужно еще уметь правильно
его использовать. Чтобы автоматизация действительно была эффективной
нужно иметь комплексный подход к ее успешному применению. Именно
поэтому, я бы хотел дополнительно рассказать об основных рецептах
автоматизации, которые мне удалось накопить и, которые я считаю важными.
Естественно, идеальных рецептов нет, и мои подходы не претендуют на
истину в последней инстанции, но мне они очень даже по вкусу, ведь они
делают работу проектов, на которых я работаю, более плодотворной и
качественной. Буду доволен, если мой опыт окажется вам чем-то полезным.
Но обо всем по порядку – начнем с небольшой исторической справки.
2. С чего все начиналось
Наш проект – Easy Projects .NET представляет собой систему управления
проектами. Без ложной скромности замечу, что это один из лучших и
известнейших продуктов в своей области. В последние годы Easy Projects
.NET стабильно попадает в списки лучших продуктов в своей отрасли. Объем
и сложность функционала для тестирования проекта достаточно велики –
несколько видов инсталляции, сложные пересчеты дат, мудреная систем прав
доступа, интеграции с другими продуктами, графики, отчеты и многое
другое. Новые версии продукта выходят регулярно, обычно каждую неделю у
нас выходят новые сборки продукта. Груз ответственности добавляет и
большое количество известных и уважаемых в мире клиентов, таких как
Microsoft, Volvo, Lenovo, FBI, Harvard и многие другие. Возможно, вам о
чем нибудь говорят эти названия . Соответственно, велики риски при пропуске ошибки в релизе.
История автоматизации нашего продукта насчитывает более 2-х лет. Сейчас мы работаем по гибкой методологии разработки Scrum, чему несказанно рады. Однако тогда у нас была стандартная и, на мой взгляд, малоэффективная модель с отделами разработки и тестирования.
Как мы тестировали?
Стоит начать с того, что у нас был налаженный процесс тестирования. Я считаю, что это один из немаловажных факторов при внедрении автоматизации на проекте. Автоматизация должна дополнять ручное тестирование. Поэтому, если вы задумались о внедрении автоматизации, не имея при этом стабильных процессов тестирования, то вам лишний раз стоит задуматься о необходимости внедрять автоматизацию именно сейчас. Очень коротко расскажу про некоторые тестовые активности на нашем проекте. Разработчики предоставляли команде тестирования установочные файлы. Тестировщики вручную «раскатывали» приложение и начинали усердно тестировать. Новые сборки на тестирование поставляли один раз в одну-две недели. По мимо проверки нового функционала и дефектов, у нас были Smoke тесты, которые выполнялись вручную и проверяли минимальную часть функционала продукта на нескольких конфигурациях. Время выполнения – около часа при параллельной работе трех-четырех тестировщиков. Затем следовали Basic тесты, которые проверяли высоко приоритетные пункты регрессии, время – около четырех часов. Автоматических тестов не было. Что нас не устраивало в данной ситуации? Во-первых, слишком большое количество времени тратилось на ручное тестирование. Во-вторых, очень часто возникала ситуация, когда в самом разгаре тестирования мы на одной из второстепенных страниц наталкивались на банальный крэш или другую серьезную ошибку. Тестирование приходилось завершать. После починки найденного дефекта тестирование приходилось начинать заново и так могло продолжаться несколько дней подряд. Все эти операции были достаточно рутинными и доставляли мало удовольствия команде тестирования. Сроки выпуска нового релиза затягивались, что никого не могло радовать.
Естественно, с этой ситуацией нужно было что-то делать, потому что такие ситуации были очень частыми. Решили попробовать автоматизировать часть приемочных тестов, используя Selenium IDE. Наверняка многие из вас знают, что из себя представляет данный инструмент. Про него классно пишет в своем блоге Selenium IDE – rulezzz Алексей Лупан, наверное, самый главный русскоязычный евангелист данного инструмента. В моем блоге также можно найти много полезной и интересной информации о Selenium IDE.
Почему Selenium IDE?
Инструмент достаточно прост для изучения и при этом, первые результаты
своих трудов можно получить практически сразу. Поэтому я рекомендую всем
тестировщикам, которые хотят развить свои навыки в автоматизации
начинать именно с него. С Selenium IDE можно быстро изучить основы
автоматизации, научиться работать с локаторами. Я тоже когда-то начинал
именно с Selenium IDE.
Учитывая, тот факт, что в нашей команде практически все уже работали с
этим инструментом или с Selenium RC, то выбор был очевиден. Наличие
специалистов имеющих опыт работы с определенным инструментом
автоматизации является важным фактором при выборе оного. Мы засучили
рукава и начали писать тесты, используя Selenium IDE. Практически сразу
мы наткнулись на некоторые трудности. Самые серьезные из них:
- ожидания AJAX-запросов. Что бы избавится от лишних ожиданий (sleep-ов) мы решили использовать решение от Виталия Помазенкова, которое представляет собой расширения к Selenium IDE. Решение заключается в том, что для специализированных JavaScript библиотек (jQuery, Prototype, Dojo и т.д.) вызываются команды-перехватчики AJAX-запросов и происходит ожидание выполнения активных AJAX-запросов. Чуть позже нам пришлось его совсем немного изменить. Все дело в том, что для некоторой функциональности нашего проекта использовались сразу несколько JavaScript библиотек, оптимизация заключалось в том, что нам нужно было научить перехватывать и дожидаться сразу нескольких AJAX-запросов разных JavaScript библиотек. А так же нам, нужно было научиться дожидаться JavaScript библиотеки MicrosoftAjax, тут не обошлось без привлечения высококвалифицированных коллег-разработчиков. После чего проблема с AJAX-запросами была решена;
- в тестируемом приложении используются компоненты от Telerik. Возникли проблемы с автоматизацией выпадающих списков и компонентов выбора даты, очень уж они проблемные для автоматизации. Тут также не обошлось без помощи от разработчиков. В наш файл расширения user-extensions.js к Selenium IDE были добавлены команды для обработки проблемных элементов. К слову, сейчас периодически появляются проблемы с работой выпадающих списков и компонентов выбора даты после обновления данных элементов управления интерфейса до новых версий;
- возникли проблемы с frame и iframe, это было связанно, с особенностями интерфейса продукта.
В результате мы смогли практически полностью (покрытие составило примерно 90%, за исключением Silverlight модулей и инсталляции продукта) заавтоматизировать приемочные тесты. Авто-тесты начали находить ошибки и экономить значительную часть времени. Нашему счастью не было предела! Это было примерно вот так:
Чуть позже, когда эйфория от первых положительных результатов прошла, мы пришли к заключению, что мощностей Selenium IDE нам стало не хватать, и начали присматриваться к Selenium RC.
Главные причины, которые побудили задуматься о переходе на более серьезный уровень автоматизации:
- слишком прямолинейные тесты;
- сложно поддерживать авто-тесты на Selenium IDE;
- нет возможности повторного использования кода;
- желание получать стабильные сборки приложения (авто-тесты должны запускаться автоматически на стороне разработчиков);
- Selenium IDE поддерживается только Firefox-ом;
- невозможно распараллелить тесты;
- не хватает гибкости при проектировании тестов.
После одобрения со стороны начальства мы начали проектировать свой фреймворк на базе Selenium RC. Но прежде чем переходить к описанию самого фреймворка, я хочу добавить пару важных слов о том, без чего попытка внедрения автоматизации, скорее всего, окажется плачевной.
2.1 Как мотивировать своих коллег и начальство
Одобрение и поддержка руководства – это обязательное условие при внедрении автоматизации. Конечно, очень здорово, когда начальство и коллеги понимают необходимость автоматизации. Сложнее когда приходится обосновывать перед ними необходимость внедрения автоматизации на проекте. Однако, тема слишком обширна для настоящего обсуждения, и заслуживает скорее отдельного доклада. Поэтому я всего лишь расскажу про свой опыт.
Как договориться с начальством.
Автоматизация, по-хорошему, должна приносить пользу проекту. Поэтому, когда вы приходите к начальству с подробным решением проблемы, то, как минимум, вас должны услышать. Ваша задача – заинтриговать руководство, чтобы идеи об автоматизации стали вашими совместными идеями. Не забывайте про план и стратегию. Мы разработали подробный план перехода с «легкой» автоматизации на «тяжелую», примерные сроки разработки тестов и высчитали прогнозируемую окупаемость инвестиций (ROI, Return on Investment). Данные опирались на результаты, которые были получены при работе с Selenium IDE. План был поэтапным. Вначале предполагалось покрыть тестами Smoke, затем, в зависимости от результатов браться за Basic тесты. Весь функционал был приоритезирован и сперва мы планировали писать тесты для более приоритетного функционала. Главная проблема, которую мы стремились устранить, – сокращение цикла тестирования, ну или по-простому экономия времени, а также увеличение тестового покрытия. Всегда нужно учитывать, что автоматизация это не только плюсы, но и минусы, поэтому необходимо предоставлять объективную информацию и стараться прогнозировать возможные риски.
Если вы начальник.
В первую очередь, необходимо найти в команде человека, который будет «тянуть» автоматизацию. Если у вас такого человека нет, то с внедрением автоматизации не стоит торопиться. Варианты – еще раз поискать у себя в команде или найти человека со стороны.
Как мотивировать коллег. Варианты «инфицирования».
На данном пункте я хочу заострить особое внимание, так как считаю его важным и при этом достаточно сложным. Чтобы авто-тесты приносили максимум пользы ими должны уметь пользоваться (как минимум уметь запустить) все заинтересованные участники проекта, от аналитиков до тестировщиков. Лично я столкнулся с такой проблемой, когда автоматизацией пользовались только автоматизаторы. Данная проблема кому-нибудь знакома? Это большая ошибка. Ваша задача как профессионала научить пользоваться вашими тестами максимально большее количество людей. Главная проблема на пути к этому – недоверие к авто-тестам. Единственный рабочий способ решения проблемы, известный мне, это – «заразить» вашими идеями, своим фанатизмом свои коллег. Во-первых, вы постоянно должны демонстрировать результаты работы авто-тестов. Автоматизация должна стать частью религии вашего проекта. Если вы работаете по гибким методологиям, то задачи по автоматизации продумывайте во время планирования спринта. Договоритесь, что на любой новый функционал обязательно должны разрабатываться тесты, иначе он не будет считаться законченным. Сделайте автоматизацию полезной всем! Подойдите к тестировщику и помогите ему заавтоматизировать его самую проблемную рутинную задачу. Продемонстрируйте тестировщику, как быстро на автомате могут выполняться самые проблемные тест кейсы. Привлекайте тестировщиков к разработке тестов, обучайте их.
Любой профессиональный разработчик заботится о качестве своего кода.
Обычно программисты пишут только unit-тесты (тесты на уровне кода,
проверяющие отдельный модуль приложения). Принебрегая при этом UI
тестами, считая, что ими должна заниматься команда по обеспечению
качества. Это не совсем верно, ведь у данных видов тестов различные
области покрытия. Работающие unit-тесты не дают информацию о том, что
ваше приложение на уровне интерфейса работает корректно. Только
сочитание unit-тестов и UI тестов может гарантировать комплексную защиту
от дефектов. Продемонстируйте разработчикам как просто писать
авто-тесты на уровне интерфейса и какую пользу можно получить от них.
Если программисты не очень сильно горят желанием помогать писать вам
авто-тесты, то попросите их подходить к вам с просьбами о создании
авто-тестов, для потенциально проблемных мест. Ведь разработчики о
проблемах в коде знают гораздо лучше вас.
Мы практикуем создание запросов на создание авто-тестов для
потенциально опасных мест в приложении – любой член команды может их
создавать. Некоторые команды используют функциональные авто-тесты для
создания критерия завершенности задачи. Таким образом, можно устранять
некоторые проблемы с бизнесом.
Станьте для ваших коллег воплощением профессионального отношения к делу –
остальные будут за вами тянуться. Старайтесь регулярно улучшать ваши
процессы с привлечением всех заинтересованных лиц. Помните –
автоматизация наиболее эффективна только тогда когда ей пользуется вся
команда проекта! Аминь .
2.2 Поиск инструмента автоматизации
Выбор инструмента автоматизации – задача нетривиальная. От вашего решения во многом будет зависеть результат попытки автоматизации. Многие “прогорели” именно на этом. Я не являюсь экспертом в этой области, но некоторый опыт по выбору инструментов имею. Могу рассказать, по каким критериям мы тогда выбирали инструмент. Очевидным фаворитом был Selenium RC (отмечу, что дело было более двух лет назад, тогда Selenium WebDriver-а еще не было), который и победил в итоге.
Почему Selenium RC?
Главные причины по которым мы выбрали Selenium RC:
- в команде были люди, уже имевшие дело с Selenium RC или Selenium IDE. А это уже часть дела ;
- у нас уже были тесты на Selenium IDE, соответственно часть наработок можно было использовать повторно и мы знали большую часть «косяков»;
- Selenium RC умел делать все, что нам нужно. Мы планировали писать тесты только для графического интерфейса пользователя и ничего более. Нам не нужен был космический инструмент, умеющий работать со всем множеством технологий и так далее. Небольшой подвох заключался в том, что в приложении есть Silverlight модули, которые также хотелось покрыть тестами. Однако на тот момент ни один инструмент не умел работать с Silverlight в чистом виде, поэтому на том этапе данная задача не была полностью решена. Ее мы решили отложить и решить потом. Как – расскажу чуть позже;
- инструмент прост и легок для изучения;
- поддерживает языки программирования;
- обеспечивает кроссбраузерность;
- распространяется бесплатно;
- имеет документацию, поддержку, сообщества;
- имеется вспомогательный инструмент записи/воспроизведения в лице Selenium IDE.
Резюмируя все вышесказанное, можно вывести несколько рекомендаций:
- внедряйте автоматизацию только тогда, когда у вас есть стабильные процессы тестирования;
- в вашей команде должен быть опытный специалист по автоматизации с выделенным временем;
- руководство должно поддерживать ваши начинания;
- команда должна доверять авто-тестам;
- начните с малого. Не забывайте про план и стратегию;
- ответственно относитесь к выбору инструмента для автоматизации.
Продолжение следует!