Автоматизация Тестирования
Разработчики, следующие гибким принципы разработки ПО, подчёркивают важность автотестов. В коротких циклах ручное регрессионное тестирование почти невозможно. Значит ли это, что не должно быть вообще ручного тестирования? Нет. Только некоторые виды ручного тестирования рекомендуемы, например, виды тестирования, отличные от традиционного сценарного ручного тестирования.
Автоматизируйте ваши ручные тесты
В продуктовых группах часто утверждают: “Невозможно автоматизировать тесты, основанные на потере сетевого соединения“ или “Мы не можем автоматизировать тесты с падением “железа“. Наш ответ обычно: “Нет, это не так” или “Да, вы можете”.
Элизабет Хендриксон, автор буклета Exploratory Testing in an Agile Context, осмеливается утверждать:
Я думаю, если вы можете написать сценарий для ручного тестирования, то вы можете его автоматизировать.
Автоматизировать ручные тесты как есть может быть нелёгкой задачей. Например, почти невозможно вытащить сетевой шнур автоматически в тесте с потерей соединения. Однако автоматический тест может быть выполнен в другом ключе. Вместо того, чтобы физически вытаскивать сетевой шнур, автоматический тест даст команд драйверу сетевой карты, как если бы шнур был вытащен на самом деле.
Есть ли ценность в автоматизации всех тестов? Согласно Хендриксон:
Если тест достаточно важен, чтобы создать для него сценарий и выполнять его, он также достаточно важен для автоматизации.
Почему так? Итеративно-инкрементальная разработка ПО подразумевает, что исходный код не фиксируется навсегда в конце каждой итерации, а потенциально готов к изменениям в следующих итерациях. Поэтому ручное регрессионное тестирование подразумевает повторное прохождение большинства тестов – каждую итерацию. Автоматизация тестирования быстро себя окупает.
Страхующая сеть из автотестов имеет первостепенное значение, особенно в крупномасштабной разработке с фиче-командами и практикой общего владения кодом
Проводите некоторые тесты вручную
Автоматизация всех тестов может быть бесполезной или даже невозможной. Следующие тесты могут выполняться вручную:
- Тесты, требующие человеческого внимания и творческого подхода – Для оценки пользовательского интерфейса требуется человек – тестирование удобства (usability testing). Исследовательское тестирование по определению требует кого-либо, кто принимает решение о дальнейших шагах.
- Тесты, требующие физического движения – Например, тесты с различными физическими конфигурациями системы. Это может быть автоматизировано с помощью симуляции, но реальная конфигурация будет необходима для финального запуска тестов.
- Дорогие тесты – Тестирование ёмкости (capacity tests) в промышленной среде может быть слишком дорогим, поэтому может выполняться один или два раза. Это отсрочка увеличивает риски. Эти риски должны быть снижены за счёт дешёвых тестов – например, путём тестирование ёмкости в среде симуляции – таки образом запуск дорогих тестов становится просто окончательной проверкой.
Ложной дихотомии тут нет: Попытайтесь автоматизировать все тесты, но не забывайте тестировать вручную, когда это требуется.
Проводите исследовательское тестирование
В книге Perfect Software and Other Illusions about Testing Джеральд Вайнберг называет их, “Глубочайшая ошибка тестирования в том, что можно проверить все!”. Это так. Количество возможных сценариев тестирования бесконечно, следовательно, автоматизация всех тестов означает бесконечные трудозатраты. Вместо этого автоматизируйте все типовые тесты и потратьте время эффективно, насколько это возможно, на исследовательское тестирование, чтобы обнаружить непредвиденные сценарии.
Краткий обзор исследовательского тестирования
Исследовательское тестирование
Что такое исследовательское тестирование? Это “одновременное обучение, разработка выполнение тестов” [Bach03]. Это контрастирует с обычным сценарным тестированием, где проектирование тест-кейсов и их исполнение разделены и выполняются последовательно — сначала проектирование, потом исполнение. Исследовательское тестирование помогает полностью использовать творческое начало людей во время исполнения тестов, получение обратной связи и наблюдений в отличие от бездумного следования сценарию. В исследовательском тестировании тестировщик исследует систему, изучает её и использует эту информацию для принятия решений о дизайне самого теста. Это лучше объяснить на примере.
Представьте, что Гита тестирует программу для 2D-моделирования. Сначала, она определяет цель сессии тестирования — в исследовательском тестировании она называется миссией или чартером. Её чартер состоит в том, чтобы “Исследовать изменение фигур при перетаскивании контрольных точек.” Она берет фигуру, переносит её в рабочую область и создаёт пару контрольных точек на ней. Она перетаскивает одну из них и наблюдает, что произойдёт. Основываясь на этом наблюдении (новых знаниях), она определяет следующие шаг (дизайн) и выполняет его. Фигура приобретает новую форму, но она замечает — во время перетаскивания контрольных точек — что фигура временно приняла такую форму, котору не должна была принять. Поэтому, Гита продолжает перетаскивать фигуру и перемещать её вокруг, пока не сможет воспроизвести это случайное преобразование.
В этом пример нет детального предопределённого сценария или тест-кейса, но есть фокус на области — чартере. Первым шагом является исследование системы, на нём строится определение следующего действия — это и есть дизайн теста. Все традиционные методы испытаний и эвристики применяются на этом этапе проектирования.
Сценарное и Исследовательское тестирование
Автоматизированное тестирование
Создавайте поддерживаемые тесты
“Необходимость поддержки автотестов увеличит нашу загрузку” — возражение, которое мы слышим. Поддержка автотестов потребует дополнительных усилий, но следующие техники могу их снизить:
- удаляйте дублирование внутри тестов и между ними
- удаляйте тесты, не добавляющие ценности
- избегайте тестирования через пользовательский интерфейс
- запускайте тесты часто
- относитесь функциональным м нефункциональным требованиям одинаково
- непрерывно выполняйте длительные тесты
- используйте виртуализацию или контейнеризацию
- избегайте использования коммерческих инструментов тестирования
Удаляйте дублирование внутри тестов и между ними
Дублирование в коде приводит к дополнительной сложности, снижение прозрачности и дефектам — что ведёт к накладным расходам в сопровождении. Это правда для кода тестов, так и для продуктивного кода. Избегайте этого, удаляя дубликаты.
Процессные тесты (workflow tests) являются основной причина дублирования. Они часто состоят из одного материнского сценария и множества сценариев, незначительно отличающих друг от друга. Когда один шаг меняется, все эти тесты нужно обновить. Такое дублирование можно избежать с помощью тестов на основе данных (data-driven tests), которые фокусируются на бизнес-правилах, или переносом дубликатов в тестовые библиотеки или фикстуры.
Мы консультировали команду, которая совершила типичную ошибку — они отложили автоматизацию тестирования на конец итерации. За 4 дня до конца остались только задачи на автоматизацию. В предыдущих итерациях эти задачи были выполнены специалистом по тестированию, но теперь их нужно было сделать всей команде.
Они начали с однодневного воркшопа, на котором специалист по тестированию обучал других членов команды. После это, они разбились на пары и одну тройку для работы над автоматизацией тестирования параллельно. Далее произошло следующее: члены команды с опытом в разработке жаловались на трату дополнительных усилий из-за дублирований в тестах. До этого никто из них не замечал этого, и специалист по тестированию — не имевший достаточного опыта в разработки — никогда об это не заботился. Теперь вся команда была вовлечена и заботились об этом, и качество тестов улучшилось значительно.
Удаляйте тесты, не добавляющие ценности
Тесты служат нескольким целям. Они выступают требованиями, проверкой и страхующей сетью, не допуская регресса системы.
Когда существующий тест уже больше не нужен — потому что он включён в другой тест — то удалите его. Сохранение ненужных тестов пользы не приносит, но увеличивает затраты на содержание и снижает скорость тестирования.
Избегайте тестирования через пользовательский интерфейс
Пользовательские интерфейсы (UI) часто меняются. Запуск ваших тестов через пользовательский интерфейс делает их уязвимыми для этих изменений — даже в случае, когда в логике тестов изменений не было. Это увеличивает затраты на их сопровождение.
Следовательно, избегайте тестирования через пользовательский интерфейс, а вместо этого обращайтесь к приложению напрямую через программный интерфейс (API). Ещё одно преимущество состоит в том, что это ускорит ваши тесты, поскольку тестирование через пользовательский интерфейс выполняется медленно.
Запускайте тесты часто
Много лет назад мы работали с большой продуктовой группой, следовавшей водопадному подходу разработки. Традиционный совет в сфере автоматизации тестирования состоит в том, чтобы выбрать и автоматизировать наиболее важные кейсы — силами отдельной команды автоматизации тестирования — после релиза. Они это сделали. К концу следующего релиза они запустили эти тесты… и они упали. Обновление тестов требует много времени, поэтому они решили провести всё тестирование вручную.
Запуск тестов единожды или дважды за релиз кажется эффективным — меньше процессорного времени будет потрачено — но больше будет изменений, и поэтому многие тесты могут упасть, что породит большую порцию работы по их исправлению. Напротив, частый запуск тестов — используя систему непрерывной интеграции — требует больше процессорного времени, но в результате мы получаем меньший объём работы в части поддержки тестов, поскольку сил на исправление упавших тестов требуется не так много. Если у вас большая загрузка по сопровождению тестов, то есть не мало шансов, что вы будете редко запускать эти тесты.
Относитесь функциональным м нефункциональным требованиям одинаково
Автоматизация и непрерывный запуск нефункциональных тестов также важны. Перенос их на конец может означать сдвиг снижения одно из самых больших рисков туда, где его реализация принесёт больше всего вреда. Например, если требуется определённый уровень производительности системы, начните его раннее тестирование, чтобы также достичь его раньше, и непрерывно запускайте эти тесты, пока будет добавляться новая функциональность, чтобы убедиться в том, что система не деградирует по производительности от её целевого уровня.
К нефункциональным требованиям часто относятся по-особенному — люди верят, что их нельзя описать и протестировать. Это прискорбно. На воркшопе по уточнению, нефункциональные требования могут быть разобраны так же, как и функциональные, а также могут быть созданы тесты из примеров для их прояснения.
Непрерывно выполняйте длительные тесты
Нефункциональные тесты часто не могут запускаться в системном цикле непрерывной интеграции, потому что они занимают много времени — тесты стабильности могут занимать до двух недель. В некоторых продуктовых группах их оставляют до релиза — создавая отложенный цикл обратной связи. Не самая хорошая идея.
Запускайте длительные тесты все время в медленном системном цикле непрерывной интеграции. Относитесь к ним также, как и к любым другим. Когда они падают, оповещайте всех, кто изменял код. После их прохождения получите последнюю сборку и запустите их заново. Таким способом цикл обратной связи будет на столько коротким, насколько мог бы быть.
Используйте виртуализацию или контейнеризацию
В порядке ускорения тестов и экономии на аппаратном обеспечении максимизируйте использование инструментов для виртуализации, например VirtualBox или VMWare. Альтернативой виртуальным машиным (которые не всегда быстро собираются и легко поддерживаются) являются виртуальные linux контейнеры, такие как Docker.
Избегайте использования коммерческих инструментов тестирования
Однажды мы консультировали компании, которая разрабатывала коммерческий инструмент для “автоматизации тестирования” — инструмент с графическим интерфейсом. В чем состоял их запрос? Научить их, как автоматизировать тестирование их инструмента, автоматизирующего тестирование…
Доступно огромное множество коммерческих инструментов. Мы редко встречали людей, которые по настоящем удовлетворены какими-либо из них. Большинство из них чрезмерно сложно и фокусируются на отчётности и ‘менеджменте‘, а не на автоматизации тестирования. Предпочтите свободные инструменты с открытым исходным кодом — созданные разработчиками для решения реальных проблем — коммерческим.
Список распространённых инструментов для автоматизации тестирования:
Выше всего лишь самый общий список, но каждый день появляются новые и новые инструменты.
Какие виды тестирования лучше автоматизировать?
Иногда ручного тестирования недостаточно, чтобы обеспечить качество, особенно когда речь идет о сложных программных продуктах и многокомпонентном ПО. К тому же, современные IT-компании, адаптируясь к динамичным потребностям рынка, ускоряют разработку, поэтому и на тестирование отводится все меньше и меньше времени. В результате автоматизация играет все большую роль, ведь она позволяет ускорить QA-процессы. Давайте посмотрим, какие виды тестирования следует автоматизировать в первую очередь.
Регрессионное тестирование
Этот вид тестирования автоматизируют чаще всего, что неудивительно, ведь автоматизация в данном случае избавляет тестировщика от многократного выполнения одинаковых тест-кейсов перед каждым релизом. Как правило, сценарии автоматизированных регрессионных тестов разрабатываются на основании ручных тестов, которые уже показали свою эффективность путем выявления дефектов. Наибольшей эффективности при автоматизации регрессионного тестирования удается достичь, если речь идет о сервисах, требующих регулярного внесения изменений.
Автоматизация хорошо себя зарекомендовала и в том случае, когда тестировщику надо выполнять одинаковые действия, но каждый раз с разными данными. Все данные можно собрать в одной базе, а скрипты станут автоматически использовать эту информацию при проведении тестов. Кстати, это уже не что иное, как DDT-подход к тестированию (data-driven testing).
Кроссбраузерное и кроссплатформенное тестирование
Автоматизация способна повысить эффективность и таких видов тестирования, как кроссплатформенное и кроссбраузерное. Тут все просто: одинаковые сценарии автоматизированных тестов используют на разных платформах.
Тестирование локализации
Такое тестирование бывает весьма трудоемким для ручного исследования. К примеру, если мы тестируем сайт с десятками версий на различных языках, мы проверяем адаптацию элементов интерфейса, перевод текста и т. д. Наша задача — получить информацию о том, не привела ли локализация к появлению дефектов. В данном случае автоматизация позволит протестировать нужные аспекты с меньшей затратой времени.
Исследование производительности, нагрузочное и стресс-тестирование
В наше время performance testing (исследование производительности), а также нагрузочное тестирование и стресс-тестирование почти всегда автоматизируются. Существует ряд инструментов для автоматизации (JMeter, Gatling, Tsung), позволяющих воспроизводить разные условия, в том числе и «на грани фола», то есть условия, которые могут вызвать проблемы с производительностью программного приложения. Используя автоматизированные тесты, вы смоделируете нехватку оперативной памяти и другие ситуации, ну и, что немаловажно, сможете зафиксировать реакцию программного обеспечения на эти ситуации.
Автоматизация тестирования: что можно, а что не нужно
Непрерывное тестирование ускоряет поставку программного обеспечения, делая весь процесс тестирования более быстрым. А благодаря незамедлительной обратной связи, которая помогает уже на самых ранних этапах выявлять ошибки и другие проблемы в приложении, гарантирует, что команды разработки будут создавать высококачественные и надежные приложения. Кроме того, сама способность организовать и проводить эффективное тестирование может значительно снизить затраты в компании, как за счёт экономии времени разработчиков, так и вследствие создания добротного конвейера поставки, в котором они могут быстро вносить изменения в код с минимальными рисками нарушения работоспособности приложения в продуктивной среде.
Главным элементом непрерывного тестирования является его автоматизация, что даёт множество преимуществ:
- Быстрое получение обратной связи
- Аккуратное и тщательное тестирование
- Высокое покрытие тестами
- Быстрое обнаружение ошибок
- Повторное использование тестов
- Более короткие сроки поставки
- Адаптация для DevOps
- Экономия времени и денег
Несмотря на перечисленные выше преимущества, начальные вложения в автоматизацию тестирования могут быть очень высоки. Приобретение ПО, затраты на обучение работе с ним, проектирование и создание автоматизированных тестов — всё это требует немалых времени и денег. Однако, как только вы начинаете всё активнее разрабатывать новые функции в своём продукте, ручное тестирование в конечном итоге выходит дороже, а автоматическое — дешевле.
Кроме того, следует понимать — не всё нужно автоматизировать и не всё можно автоматизировать. Поэтому важно тщательно оценить, изучить и проанализировать свои требования, прежде чем решить, как лучше всего организовать автоматизацию тестирования. Когда следует автоматизировать тесты, а когда — нет?
Какие тесты можно автоматизировать
Практически каждая команда разработчиков работает над проектом, который критически зависит от сроков, а значит, что времени на применение всех передовых практик всегда не хватает. То же самое относится к стратегии тестирования, поскольку тестирование как вид деятельности не всегда является приоритетом для команд разработки. Нужно попытаться найти баланс и сделать правильный выбор в зависимости от типа разрабатываемого приложения, временных рамок, используемого ПО для тестирования и имеющихся ресурсов. Вот важные типы тестов, которые можно автоматизировать.
Модульное тестирование
Это отличный способ приступить к автоматизации тестирования, поскольку модульные тесты направлены лишь на часть кода, в ходе которых он проверяется на работоспособность, и не зависят от других частей приложения. Таким образом, разработчики получают больше информации о работе созданной функциональности. Благодаря современной культуре тестирования многие команды используют методологию разработки через тестирование (test-driven development, TDD), при которой они начинают составлять тесты до написания кода. Таким образом гарантируется качество и кода, и тестов.
Приоритетные функции
Если у вас в плане десятки функций и сжатые сроки на их разработку, вы можете выделить среди них те, что имеют высокую вероятность сбоев. Тестирование подобных функций нужно начинать как можно раньше.
Регрессионные и интеграционные тесты
Интеграционные тесты используются для определения того, работают ли отдельные модули в приложении как группа, а регрессионные тесты проверяют, что функции приложения работают должным образом. Эти два теста обычно выполняются после изменений / улучшений приложения, поэтому тестировщики постоянно проводят эти тесты. Автоматизация таких тестов экономит огромное количество времени, высвобождая его для выполнения других типов тестов.
Нагрузочные тесты и тесты производительности
Для тестов производительности и нагрузочных тестов нет альтернативы в виде ручного тестирования, поскольку необходимо моделировать сотни или тысячи пользователей, работающих в разных условиях: из-под разных браузеров, в разных часовых поясах, использующих разные операционные системы и т.п.
Повторяющиеся тестовые сценарии
Это очень важные тесты, которые команды разработки вынуждены запускать чуть ли не постоянно. Например, работоспособность функции входа в систему — она обеспечивает возможность пользоваться приложением, влияя на его доступность. Поэтому лучше автоматизировать тестирование и сэкономить прорву времени тестировщиков и разработчиков.
Базовая функциональность (дымовые тесты)
В отличие от других тестов, дымовые тесты не такие сложные и относительно легко реализуемые. При этом прохождение этих тестов имеет решающее значение. Они информируют команды разработки о том, правильно ли работают базовые функции приложения, например: открывается ли окно входа в приложение, могут ли пользователи войти в систему, доступен ли API, доступно ли приложение из разных мест и т.п.
Какие тесты не нужно автоматизировать
Всё больше и больше узнавая о преимуществах автоматизации тестирования и глубоко проникаясь ими, можно задаться закономерным вопросом — а почему бы не автоматизировать вообще все тесты? Ответ в виде “не нужно пытаться автоматизировать всё” идёт вразрез с DevOps-мышлением, в котором явная установка на автоматизацию всего и вся. Перед планированием автоматизации тестирования нужно учесть несколько факторов. Вот примеры тестов и сценариев, для которых не нужна автоматизация.
Пользовательский опыт (UX)
Эта область тестирования не может быть автоматизирована. Многие аспекты UX-проектирования требуют ручного, долгого и утомительного тестирования. Например, когда разработчики хотят понять, насколько легко пользователи могут зарегистрироваться на веб-сайте, или проверить, какие наборы полей дают лучшую видимость профилей пользователей. Подобные тесты должны быть проведены вручную.
Стадии ранней разработки
Когда какая-то функция только-только разрабатывается, в её код постоянно вносятся изменения, а это может затруднить составление и теста. На ручное тестирование этих функций уходит меньше времени, поэтому следует дождаться стабильной версии.
Функциональность, не имеющая большой важности
Автоматизация тестирования требует времени и усилий, поэтому следует автоматизировать тестирование не всех функций, разрабатываемых в рамках проекта, а лишь самых важных функций. Низкоприоритетные можно оставить в стороне и продолжить тестировать их вручную.
Тесты без понятных результатов
Командам разработки необходимо знать ожидаемый результат для каждого входа функции. Если результаты непонятны, то и автоматизация не предоставит необходимых доказательств того, что функция работает должным образом.
Тесты, которые невозможно полностью автоматизировать
Если автоматизирована половина теста, а другая половина так и осталась выполняемой вручную, то это приводит к сложности и дополнительным расходам, поскольку проведение такого теста требует много времени, а достоверность его под большим вопросом. Было бы рациональнее продолжать тестирование таких функций вручную.
Фреймворки автоматизированного тестирования
В каждой команде разработки и поставки ПО группа QA отвечает за разработку, внедрение и выполнение тестов. Для каждого типа тестирования должен быть определён тестовый сценарий, принципы, правила и инструменты для проведения. Фреймворк тестирования — это набор этих руководств, инструментов и практик, который помогает инженерам-тестировщикам эффективно выполнять тестовые сценарии.
Существуют разные фреймворки для разных целей тестирования. Вот некоторые из самых популярных типов фреймворков для автоматизированного тестирования:
- Модульный: приложение разделено на отдельные модули, и каждый модуль тестируется в изолированном состоянии
- Линейный: составление и исполнение тестовых скриптов. Тестировщики пишут тестовые сценарии последовательно, выполняя их затем для каждого отдельного тест-кейса
- Библиотечная архитектура: создан на основе модульного фреймворка тестирования, с той лишь разницей, что содержит функции для многократного использования
- Управляемое данными тестирование: тестовые скрипты выполняются и верифицируются на основе данных, которые хранятся в центральном хранилище данных или базе данных (SQL, ODBC-ресурсы, csv или xls файлы)
- Тестирование по ключевым словам: в данном фреймворке не обязательно иметь навыки программирования, поскольку ключевые слова, используемые при создании тестов, отделены от технического кода. Тестировщику достаточно иметь представление о всём наборе действий, реализованных во фреймворке
- Гибридный: комбинация из различных фреймворков.
Главная цель всех команд разработчиков программного обеспечения — обеспечить быструю поставку качественного и надежного программного продукта. Чтобы обеспечить быстрый и эффективный процесс поставки, необходимо непрерывное тестирование. Автоматизация — ключ к тому, чтобы разрабатываемое ПО могло быстро пройти через все стадии конвейера разработки и предоставить клиентам свои функции. Однако, это не означает, что команды должны вкладывать всё свое время и ресурсы в автоматизацию тестирования. Команды должны понимать, что можно и нужно автоматизировать, а что не стóит. Правильный выбор охвата тестов на ранних этапах разработки имеет большое значение.
Какие тесты наиболее эффективны с точки зрения автоматизации
- Портал
- Форум
- Тренинги
Что пишут в блогах
- Путь тестировщика. Интервью с тренером ПОИНТ Никитой Кратом
- Юзабилити: что мы можем узнать от Apple и Twitter
- Legacy code and tests
- Анонс митапа от Тинькофф
- Зеленая орионская рабыня
- Курсы по тестированию ПО: полное расписание на сентябрь 2023
- Вебинар про ISTQB FL 4.0 (2023)
- Жизненный цикл тестирования ПО. STLC. Этапы жизненного цикла тестирования ПО
- Оптимизация тестовых сценариев с помощью ИИ: TestCraft и Testim
- Как интервьюировать тестировщика? Понаблюдайте за ним в действии
Конференции
Большая техническая конференция по тестированию Heisenbug 2023 Autumn
10–11 октября онлайн и 15-16 октября офлайн в Санкт-Петербурге
Что пишут в блогах (EN)
- SoCraTes 2023 — A Place Where I Belong
- Everything You Need For Great Testing Results In One Platform
- Regarding free sharing of material
- Open Source Test Automation Tools in 2023
- Boost your engineering capability with this growth-focused framework
- Text Trek: Navigating Classifications, Part 6
- Text Trek: Navigating Classifications, Part 5
- Five for Friday – August 25, 2023
- Experience Report: Using ChatGPT to Generate and Analyze Text
- Text Trek: Navigating Classifications, Part 4
Разделы портала
Онлайн-тренинги
| Как выбрать тесты для автоматизации |
| 06.02.2017 16:41 |
|
Перевод: Ольга Алифанова Как вы решаете, какие тесты автоматизировать, а какие оставить для ручного тестирования? Перед тем, как вы начинаете автоматизировать тест, вам нужно выяснить, какую выгоду вы получите от автоматизации этого теста, учитывая время, силы и ресурсы, вложенные в автоматизацию. Ниже перечислены факторы, которые стоит принять во внимание, решая, какие ручные тесты должны или не должны быть автоматизированы. Как говорится, только то, что вы можете что-то автоматизировать, не означает, что вы должны автоматизировать все и вся. Вот некоторые идеи, помогающие выбрать хороших кандидатов на автоматизацию: Тесты, которые должны быть автоматизированы:
В общем и целом, чем чаще прогоняется тест, тем лучше его автоматизировать. Помните также, что тесты – не единственные кандидаты на автоматизацию. Задачи, например, настройка, создание тестовых данных для ручного тестирования – тоже прекрасные идеи для автоматизации. |
Автор: Амир Гахрай (Amir Ghahrai)