Автоматизация тестирования с нуля. Часть 1
Добрый день, уважаемые читатели.
Хочу рассказать об опыте построения системы автоматизации тестирования, когда на проекте или совсем нет тестирования, или ее степень минимальная.
Надеюсь статьи будет полезна начинающим автотестерам.
Когда делать автотесты?
Краткий ответ — как можно раньше.
А полный будет раскрыть ниже. В любом случае, когда проект работает 3 года, и все проверялось вручную, жить становится очень монотонно. И парк из 5000 сценариев автоматизировать за месяц-два проблематично. Как правило в таких проектах придется начинать прорабатывать сценарии заново. Потому что это окажется быстрее. И не факт, что старые получится автоматизировать без существенных изменений.
Почему?
Потому что автотетсы:
Накопленные сценарии
Чем больше парк автоматизированных сценариев, там больше вероятность найти регрессию, особенно если при каждом запуске данные изменяются.
Если автотест проходил стабильно и на какой-то ветке упал, то или меняли требования, или баг, или инфраструктура подвела.
Непредвзятость
Если меняли требования — автотест должен отправиться на переделку вместе с переделкой основного функционала. Именно поэтому тестировщики принимают участи в согласовании ТЗ.
Если прогон теста автоматически линкуется к задаче, то никто не сможет сказать, что это не тестировалось. Или наоборот, сможет. В общем проблем точно становится меньше.
Скорость
Если каждый тест удовлетворяет занудным условиям:
Предусловие — Тест — Постусловие
То такие тесты легко автоматизировать.
А потом легко распараллелить. Потому что они получаются независимыми.
Количество потоков — сколько выдержат тестовые сервера и чтобы не мешать другим.
Второй момент это сама по себе скорость. В ручном режиме прокликать создание товара, его поиск и покупку в интернет магазине это 5 минут. 4 браузера. Итого 20 минут. На всего лишь одном небольшом сценарии.
Автотест по этому сценарию проходит за 1,5 минуты. Но на 8 браузерах. (Последняя и предпоследняя версии каждого браузера).
С чего начать?
С пользовательских сценариев.
Ценность атомарных тестов все время падает, особенно на микросервисах. И вообще, в идеальном мире это зона ответственности программиста. Такие ошибки должны быть обнаружены на этапе юнит-тестирования.
QA должен работать от user story. Потому что программист обычно и не знает ее, и не хочет знать.
Соответственно логика 1 тест — 1 пользовательский кейс (бизнес сценарий) наиболее приближена к реальности.
Есть конечно сложности с подготовкой данных, например в случае интернет-магазина процесс оплаты картой требует наличия вещей в корзине, и или данных для нового пользователя, или данных авторизации существующего.
Да, иногда предусловия занимают больше времени, чем тест, но при переиспользовании сценариев сложности не несет.
Какие сценарии автоматизировать
Наименее подверженные изменениям в ближайшей перспективе. Чтобы автоматизация хоть сколько-то прожила.
Или наиболее часто используемые. Есть смысл помогать ручному тестированию в генерации тестовых данных. Например в доске объявлений есть смысл автоматизировать создание объявлений, т.к. далее любой сценарий требует созданного объявления.
Что конкретно делать?
Обычно в проектах есть
Поэтому предлагаю заняться Бэкэндом и Фронтом.
Выбираем сценарий
Допустим, у нас есть интернет-магазин.
Есть админка, есть клиентский и админский фронт.
Есть API, которое все это обслуживает.
С чего начать автоматизацию?
Есть клиенты, есть сотрудники.
У клиента первый кейс — просмотр и поиск товара, добавление его в корзину, и оформление.
У сотрудника самый распространенный кейс — добавление карточки товара.
Какой кейс автоматизируем первым? И как?
Самое важное для магазина — продажи.
Поэтому клиентская история наиболее важна для бизнеса. Поэтому найти товар, поместить в корзину и завершить оформление с любым способом оплаты это первое, что нужно сделать.
По API. Но без фронта. Тут можно поспорить, но скорее всего дизайн поменяется 2-3 раза еще, а вот бэкэнд вряд ли. Так что на 1 этапе придется интерфейс проверять вручную.
Далее сделать проверки на API редактирования карточки товара и ее фронт.
И вернуться к клиентскому. На этом этапе уже будет статистика наиболее частых действий пользователей, и наиболее частых путей клиента. Да, Яндекс Метрика и Вебвизор помогают и тестировщикам.
Нет никакого смысла на первом этапе проверять, работает ли функция оплаты на счет фирмы через сгенерированную платежку, если этой функцией пользуется 0,5% посетителей. Конечно можно задать менеджеру вопрос зачем это тут нужно, но тут не об этом.
Допустим у нас 40% человек платят на сайте картой, 30% наличкой, 20% наложенным платежом и 10% все остальные способы.
Какой тип оплаты будем проверять первым? Конечно картой.
То есть мы должны четко представлять, какой сценарий самый важный для бизнеса в данный момент. И его качество обеспечивать в первую очередь.
Постусловия
Мы насоздавали всего-всего в тестах. Намусорили. Надо бы за собой убрать. Нужно заранее предусмотреть, в каких тестах мы будем за собой убирать, а в каких — нет.
Если товар можно оставить в магазине, и ничего страшного не произойдет, то добавление прав администратора обычному пользователю нужно вернуть. А то следующий тест, связанный с правами может упасть. Или хуже — пройти позитивно, хотя должен был упасть.
Странности
Есть странный подход, когда автоматизируют сценарии, в которых пользователи находили баг. Обычно это очень экзотические сценарии, и тратить ресурс на них нет смысла. Была ситуация когда сломался функционал обновления данных банка-контрагента. Сбоила синхронизация со справочником БИК.
То есть новый БИК не обновлялся. Но новый банк заводился нормально.
Есть ли смысл автоматизировать этот сценарий? Если контрагенты меняются каждый день — может быть. И тогда это была недоработка планирования.
Если это делается 5-6 раз в год, то может лучше более приоритетной задачей заняться?
Что будет дальше?
В следующей статье я расскажу как быстро начать тестировать API, встроить эти тесты в релизы, распараллелить тесты, как подбирать данные для тестов и что нам это даст.
Напомню про эффект пестицида, и как его свети к минимуму.
Технологии: Java + maven + testng + allure + RestAssured + Pict.
Как стать автоматизатором тестирования?
Вчера, отвечая, кажется, в шестой раз на этот вопрос, твёрдо решил, что пришло время для написания статьи. Сразу отмечу – это исключительно моё видение, с которым, уверен, добрая половина мира автоматизаторов не согласится, – мой рецепт несколько сложнее, чем «почитать про тулзу», «поставить тулзу», «использовать тулзу», «написать в резюме, что умеешь пользоваться тулзой».
Эта статья полезна не только для мануальных тестировщиков, желающих автоматизировать свои рутинные проверки, но и для бизнеса и HR-ов, которые ввиду отсутствия каких-либо общепринятых критериев, как правило, понятия не имеют кто есть QA Automation Engineer и в большинстве случаев принимают решение на основании «хороший человек».
Бывает ещё хуже – руководитель/PM/etc… приходят к своим мануальным тестировщикам и говорят: «слушай, а может мы автоматизируем наше тестирование – это сэкономит нам кучу времени и денег. Скажи, какие книги тебе нужны и какие курсы».
Итак, мы узнаём, что такое примитивы, классы, объекты, полиморфизм, инкапсуляция, интерфейсы, абстрактные классы, статические поля, циклы, массивы, листы, мапы, потоки и так далее… Это изучение будет продолжаться в целом всё время, даже когда вы уже автоматизируете тестирование. Но на базовом уровне – Junior Java Developer – вы должны (если выбрали Java) быть знакомы с языком и иметь соответствующие навыки, потому как первичная локализация возникшей проблемы лежит на ваших плечах. Забудьте про «а вот у меня сценарий, ошибка наигрывается непонятно как и непонятно почему» — ваша задача, чтобы разработчик знал, что тут вот рядом человек может найти баги даже не запуская приложение. Не поверите, как вдруг качество продукта возрастает, когда есть человек, который не просто слышит запах плохо пахнущего кода, но и может предложить решения по улучшению.
Мы плавно перешли к
2. Использование шаблонов проектирования для разработки тестового фреймворка.
ДА-ДА. Вы открыли, например, Selenium, — всякие примеры, скопировали бездумно, написали на получившемся «фрэймворке» 1000 тестов. Приходит заказчик к бизнесу, говорит «мне тут нужно кое-что переделать», бизнес приходит к разработчику — «нам тут нужно немного подстроиться под рынок», разработчик всё прекрасным образом запиливает, — 90% тестов падают. Приходят к автоматизатору «мы тут немного поменяли, надо привести тесты в порядок», а автоматизатор в ответ «тут работы на месяц»… Упс…
Архитектура фрэймворка, который вы пишите, должна не просто быть гибкой, а должна постоянно стремиться минимизировать время рефакторинга имеющихся тестов и написания новых. В идеале, если разработчик и автоматизатор одновременно садятся исправлять что-либо, то автоматизатор должен сделать всё быстрее и предоставить разработчику некую форму TDD.
В создании такой чудо-архитектуры нам помогают паттерны проектирования и их грамотное использование… Builder, Facade, Factory, Null Object, Singleton, Adapter и многие другие паттерны активно помогают в решении подобных задач. Грамотная архитектура тестового фреймворка – это счастье для вас, для разработчиков, для бизнеса…и в конечном счёте для пользователя. Помните, что экспоненциальный рост ресурсов поддержки тестов при линейном росте/изменении функционала свидетельствует о том, что вам пора дорабатывать архитектуру движка. С наиболее полным списком паттернов с примерами на Java можете ознакомиться здесь. Отдельно отмечу Page Object Pattern, но лучше, сначала познакомиться с классическими.
3. Использование библиотек
То, что плавно вливается в любые задачи, — внешние API, библиотеки, драйверы и прочие прелести. Selenium — тестируем Web, Robotium/Espresso — тестируем Android, Fest/Jemmy — тестируем Java Swing, JemmyFX — тестируем JavaFX, замечательные Apache HttpComponents — делаем запросы и тестируем множество API, GSON — помогает приводить json к объектной модели и обратно и так до бесконечности… Библиотек прекрасных много написано почти под любую задачу — про некоторые из них можно почитать здесь. Не стоит бояться того, что их много — вы уже достаточно знаете, чтобы выбрать то, что вам подходит/нравится/вписывается в архитектуру. Например, под тестирование Java Swing приложений я использую JUnit, Fest, Mockito и широкие возможности java.lang.reflect — этого набора мне более чем хватает.
Будьте готовы к частому посещению stackoverflow и подобных ресурсов на ранних этапах. Будьте готовы к тому, что иногда надо будет заглянуть в исходники. И самое главное — не бойтесь не разобраться.
5***. Написание утилит и собственных библиотек
Тут звёздочки… У вас уже всё замечательно на проекте, регресс покрыт, тесты гоняются, разработчики спокойны и могут спокойно рефакторить архитектуру, не боясь сломать имеющийся функционал. Но, например, для того, чтобы что-то сэмулировать руками, разработчику приходится проделывать из месяца в месяц одно и то же действие руками. Напишите для него утилиту, оптимизирующую эти процессы, включите туда всякие невалидные сценарии, разрекламируйте на уровне компании, — пусть все начнут пользоваться… Это ускорит работу и, как ни странно, уменьшит количество багов, так как у разработчика появится больше времени на то, чтобы проверить побольше сценариев, прежде чем коммитить измненения в ветку. Оглядитесь по сторонам и вы увидите так много процессов, которые можно автоматизировать, что не будете знать, за что взяться.
Пишите достаточно абстрактные библиотеки, могущие быть использованными на разных проектах в вашей компании, да и просто в вашей работе в будущем.
P.S.
К бизнесу, руководителям, специалистам по подбору персонала:
Профессиональный автоматизатор тестирования в конечном счёте экономит деньги компании, я бы даже сказал, в краткосрочной перспективе. Смотрим сравнение очень близкое к реальности здесь.
Процесс автоматизированного тестирования за 10 шагов
Во многих организациях качество является главным приоритетом. Если вы окажетесь в такой организации, но в ней все еще не будет формального процесса автоматизации тестирования, вы можете стать тем человеком, который его внедрит.
С ним ваша организация сможет создавать более качественные продукты за меньшее время и соответственно раньше будет выводить их на рынок.
В третьей части «Руководства по автоматизации тестирования», я расскажу вам о том, что такое процесс автоматизации тестирования и как начать автоматизацию тестирования в вашей организации. Важно понимать, какой шаг нужно сделать первым и почему.
Выполнение этих шагов поможет вам внедрить автоматизацию без проблем и позволит избежать распространенных ошибок, которые приводят с сбоям автоматизации.
10 шагов на пути к внедрению автоматизации тестирования
В этой статье процесс автоматизации тестирования представлен пошагово, поэтому вы получаете руководство, которое поможет вам внедрить автоматизированное тестирование.
Шаг 1. Убедите руководителей
Независимо от того, насколько вам хочется внедрить автоматизацию тестирования в вашей организации, вы ничего сможете сделать, если руководство не видит в нем преимуществ. Все знают, что автоматизация тестирования – это дорого. Инструменты – это дорого (лицензия HP QTP/UFT стоит около 8 тысяч долларов на машину). Есть и стоимость работы архитектора или инженера по автоматизации (которая, кстати, тоже немалая). После всего этого преимущества автоматизации тестирования уже не кажутся такими очевидными. Должно пройти 2-3 месяца, прежде чем скрипты будут готовы, проверены и будут хорошо работать, а только после этого вы сможете начать тестирование вашего приложения.
Вам нужно убедить руководство, что нужно понести все эти расходы и подождать, прежде чем автоматизация тестирования выдаст какой-то результат.
Так как же их убедить? Вам нужно показать им анализ рентабельности. Например, вы можете задаться вопросом, сколько вы тратите на тестирование BAT (Build Acceptance Testing) вашего приложения? Если оно занимает день, то вы сможете сказать, что с автоматизацией тестирования сможете протестировать его за 2 часа. Стоимость будет состоять из приобретения инструментов, обучения персонала и ожидания результатов в течение двух месяцев. Через два месяца мы сможем проводить BAT за два часа. Каждый раз при выпуске нового билда вы будете экономить 6 часов. Если билд выпускается 4 раза в месяц, то вы сэкономите 24 часа или 3 рабочих дня ручного тестирования!
Тем не менее, это не значит, что ручные тестировщики не будут ничего делать. Они используют свои 6 освободившихся часов, чтобы сосредоточиться на новых и важных функциях приложения, в то время как автоматизация позаботится о задачах регрессии. Такая установка в целом улучшит качество продукта в десятки раз.
Если ваше руководство не готово платить за качество своей продукции, то никто не заставит его это сделать. Они поймут это сами, когда клиенты будут жаловаться на продукт. Качество влияет на все. Оно влияет на ваши продажи, на ваши отношения с клиентами, на восприятие вас в глазах пользователей. Таким образом, грамотное руководство всегда будет инвестировать в качество своих продуктов.
Итак, пять пунктов, которые нужно запомнить, чтобы убедить свое руководство:
Подробно расскажите им о преимуществах автоматизации тестирования.
Скажите, что автоматизация тестирования как таковая – это дорого, и по началу будет стоить много, но затем стоимость будет снижаться, когда скрипты будут готовы и начнут работать.
Скажите им, что нужно будет подождать около трех месяцев, прежде чем появится какой-то результат от автоматизации тестирования.
Расскажите, что автоматизация тестирования не имеет целью заменить ручных тестировщиков, а наоборот помогает им, поскольку вместе они могут покрывать большие объемы задач.
Автоматизация тестирования — не значит увеличение объемов тестирования и уменьшение количества времени, затраченного на него, она значит, что вы сможете делать больше задач одновременно. (Если ручные тестировщики проводили BAT за 8 часов, теперь они смогут протестировать BAT и другой функционал за те же 8 часов при наличии автоматизации.)
Помните, что убедить руководство – это самый первый и самый важный шаг на пусти внедрения автоматизации тестирования в вашей организации. Если они не будут уверены в целесообразности, то про вашу идею с внедрением автоматизации можно забыть или уйти в другую организацию 🙂
Шаг 2: Поиск экспертов по работе с инструментами автоматизации
Есть два вида экспертов по автоматизации:
Архитекторы по автоматизации
Инженеры по автоматизации
Архитектор по автоматизации – редкий зверь. Их непросто найти, они дорого стоят, но при этом они крайне необходимы для успеха проекта автоматизации. Эти специалисты обычно отвечают за создание систем автоматизации. (Фреймворки автоматизации мы подробно обсудим в отдельной статье).
Архитекторы по автоматизации работают с различными инструментами и обычно знают сильные и слабые стороны каждого из них. Такой специалист может помочь руководству выбрать правильный инструмент для автоматизации, тщательно проанализировав приложение и технологии, используемые для его создания. Также они могут построить фреймворк, разработать соглашение об именовании и правила для скриптов. Архитекторы по автоматизации помогут выбрать какие тест-кейсы автоматизировать в первую очередь.
Если вы найдете правильного человека на должность архитектора по автоматизации, то уже полдела по внедрению автоматизации тестирования будет сделано.
С другой стороны, появятся инженеры по автоматизации – это люди, которые переводят ручные тест-кейсы в автоматизированные скрипты. Они будут работать под руководством архитектора автоматизации и будут отвечать за создание и выполнение скриптов.
Одни компании нанимают инженеров по автоматизации извне, а другие воспитывают самостоятельно, обучая ручных тестировщиков. Как бы то ни было, человек должен хорошо владеть программированием. Он/она должны хорошо знать ООП. Команда из одного архитектора по автоматизации и двух инженеров по автоматизации отлично подойдет для работы над большинством продуктов.
Шаг 3: Использование правильного инструмента для автоматизации
Этот шаг заслуживает отдельной статьи (и позже я ее напишу). Он является сложным этапом в процессе внедрения автоматизации. Рынок изобилует различными инструментами, но вам нужно выбрать те, которые будут лучше всего подходить для вашего приложения.
Короче говоря, в этом пункте я опишу самые важные мысли о выборе инструмента. Процесс выбора инструмента я подробно распишу в отдельной статье.
Наиболее важные аспектами, которые следует учитывать при выборе правильных инструментов:
Инструмент должен отвечать вашему бюджету. Средства автоматизации – это дорого. Поэтому у компании под них должен быть заложен бюджет.
Инструмент должен поддерживать технологии, используемые в вашем приложении. Если в нем используется Flash или Silverlight, инструмент должен их поддерживать. Если ваше приложение работает на мобильном устройстве, инструмент должен уметь выполнять скрипты на нем. Вы можете приобрести один инструмент, поддерживающий все технологии, используемые в вашем приложении, или приобрести отдельные инструменты под каждую технологию. Например, для веб-приложений вы можете использовать Selenium, для приложений на Android взять Robotium, а MS Coded UI для десктопных приложений. Каким бы ни было решение, оно должно вписываться в ваш бюджет.
У вас должны быть все необходимые квалифицированные специалисты, которые умеют пользоваться этим инструментом или могут изучить его в кратчайшие сроки. Например, если вы наняли архитектора по автоматизации, у которого есть только опыт работы с QTP, и покупаете лицензию MS Coded UI, то специалист может работать неэффективно. Инструменты – это как хорошие автомобили, но у вас должны быть хорошие водители, чтобы водить их.
У инструмента должен быть хороший механизм генерации отчетов, чтобы можно было показать результаты работы заинтересованным сторонам.
При выборе инструмента нужно учитывать и другие факторы, о которых мы подробно поговорим в отдельной статье.
Шаг 4: Анализ различных приложений и определение тех, которые лучше подходят для автоматизации
Если ваша организация работает над 5 приложениями, нет необходимости автоматизировать каждое из них. Вам нужно учитывать различные факторы при выборе приложения для автоматизации.
Приложение, которое нужно автоматизировать, должно обладать следующими факторами:
Приложение не должно находиться на ранних стадиях жизненного цикла. (В приложении все или основные модули должны работать стабильно и уже быть протестированы вручную.)
Пользовательский интерфейс приложения должен быть неизменным. (Он не должен часто меняться.)
Ручные тесты для этого приложения должны быть задокументированы.
Основная цель автоматизации состоит в том, чтобы убедиться, что если в одном билде нет каких-то определенных ошибок, то их не должно быть и в следующем. Ручной тестировщик не должен тратить свое время на поиск регрессионных проблем, они должны быть выявлены с помощью автоматизации.
Таким образом, чтобы обнаружить регрессию, нам нужно стабильное приложение и несколько собственных тест-кейсов. Команда автоматизации преобразует эти тест-кейсы в скрипты и будет запускать их при каждой сборке, чтобы убедиться, что регрессия не появляется.
Шаг 5: Обучение команды
После выбора инструмента и найма необходимых специалистов, следующим шагом должно быть их обучение.
Если ручные тестировщики превращаются в инженеров по автоматизации, они должны знать терминологию и концепции автоматизации. Если архитектор по автоматизации нанят извне, он должен получить информацию о тестируемом продукте, существующем процессе ручного тестирования и о том, что от него ждет руководство.
Дайте сотрудникам некоторое время, чтобы опробовать различные подходы, пока они, наконец, не придумают выигрышную стратегию автоматизации. Обучите их инструментам, которые организация уже использует для отслеживания ошибок и управления требованиями.
Хорошая подготовка и коммуникация между ручными тестировщиками, разработчиками и командой автоматизации действительно необходимы.
Шаг 6: Создание фреймворка автоматизации тестирования
Самая большая задача для архитектора по автоматизации – это разработать фреймворк автоматизации, который должен поддерживать автоматизированное тестирование в долгосрочной перспективе.
Фреймворк автоматизации – это набор правил и тщательное планирование скриптов, которые нужны, чтобы уменьшить количество требуемого обслуживания. Если что-то меняется в приложении, скрипты практически не нужно менять, чтобы удовлетворить этим изменениям. В этом и заключается прелесть системы автоматизации.
Есть пять типов фреймворков автоматизации: линейный, модульный, управляемый данными, управляемый ключевыми словами и гибридный. Все эти фреймворки с примерами мы подробно рассмотрим в отдельной статье этой серии.
Вы можете узнать больше о фреймворках автоматизации из следующих источников:
Шаг 7: Разработка плана выполнения
План выполнения подразумевает под собой выбор среды, в которой будут выполняться скрипты. Среда включает в себя операционную систему, браузер и различные аппаратные конфигурации.
Например, если тест-кейс требует проверки веб-сайта в трех браузерах, а именно Chrome, Firefox и IE, то команда автоматизации напишет скрипт таким образом, чтобы он мог выполняться в каждом браузере.
Об этом всегда следует упоминать перед тем, как писать скрипты, потому что тогда команда автоматизации обязательно об этом позаботится. В плане выполнения также нужно указать, кто будет выполнять их. Обычно команда автоматизации выполняет скрипты на каждой сборке, но тут все зависит от компании. Некоторые менеджеры поручают разработчикам выполнить скрипты на сборке перед релизом, а в некоторых компаниях даже есть отдельная команда, которая их выполняет. Также какие-то компании запускают скрипты в автоматическом режиме, на что, конечно, требуются дополнительные ресурсы.
Шаг 8: Написание скриптов
Когда фреймворк готов, план выполнения утвержден, а специалисты обучены работе с новым инструментом, самое время начинать писать скрипты.
Скрипты должны писаться организованно с применением соглашения об именовании. Исходный код должен храниться в системе управления версиями, чтобы не потеряться. Должен присутствовать контроль версий и история изменений. Автоматизация тестирования похожа на разработку программного обеспечения. При написании скриптов нужно учитывать все лучшие практики программирования.
Шаг 9: Отчеты
Функция создания отчетов обычно предоставляется инструментом. Но мы можем создать собственные механизмы генерации отчетов, например, отправлять результаты тестирования по электронной почте руководству автоматически.
Мы можем создавать отчеты после каждого выполнения в виде диаграмм и таблиц, если это необходимо руководству. Руководство всегда должно быть проинформировано о покрытии тест-кейсами, то есть о том, какие ручные операции охвачены автоматизацией, а какие так и остались ручными.
Шаг 10: Обслуживание скриптов
Если вы следуете лучшим практикам программирования и используете хороший фреймворк, то техническое обслуживание не должно стать проблемой.
Техническое обслуживание обычно необходимо, когда есть потребность в изменении приложения. Скрипты нужно обновлять, чтобы учесть изменения в коде и обеспечить безупречное выполнение.
Например, если раньше вы с помощью скрипта вводили текст в текстовое поле, а в новой версии приложения это текстовое поле стало выпадающим списком, то скрипт необходимо немедленно обновить.
Другие изменения могут возникнуть, если раньше ваши скрипты работали на английской версии приложения, а теперь их нужно менять, поскольку приложение будет поддерживать и китайский. Ваш фреймворк должен позволять вам обновлять скрипты без особых усилий, чтобы ваше приложение хорошо работало и на китайском! Именно поэтому архитекторы по автоматизации стоят дорого. 🙂
Если фреймворк получился не очень хорошим, а лучшие практики не используются, то техническое обслуживание станет вашим кошмаром. Большинство проектов по автоматизации терпят неудачу из-за плохого обслуживания наборов скриптов.
Заключение
В этой статье мы поговорили о том, что такое процесс автоматизированного тестирования и как шаг за шагом ввести практику автоматизированного тестирования в вашей организации. Если вы сможете выполнить все эти шаги, надеюсь, что у вас получится успешно внедрить автоматизацию.
Есть некоторые моменты (например, выбор инструментов автоматизации и фреймворков), о которых можно написать отдельные статьи. В следующих руководствах по автоматизации тестирования мы их обязательно рассмотрим.
Я постарался охватить все аспекты и использовал свой собственный опыт для написания этой статьи.
Если вы считаете, что я упустил что-то важное или какая-то часть этой статьи нуждается в дополнении, расскажите об этом в комментариях.