Можно ли автоматизировать тестирование удобства приложения
Иногда мы сталкиваемся с непонятными, нелогичными приложениями, многие функции и способы использования которых часто не очевидны. После такой работы редко возникает желание использовать приложение снова, и мы ищем более удобные аналоги. Для того чтобы приложение было популярным, ему мало быть функциональным – оно должно быть еще и удобным. Если задуматься, интуитивно понятные приложения экономят нервы пользователям и затраты работодателя на обучение. А значит они более конкурентоспособные! Поэтому тестирование удобства использования, о котором пойдет речь далее является неотъемлемой частью тестирования любых массовых продуктов.
Тестирование удобства пользования - это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. [ISO 9126]
Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам:
Уровни проведения
Проверка удобства использования может проводиться как по отношению к готовому продукту, посредством тестирования черного ящика (black box testing), так и к интерфейсам приложения (API), используемым при разработке - тестирование белого ящика (white box testing). В этом случае проверяется удобство использования внутренних объектов, классов, методов и переменных, а также рассматривается удобство изменения, расширения системы и интеграции ее с другими модулями или системами. Использование удобных интерфейсов (API) может улучшить качество, увеличить скорость написания и поддержки разрабатываемого кода, и как следствие улучшить качество продукта в целом.
Отсюда становится очевидно, что тестирование удобства пользования может производиться на разных уровнях разработки программного обеспечения: модульном, интеграционном, системном и приемочном. При этом оно целиком и полностью будет зависит от того, кто будет использовать приложение на выделенном конкретном уровне - разработчик, бизнес пользователь системы и т.д.
Советы по улучшению удобства пользования
Для дизайна удобных приложений полезно следовать принципам «пока-йока» или fail-safe. У нас это более известно как «защита от дурака». Простой пример, если поле требует цифровое значение, логично ограничить пользователю диапазон ввода только цифрами – будет меньше случайных ошибок.
Для повышения юзабилити существующих приложений можно использовать цикл Демминга Plan-Do-Check-Act, собирая отзывы о работе и дизайне приложения у существующих пользователей, и, в соответствии с их замечаниями, планируя и проводя улучшения.
Заблуждения о тестировании удобства пользования
1. Тестирование пользовательского интерфейса = Тестирование удобства пользования
Тестирование удобства пользования не имеет ничего общего с тестированием функциональности пользовательского интерфейса, оно лишь проводится на пользовательском интерфейсе равно как и на многих других возможных компонентах продукта. При этом тип тестирования и тесткейсы будут совсем другие, так как речь может идти об удобстве использования не визуальных компонентов (если таковые имеются) или процессе администрирования, например, распределенного клиент-серверного продукта и т.д.
2. Тестирование удобства пользования можно провести без участия эксперта
Не всегда человек не разбирающийся в предметной области способен провести его самостоятельно. Представьте, что тестировщику нужно протестировать удобство пользования стратегического бомбардировщика. Ему придется проверить основные функции: удобство ведения боя, навигации, пилотирования, обслуживания, наземной транспортировки и т.д. Очевидно, что без привлечения эксперта это будет весьма проблематично, и можно даже сказать, что невозможно.
За последние 15 лет автоматизация тестирования прошла долгий путь. Изменились цели и роль сервиса в ИТ-процессах: когда-то она внедрялась только для сокращения времени тестирования, а сейчас к этому добавляется обеспечение оптимального тестового покрытия и более эффективное использование тест-кейсов.
Таким образом, внедряя данный сервис в цикл разработки сегодня, компании преследуют комплексную и важную цель – получить высококачественный программный продукт, и как можно быстрее.
Причина в том, что изменения в логике уже разработанной функциональности, а также выпуск новых версий ПО требуют проведения дополнительных проверок новой функциональности, регрессионного тестирования, а также регулярной поддержки автотестов и их изменения согласно актуальным требованиям к системе.
Несмотря на эти трудности, ИТ-специалисты все больше понимают роль данного сервиса для своих бизнесов и не сдаются, стремясь создать надежное и стабильное решение по автоматизации.
В данной статье мы обсудим цели автоматизации, ее плюсы и минусы, а также расставим все точки над i в вопросе сравнения ручного тестирования с автоматизированным.
Основы автоматизации тестирования
В последнее время в автоматизации часто используются ИИ, машинное обучение и предсказательная аналитика, которые дают ей новые преимущества и делают ее «умнее» и эффективнее.
Для достижения значимых результатов на проекте компании должны учитывать, что автоматизированное тестирование – это не просто сервис для замены ручных проверок или дополнительный способ снизить затраты. В самом общем смысле оно нацелено на то, чтобы обеспечить высокое качество ПО быстрее, вывести процесс QA на новый уровень, а также эффективно реализовывать DevOps и Agile.
Что дает автоматизация тестирования?
Чтобы получить максимальный эффект от сервиса, нужно обращать внимание как на качество самих автотестов, так и на качество процессов по внедрению автоматизации, а также понимать, когда нужно автоматизировать, а когда этого делать не стоит.
| Автоматизация полезна в следующих случаях | Автоматизация не будет полезной, если |
| Ваша первоочередная задача – сэкономить время проектной команды. | Для выполнения тестирования нужен человеческий интеллект и интуиция. |
| Тесты должны выполняться для каждой сборки приложения. | Процесс тестирования ограничен интуитивными или исследовательскими проверками. |
| Ваш проект длительный или комплексный (состоит из различных итераций). | Требования, относящиеся к существующей функциональности, часто изменяются. |
| На выполнение тест-кейсов тратится много времени и ресурсов. | Нужно провести тестирование только единожды. |
| Проводится нагрузочное или стресс-тестирование. | |
| Нужно сократить текущий объем тестирования с целью успеть к определенным срокам. |
Как найти баланс между ручным и автоматизированным тестированием?
Ручное тестирование все еще играет важную роль в процессе обеспечения качества ПО. Однако в условиях процесса непрерывного тестирования (continuous testing) оно может быть крайне ресурсозатратным.
Между тем автоматизация увеличивает скорость выполнения проверок и экономит ресурсы команды QA-инженеров. Автоматизированные проверки уменьшают количество тестов, которые должны быть выполнены вручную (например, во время тестирования мультиязычных сайтов), но, в то же время, не исключают их.
В некоторых случаях автоматизация применяться не может. Приведем примеры:
- Тестирование пользовательского интерфейса. Ручное тестирование проверит общий вид приложения (четкость изображений, расположение и отображение элементов графического интерфейса при разных разрешениях экрана и др.), а также отдельно взятые компоненты (например, цвет шрифта – сможет ли конечный пользователь его легко воспринимать). Ручные проверки покажут, соответствует ли графический интерфейс предпочтениям потребителей.
- Тестирование удобства использования. Оно ответит с точки зрения пользователя на вопрос, является приложение простым в использовании или нет.
- Интуитивное тестирование. Это тип проверок, при котором тест-кейсы не создаются заранее, а QA-инженеры тестируют приложение и исследуют его «на ходу».
В идеале нужно научиться сочетать ручное тестирование и автоматизацию так, чтобы они приумножали ценность друг друга, а не приуменьшали.
Рассмотрим 5 случаев, когда такая «командная работа» будет особенно удачной:
- Вы используете как автоматизированные, так и ручные проверки для тестирования различных аспектов одной и той же функциональности.
- У вас есть цель быстрее выпустить новую версию продукта на рынок, но, чтобы эту цель достичь, нужно ускорить сам процесс тестирования.
- Тесты являются «полуавтоматизированными», а для завершения теста нужно провести ручную проверку. В качестве примера можно привести тестирование пользовательского интерфейса для различных браузеров и разрешений экранов. Автотест откроет каждый браузер в нужном разрешении, перейдет по ссылкам (чтобы открыть страницу), сделает скриншот, а ручной тестировщик определит, насколько корректно отображается содержимое страницы.
- Ручные тесты должны быть проведены после завершения автоматизированных тестов, например, чтобы выявить проблемы с пользовательской стороны.
- Частые выходы новых версий ПО сложного продукта (масштабное регрессионное тестирование).
Нужно также иметь в виду, что, увеличивая общее тестовое покрытие, потребуется больше времени на поддержку тестовых сценариев. Хорошее решение по автоматизации тестирования не должно быть трудозатратным в такой поддержке.
Как повысить эффективность тестирования автоматизации?
- Запускать автотесты как можно чаще, чтобы быстрее реагировать на изменения, быстрее находить дефекты и следить за тем, чтобы тестовое покрытие было оптимальным.
- Группировать тесты по функциональности в тестовые наборы, чтобы упростить обновление связанных тест-кейсов при изменении функциональной области.
- Формировать отчеты с разными артефактами (скриншоты, логи), чтобы можно было легко выявить причину ошибки.
- Разрабатывать тест-кейсы таким образом, чтобы изменение положения элементов на странице не приводило к падению автотеста и необходимости его обновления.
- Хранить тестовые данные в конфигурационном файле отдельно от шагов автотестов.
- Разрабатывать тесты в наборе таким образом, чтобы они оставались независимыми друг от друга, а неудачный запуск одного из них не влиял на остальные.
Согласно гайду DZone по автоматизированному тестированию 2019 года, продолжает набирать обороты стратегия «shift left», согласно которой привлечение команды тестировщиков происходит на ранней стадии разработки ПО.
По сравнению с результатами, полученными в 2018 году, количество респондентов, которые внедряют автоматизированное тестирование ПО на этапе разработки, выросло на 12%. Количество опрошенных ИТ-специалистов, начавших автоматизацию на этапе обеспечения качества, сократилось на 9%.
Что касается ручного тестирования, то, по сравнению с предыдущим годом, модель «shift left» прослеживается слабо. На контрасте с 2018 годом, процент опрошенных респондентов, начавших тестирование программного обеспечения вручную на стадии разработки, снизился на 2%. Количество специалистов, внедряющих ручное тестирование на этапе стейджинга, увеличилось на 4%.
Источник: Гайд DZone по автоматизированному тестированию от 2019 года
Когда автоматизировать, а когда применять ручное тестирование?
Определим три основных фактора, которые следует учитывать при ответе на этот вопрос.
| Фактор | Вспомогательные вопросы |
| ROI (окупаемость инвестиций) | Окупят ли себя ресурсы, потраченные на автоматизацию конкретного сценария? |
| Сложность теста | Можно ли тест автоматизировать? Есть ли смысл оставлять его ручным? |
| Стабильность системы | Насколько приложение и его отдельные компоненты стабильны? Могут ли они быть покрыты автоматизированными тестами? Где, из-за часто меняющейся функциональности, понадобится помощь ручных тестировщиков? |
Достоинства и недостатки автоматизации тестирования
Автоматизация может быть весьма прибыльной, если построить грамотный процесс по ее внедрению. Чуть позже мы остановимся на ее достоинствах, а пока обсудим другую сторону медали и рассмотрим, какие ловушки автоматизации нам нужно учитывать.
- Внедрение автоматизации – это не одноразовое действие, так как нужно тратить время на поддержку актуальности автотестов.
- Количество новых регрессионных дефектов всегда будет немного меньше по сравнению с теми ошибками, что будут обнаружены в новой функциональности.
- Иногда результаты тестирования нужны в течение нескольких часов, особенно если говорить о проверках недавно внедренной функциональности. В этом случае эффективнее перейти к ручному тестированию и получить результаты как можно скорее.
Тем не менее, плюсы автоматизации для любого проекта могут быть безграничными. Давайте остановимся на наиболее весомых достоинствах.
| Преимущества автоматизации тестирования | Эффект |
| Влияние на ROI | Несмотря на то что для написания тест-кейсов требуются определенные ресурсы, окупаемость у данного подхода для больших и долгосрочных проектов может быть огромной. Это можно объяснить тем, что тесты легко настраиваются и могут многократно использоваться. Внедряя автоматизацию, можно значительно снизить стоимость каждого часа, затрачиваемого на проверки, а также найти наиболее трудно обнаруживаемые баги. |
| Быстрая обратная связь о качестве приложения | Автоматизация может дать возможность быстро собрать обратную связь относительно состояния программного продукта и обеспечить более высокую эффективность работы команды разработчиков. Это улучшает интеграцию между инженерами по обеспечению качества, программистами, менеджерами и другими участниками процесса работы над ПО. |
| Более раннее обнаружение дефектов программного обеспечения | Поскольку автоматизация тестирования помогает увеличить скорость разработки, она становится более рентабельной и значительно упрощает выявление ошибки и ее устранение на ранней стадии жизненного цикла системы. |
| Экономия времени | Автоматизация регрессионных тестов экономит время QA-инженеров и освобождает больше ресурсов для проведения интуитивных проверок и других активностей по тестированию. Кроме того, при корректном использовании, автоматизированные тесты могут выполняться с минимальной вовлеченностью человека или вообще без него. |
| Безопасность тестовых данных | Эффективность проверок во многом зависит от качества используемых тестовых данных. Создавать их вручную довольно ресурсоемко, поэтому тестирование часто проводится на копиях «живых» БД. Автоматизированные тесты могут быть спроектированы таким образом, чтобы они создавали и получали необходимые данные, изменяли их (не затрагивая другие) и возвращались в исходное состояние. |
| Быстрая скорость выполнения проверок | Автоматизация позволяет проходить этапы проведения тестов быстрее, чем это делает человек. Это особенно актуально для DDT (тестов, управляемых данными), поскольку одни и те же проверки проводятся много раз, но с разными наборами данных. |
Свяжитесь с нашими специалистами, чтобы получить персональную консультацию по автоматизации тестирования.
Непрерывное тестирование ускоряет поставку программного обеспечения, делая весь процесс тестирования более быстрым. А благодаря незамедлительной обратной связи, которая помогает уже на самых ранних этапах выявлять ошибки и другие проблемы в приложении, гарантирует, что команды разработки будут создавать высококачественные и надежные приложения. Кроме того, сама способность организовать и проводить эффективное тестирование может значительно снизить затраты в компании, как за счёт экономии времени разработчиков, так и вследствие создания добротного конвейера поставки, в котором они могут быстро вносить изменения в код с минимальными рисками нарушения работоспособности приложения в продуктивной среде.
Главным элементом непрерывного тестирования является его автоматизация, что даёт множество преимуществ:
- Быстрое получение обратной связи
- Аккуратное и тщательное тестирование
- Высокое покрытие тестами
- Быстрое обнаружение ошибок
- Повторное использование тестов
- Более короткие сроки поставки
- Адаптация для DevOps
- Экономия времени и денег
Несмотря на перечисленные выше преимущества, начальные вложения в автоматизацию тестирования могут быть очень высоки. Приобретение ПО, затраты на обучение работе с ним, проектирование и создание автоматизированных тестов — всё это требует немалых времени и денег. Однако, как только вы начинаете всё активнее разрабатывать новые функции в своём продукте, ручное тестирование в конечном итоге выходит дороже, а автоматическое — дешевле.
Кроме того, следует понимать — не всё нужно автоматизировать и не всё можно автоматизировать. Поэтому важно тщательно оценить, изучить и проанализировать свои требования, прежде чем решить, как лучше всего организовать автоматизацию тестирования. Когда следует автоматизировать тесты, а когда — нет?
Какие тесты можно автоматизировать
Практически каждая команда разработчиков работает над проектом, который критически зависит от сроков, а значит, что времени на применение всех передовых практик всегда не хватает. То же самое относится к стратегии тестирования, поскольку тестирование как вид деятельности не всегда является приоритетом для команд разработки. Нужно попытаться найти баланс и сделать правильный выбор в зависимости от типа разрабатываемого приложения, временных рамок, используемого ПО для тестирования и имеющихся ресурсов. Вот важные типы тестов, которые можно автоматизировать.
Модульное тестирование
Это отличный способ приступить к автоматизации тестирования, поскольку модульные тесты направлены лишь на часть кода, в ходе которых он проверяется на работоспособность, и не зависят от других частей приложения. Таким образом, разработчики получают больше информации о работе созданной функциональности. Благодаря современной культуре тестирования многие команды используют методологию разработки через тестирование (test-driven development, TDD), при которой они начинают составлять тесты до написания кода. Таким образом гарантируется качество и кода, и тестов.
Приоритетные функции
Если у вас в плане десятки функций и сжатые сроки на их разработку, вы можете выделить среди них те, что имеют высокую вероятность сбоев. Тестирование подобных функций нужно начинать как можно раньше.
Регрессионные и интеграционные тесты
Интеграционные тесты используются для определения того, работают ли отдельные модули в приложении как группа, а регрессионные тесты проверяют, что функции приложения работают должным образом. Эти два теста обычно выполняются после изменений / улучшений приложения, поэтому тестировщики постоянно проводят эти тесты. Автоматизация таких тестов экономит огромное количество времени, высвобождая его для выполнения других типов тестов.
Нагрузочные тесты и тесты производительности
Для тестов производительности и нагрузочных тестов нет альтернативы в виде ручного тестирования, поскольку необходимо моделировать сотни или тысячи пользователей, работающих в разных условиях: из-под разных браузеров, в разных часовых поясах, использующих разные операционные системы и т.п.
Повторяющиеся тестовые сценарии
Это очень важные тесты, которые команды разработки вынуждены запускать чуть ли не постоянно. Например, работоспособность функции входа в систему — она обеспечивает возможность пользоваться приложением, влияя на его доступность. Поэтому лучше автоматизировать тестирование и сэкономить прорву времени тестировщиков и разработчиков.
Базовая функциональность (дымовые тесты)
В отличие от других тестов, дымовые тесты не такие сложные и относительно легко реализуемые. При этом прохождение этих тестов имеет решающее значение. Они информируют команды разработки о том, правильно ли работают базовые функции приложения, например: открывается ли окно входа в приложение, могут ли пользователи войти в систему, доступен ли API, доступно ли приложение из разных мест и т.п.
Какие тесты не нужно автоматизировать
Всё больше и больше узнавая о преимуществах автоматизации тестирования и глубоко проникаясь ими, можно задаться закономерным вопросом — а почему бы не автоматизировать вообще все тесты? Ответ в виде «не нужно пытаться автоматизировать всё» идёт вразрез с DevOps-мышлением, в котором явная установка на автоматизацию всего и вся. Перед планированием автоматизации тестирования нужно учесть несколько факторов. Вот примеры тестов и сценариев, для которых не нужна автоматизация.
Пользовательский опыт (UX)
Эта область тестирования не может быть автоматизирована. Многие аспекты UX-проектирования требуют ручного, долгого и утомительного тестирования. Например, когда разработчики хотят понять, насколько легко пользователи могут зарегистрироваться на веб-сайте, или проверить, какие наборы полей дают лучшую видимость профилей пользователей. Подобные тесты должны быть проведены вручную.
Стадии ранней разработки
Когда какая-то функция только-только разрабатывается, в её код постоянно вносятся изменения, а это может затруднить составление и теста. На ручное тестирование этих функций уходит меньше времени, поэтому следует дождаться стабильной версии.
Функциональность, не имеющая большой важности
Автоматизация тестирования требует времени и усилий, поэтому следует автоматизировать тестирование не всех функций, разрабатываемых в рамках проекта, а лишь самых важных функций. Низкоприоритетные можно оставить в стороне и продолжить тестировать их вручную.
Тесты без понятных результатов
Командам разработки необходимо знать ожидаемый результат для каждого входа функции. Если результаты непонятны, то и автоматизация не предоставит необходимых доказательств того, что функция работает должным образом.
Тесты, которые невозможно полностью автоматизировать
Если автоматизирована половина теста, а другая половина так и осталась выполняемой вручную, то это приводит к сложности и дополнительным расходам, поскольку проведение такого теста требует много времени, а достоверность его под большим вопросом. Было бы рациональнее продолжать тестирование таких функций вручную.
Фреймворки автоматизированного тестирования
В каждой команде разработки и поставки ПО группа QA отвечает за разработку, внедрение и выполнение тестов. Для каждого типа тестирования должен быть определён тестовый сценарий, принципы, правила и инструменты для проведения. Фреймворк тестирования — это набор этих руководств, инструментов и практик, который помогает инженерам-тестировщикам эффективно выполнять тестовые сценарии.
Существуют разные фреймворки для разных целей тестирования. Вот некоторые из самых популярных типов фреймворков для автоматизированного тестирования:
- Модульный: приложение разделено на отдельные модули, и каждый модуль тестируется в изолированном состоянии
- Линейный: составление и исполнение тестовых скриптов. Тестировщики пишут тестовые сценарии последовательно, выполняя их затем для каждого отдельного тест-кейса
- Библиотечная архитектура: создан на основе модульного фреймворка тестирования, с той лишь разницей, что содержит функции для многократного использования
- Управляемое данными тестирование: тестовые скрипты выполняются и верифицируются на основе данных, которые хранятся в центральном хранилище данных или базе данных (SQL, ODBC-ресурсы, csv или xls файлы)
- Тестирование по ключевым словам: в данном фреймворке не обязательно иметь навыки программирования, поскольку ключевые слова, используемые при создании тестов, отделены от технического кода. Тестировщику достаточно иметь представление о всём наборе действий, реализованных во фреймворке
- Гибридный: комбинация из различных фреймворков.
Главная цель всех команд разработчиков программного обеспечения — обеспечить быструю поставку качественного и надежного программного продукта. Чтобы обеспечить быстрый и эффективный процесс поставки, необходимо непрерывное тестирование. Автоматизация — ключ к тому, чтобы разрабатываемое ПО могло быстро пройти через все стадии конвейера разработки и предоставить клиентам свои функции. Однако, это не означает, что команды должны вкладывать всё свое время и ресурсы в автоматизацию тестирования. Команды должны понимать, что можно и нужно автоматизировать, а что не стóит. Правильный выбор охвата тестов на ранних этапах разработки имеет большое значение.
Специалисты по автоматизации тестирования (SDET, то есть Software Development Engineer in Test) помогают ускорить проведение тестов, а значит, быстрее выпускать свежие релизы IT-продукта. Как правило, это наиболее необходимо в масштабных приложениях с большим количеством бизнес-функций.
Рассмотрим, как бизнесу понять потребность в автотестах, с чего начать и как оценить эффективность результатов.
Когда на проекте нужна автоматизация
При работе с масштабными IT-решениями, например, системами дистанционного банковского обслуживания (ДБО), важно постоянно тестировать не только работу отдельных функциональностей, но и их взаимодействие. В условиях сжатых сроков, когда ведущие банки каждый месяц обновляют свои приложения, проверить все вручную невозможно – на это как минимум не хватит времени.
При создании IT-продуктов для бизнеса обычно сочетают два подхода:
осуществляют проверки вручную, с помощью специалистов по обеспечению качества (QA);
комбинируют ручное тестирование и автоматизацию отдельных тест-кейсов, смоук- и регрессионных тестов.
Как правило, мы привлекаем экспертов SDET для решения следующих задач:
Автоматизация рутинных и частых проверок, снижение нагрузки на QA-специалистов.
Контроль основных функций приложения и отслеживание изменений в продукте.
Возможность проводить тестирование с большим количеством мобильных устройств, версий браузеров и операционных систем.
Тестирование производительности приложения в условиях одновременной работы с большим количеством данных и пользователей.
Критерии автоматизации тестирования
Существует ряд признаков, указывающих на то, что пора задуматься о подключении SDET-специалиста на проект. Наличие их является своеобразными маркерами необходимости этого процесса.
Работы на проекте будут продолжаться минимум полгода
Если разработка проекта рассчитана на полгода и более, чаще всего за это время у команды накапливается некоторая база стабильного и неизменного функционала, тестирование которого можно автоматизировать.
Наличие продолжительных регрессионных тестов
Если повторные проверки (регрессионные тесты) занимают 3-4 дня и более, то автотесты помогут ускорить этот процесс за счет параллельного запуска, ночных прогонов и автоматической генерации отчетов.
Большое количество багов выявляется на поздних этапах тестирования
Внедрение автоматизации не решит такого рода проблемы на 100%, поскольку многое зависит от проекта и процессов на нем. Однако в данном случае у автотестов есть существенное преимущество – они могут запускаться в любое время, в том числе на этапе разработки. Это позволит выявлять возможные проблемы и ошибки раньше, чем задача будет передана в тестирование.
Тест-кейсы требуют создания большого количества тестовых данных или заполнения больших форм
В данном случае автоматизация тестирования решит проблему человеческого фактора. Автотест выполняет каждый раз одинаковую последовательность действий и проверяет один и тот же ожидаемый результат. Кроме того, заполнение и генерация данных в автоматическом режиме выполняется в разы быстрее, чем в ручном.
Тест-кейсы в основном проверяют функциональное поведение, а не интерфейс и юзабилити
Автоматизация тестирования может принести положительные результаты при проверке функциональности, тогда как визуальное тестирование эффективнее проводить вручную.
Если есть проблемы с производительностью и\или стабильностью работы систем
Проверить работу приложения или отдельных сервисов, используя тысячи одновременно работающих пользователей вручную – это очень трудно или даже невозможно. Автоматизированные сценарии, запущенные в тысячи потоков, создадут условия, необходимые для оценки работоспособности и производительности приложения.
На основании выполнения большинства из перечисленных условий, может быть принято решение о внедрении автоматизации тестирования на проекте.
С чего начинается автоматизация тестирования
После того, как решение о внедрении автоматизации принято, следует определить цель внедрения автоматизации тестирования, а также объект тестирования, ресурсы и процессы.
Наиболее частые цели автоматизации тестирования:
Сокращение time-to-market
Уменьшение времени от постановки задачи до выпуска приложения на production. SDET-специалисты помогают сократить время на тестирование устоявшейся функциональности приложения. Вместо того, чтобы проходить регрессионные кейсы руками, они автоматизируются. Прогон автотестов занимает в разы меньше времени, чем ручная работа. Кроме того, его можно запланировать на ночное время и запустить в несколько потоков, в зависимости от ваших аппаратных ресурсов.
Улучшение качества продукта и оптимизация затрат на тестирование
За счет автоматизации регрессионных кейсов отпадает необходимость в найме специалистов по ручному тестированию для прохождения постоянно увеличивающегося на развивающемся проекте регресса.
Проведение тестирования нагрузки и исследование производительности
Автоматизация позволяет эмулировать действия реального пользователя в системе в нужном количестве и нужного типа для проведения исследований нагрузки. Это позволяет моделировать различные ситуации повышенной нагрузки на систему и предугадать её поведение в таких ситуациях.
Какие ресурсы необходимы
Прежде чем приступать непосредственно к автоматизации, следует проанализировать условия, в которых предстоит работать, и уточнить, готовы ли необходимые ресурсы для ее старта:
Нужно выяснить, насколько вписываются ожидания клиента о времени запуска автоматизации в предполагаемые затраты на эти работы. Практика показывает, что затраты на SDET начинают окупаться в среднем спустя полгода после старта. Поэтому уточнение масштабов долгосрочности проекта является одним из ключевых факторов в принятии решении о необходимости автоматизации тестирования.
Следует выяснить, каков будет состав команды SDET. Возможны два варианта:
- у заказчика уже есть свои специалисты по автоматизации тестирования и им нужны просто дополнительные руки. Здесь имеет место вариант подключения к уже существующей команде “на усиление”.
- заказчик начинает автоматизацию “с нуля” без имеющихся собственных специалистов в этой области. В этом случае условия работы представляются совершенно иными, нежели в первом варианте.
Необходимо сразу определиться, выстроен ли на проекте процесс CI/CD, кто займется настройкой окружения для тестирования (SDET или DevOps), стенды для тестирования и доступ к ним у участников команды.
Инструменты для разработки и тестирования
До старта процесса разработки тестового фреймворка нужно определиться с используемыми технологиями и языками.
Следует произвести анализ проекта и в зависимости от его особенностей и требований к автоматизации выбрать наиболее оптимальный стек. При этом нужно учесть и навык работы специалистов, которые будут поддерживать и развивать проект автоматизации с этим стеком.
Как оценить эффективность автоматизации
При реализации проекта можно собрать метрики эффективности автоматизации, чтобы впоследствии проанализировать их и рассчитать процент эффективности.
Собираемые метрики можно разделить на две ключевые группы. Это:
Количество часов, затраченных QA на прохождение тест-кейса.
Количество часов, затраченных SDET на автоматизацию (актуализацию) тест-кейса.
Упрощенная формула расчета выглядит как Кол. ч. QA / Кол. ч. SDET * 100%
Пример: если на проекте впервые внедрена автоматизация тестирования, то ожидаемая экономия времени и других ресурсов за год в среднем составляет 140-150%. При этом эффективность автоматизации нарастает пропорционально времени ее использования, в частности, до 240% к концу второго года.
Если показатель экономии ресурсов со временем начинает снижаться, мы рекомендуем провести аудит тестирования и автоматизации тестирования для выявления возможных проблем, ошибок и узких мест.
Для расчета эффективности автоматизации важно иметь источник достоверной информации о временных затратах на автоматизацию тестирования. В частности, источником данных может быть система таск-трекинга на проекте, такая как Jira.
Из практики
Рассмотрим пример одного из наших проектов, в котором было порядка 700 тест-кейсов, каждый из них проходили от 70 до 100 раз в год. У нас была возможность автоматизировать 75% кейсов, а остальные требовали проверки вручную.
- 30 часов при ручной проверке всех кейсов.
- 8 часов после автоматизации (ночной прогон тестов без участия человека).
Помимо ночного прогона, нам требовалось около 8 часов на проверку тех кейсов, которые невозможно было покрыть автотестами, и 6 часов – на анализ результатов автотестов и проверку отказов в случае необходимости. Таким образом, автоматизация тестирования позволила снизить затраты времени специалистов с 30 до 14 часов. В среднем, этот подход позволяет экономить как минимум от 30 до 50% времени и уделить больше внимания развитию и улучшению продукта.
Выводы
Сочетая ручное тестирование и автотесты, мы контролируем качество ПО. SDET-специалисты, как правило, необходимы при реализации крупных IT-проектов, в которых задействованы несколько команд, со сложными алгоритмами и бизнес-логикой. За счет автоматизации мы снижаем риски ошибок, недопустимые в условиях жесткого расписания релизов.
В разработке автотестов используем наиболее востребованные языки программирования – Java, Python, Kotlin и др. В числе технологий и инструментов, с которыми мы работаем, Appium, TestNG, JUnit, RobotFramework, Pytest, Selenium, Selenide, Allure Report, TeamCity, Jenkins, JMeter.
Читайте также: