Автор: Деннис Мартинез (Dennis Martinez)
Оригинал статьи
Перевод: Ольга Алифанова

 В приложении можно много чего протестировать. Как разобраться, на чем сконцентрироваться, при таком обилии вариантов?

Как тестировщики, мы можем бросить беглый взгляд на любое приложение или сайт и перечислить десятки, сотни вещей, нуждающихся в валидации. Неважно, какого размера и охвата приложение – в нем в любом случае есть кажущееся бесконечным количество сценариев, которые надо пройти. И это только на уровне пользовательского интерфейса, не зная тонкости происходящего за сценой. На бэкэнде наверняка тоже хватает, чего протестировать. Временами кажется, что работа QA никогда не заканчивается.

Иногда сложность работы тестировщиком не связана с инструментарием или тактикой ежедневной работы с целью убедиться в качестве нашего приложения. Зачастую сложность работы в том, чтобы знать, что нуждается в тестировании. В идеале хотелось бы думать, что мы должны и можем протестировать все, что мы знаем и узнаем о проекте. Но это не оправдано и даже не возможно, даже при большом наборе автоматизационных практик в нашем распоряжении.

Каждый тестировщик, каждая компания будут по-разному думать и оценивать, что нуждается в тестировании, и что больше всего выиграет от тест-автоматизации. В основном такие размышления можно разделить на две категории: концентрация на исключительно "счастливом пути", и желание копнуть глубже во все "несчастливые пути" и граничные случаи, которые только можно раскопать.

Ни один из этих подходов ни плох, ни хорош, и к тому же они не единственные доступные стратегии тестирования. В зависимости от вашей ситуации в вашем проекте есть области, которые нуждаются в особом или даже абсолютно ином внимании по сравнению со схожими проектами. Приложения, инструменты и команда с шансами повлияют на то, как вы автоматизируете свои тесты.

Тестирование универсальной формы регистрации

Все, пользовавшиеся интернетом за последнее десятилетие, сталкивались с очень распространенной функции в практически любом современном веб-приложении: формой регистрации.

Формы регистрации для Google Gmail, Amazon AWS и Spotify

Этот скриншот демонстрирует примеры различных форм регистрации для разных SaaS-сайтов. Помимо визуальных аспектов дизайна и брендинга каждой страницы можно заметить, что там есть поля, запрашивающие схожую информацию – или обязательную, или опциональную. Эти службы попросят ваш email-адрес, пароль, и другие данные вроде полного имени, уникального имени пользователя, и т. д.

Допустим, вы присоединились к SaaS-стартапу в качестве инженера-автоматизатора, и вам нужно автоматизировать часть тест-покрытия формы регистрации их сайта. Регистрация – одна из первых точек входа для клиентов любого онлайн-сервиса, и очень важно убедиться, что эта часть работает. Если ваши клиенты наткнутся на проблемы в ходе регистрации, они с шансами потеряют доверие к вашей компании и уйдут, чтобы никогда не вернуться.

Возвращаясь к различным способам мыслить о тестировании: вы можете подойти к этой задаче различными способами (помните о том, что выбор ими не ограничен):

Концентрация на "счастливом пути

Вы напишете один-единственный тест-кейс, покрывающий полный цикл регистрации от старта до финиша. Вы можете сконцентрироваться на заполнении каждого поля только валидными данными, убеждаясь, что пользователь может успешно отправить форму, и ни в чем больше.

Углубляясь в требования

Вы также можете разобраться в скучных деталях формы регистрации и написать различные кейсы для валидации специфических требований. К примеру, можно создать короткие тест-кейсы для:

• Проверки, что все обязательные поля заполнены, перед отправкой формы;
• Проверки полей, требующих специального формата – например, email-адреса.
• Наличия проверки требований к паролю.
• Верификации, не зарегистрирован ли с этим email-адресом другой пользователь.
• Подтверждения, что выбранное пользователем имя доступно для регистрации.

Какой путь избрать для автоматизации?

У обоих примеров есть и плюсы, и минусы. Покрытие "счастливого пути" проще написать и поддерживать, но оно не убедится в реализации специфических требований к форме. Более глубокая работа автотеста может покрыть все требования компании к регистрации, но потребует больше времени и внимания при поддержке.

Вне зависимости от выбранного варианта результат у обоих подходов одинаков – валидация, что форма регистрации работает, и пользователи могут создать новую учетную запись для использования в вашем сервисе. Неважно, избрали вы единый путь или разветвили ваши тесты, итог будет идентичным. Но это все еще не отвечает на вопрос, какой подход избрать, автоматизируя тесты.

У каждого тестировщика есть своя точка зрения на то, как разбираться с автоматизацией, но в итоге наибольшее значение имеет то, что важнее всего для вашей компании и бизнеса.

Если вы работаете в обычной коммерческой фирме, то самое важное – зарабатывать деньги, чтобы поддерживать бизнес живым и растущим. В некоммерческом секторе фокус будет на миссии организации. В зависимости от устремлений вашей компании нужно всегда приводить автоматизацию в соответствие с ними. В конце концов, если компания не зарабатывает деньги или не имеет цели для этого, ей бы и не понадобилась такая работа. Приоритеты и стратегии тестирования должны базироваться на помощи в достижении высокого качества в организации в зависимости от ее целей.

Многие тестировщики тратят чересчур много времени, концентрируясь на деталях, которые, обеспечивая пристойное покрытие, не дают возможности использовать время с максимальной выгодой. К примеру, важно ли иметь автоматизированные регресс-тесты, валидирующие требования к паролю в форме регистрации? Стоит ли ее вообще тестировать? Если вы не знаете, насколько это значимо для бизнеса, то можете потратить время на что-то ненужное. Концентрация на важном делает вашу автоматизацию эффективной, а вовсе не выбранные инструменты или стратегии.

Иногда мы можем разойтись во мнениях, что считать важным. Как правило, это комбинация QA, не до конца понимающих, что бизнес считает наиболее важным, и бизнеса, не до конца понимающего, какие области нуждаются в крепком наборе автотестов. Коммуникация – ключевой фактор для удостоверения, что все заинтересованные лица понимают, как получить максимально качественный результат в конце процесса.

Реальные стратегии тест-автоматизации

Подход к созданию автотестов для вашего приложения будет зависеть от множества факторов. Размер и сложность приложения, структура команды, внешние дедлайны, требования к безопасности и бесчисленное количество прочих деталей определят вашу наилучшую стратегию. Держа это в уме, большинство QA-команд следуют схожему подходу к тест-автоматизации. Ниже – несколько практичных и эффективных стратегий, основанных на моем опыте работы в разных командах и проектах.

Используйте end-to-end тесты только для "счастливого пути"

End-to-end тесты медленнее других форм автоматизированного тестирования и требуют много внимания при долгосрочной поддержке. У этих тестов плохая репутация, потому что тестировщики пытаются впихнуть в свои тест-наборы максимум покрытия. Это приводит к плохой производительности и сложностям, мешающим плавной работе. Умеренное применение end-to-end тестов и проход через меньшее количество общих зон даст вам убедиться, что приложение хорошо работает, и потребует меньше времени с точки зрения поддержки.

Копайте глубже при помощи юнит, функциональных и API-тестов

Эти типы автотестов меньше, быстрее и куда проще в поддержке, чем end-to-end тесты, что делает их идеальными кандидатами для тщательного покрытия. Тут можно покрывать как "счастливый", так и "несчастливый путь" в небольших участках приложения, меньше беспокоясь о стабильности и обслуживании. Хорошая комбинация юнит-тестирования, функционального тестирования и тестирования API сильно поможет держать марку качества ваших приложений.

Учитывая, что эти тесты проще внедрять и выполнять, у любого проекта должен быть комплекс этих тестов, написанных разработчиками и тестировщиками. Сейчас инструменты и фреймворки разработки ПО как никогда упрощают задачу по созданию таких тестов, поэтому нет никаких оправданий отсутствию тестового покрытия в этой области.

При необходимости подключайте другие формы тестирования

В зависимости от тестируемого приложения и бизнес-требований, стоит исследовать другие инструменты и библиотеки автоматизации, если возникнет нужда в более специализированном тестировании. К примеру, если производительность критически важна для вашего приложения, добавьте к автоматизации тестирование производительности и нагрузки. Еще пример – внедрение контрактного тестирования микросервисов, общающихся через API.

Ключ к успеху тут в добавлении этих типов тестов по необходимости, особенно в быстро развивающихся системах. К примеру, добавление тестов производительности, когда система еще вовсю разрабатывается, не даст вам точных результатов. Вы можете начать настраивать инструменты заранее, если знаете, что они вам понадобятся, но зачастую лучше добавлять эти тесты после того, как вы разобрались с другими вышеупомянутыми формами тестирования.

Заключение

Автоматизаторов может ошарашить присоединение к новому проекту, когда не знаешь, с чего начать работу. В любом приложении масса сценариев, для которых можно сразу же начать писать тест-скрипты. Как определить, на чем сконцентрироваться, чтобы получить от тестирования максимум пользы?

Хорошее практическое правило – всегда начинать с нужд бизнеса. Многие тестировщики пропускают этот шаг и в итоге создают наборы тестов, которые не приносят ощутимой пользы в работе. Поговорите с командой и другими участниками проекта, чтобы определить, что наиболее важно для бизнеса, а затем базируйте свою стратегию на этих высокоприоритетных сегментах.

Когда вы знаете, что важнее всего для бизнеса и организации, настанет момент для внедрения вашей работы. Ваша стратегия зависит от проекта и его конкретной ситуации. Однако беспроигрышный вариант – это копать глубже при помощи легких в поддержке тестов, добавляя немного расширенных end-to-end тестов, чтобы долгосрочная поддержка не утянула вас на дно. Если ваш проект этого требует, добавляйте дополнительные типы тестирования в этот набор после концентрации на создании солидного фундамента для автоматизированного тестирования.

Помните, нельзя протестировать в приложении абсолютно все, особенно если это развивающаяся, быстро меняющаяся система. Выбирайте точки приложения сил вместо того, чтобы нырять в работу очертя голову, и у вас будет техничная и стабильная автоматизация.

Обсудить в форуме