Само по себе тестирование — это дорогой процесс, поэтому все стремятся его удешевить. Теоретически, ради удешевления можно сократить зарплату тестировщиков, но это обязательно вызовет недовольство сотрудников и скажется на качестве тестирования.
Поступать так радикально необязательно. Есть и другие способы оптимизировать тестирование, причем без потери качества. Именно эти способы мы рассмотрим в этом уроке.
Как оптимизировать тестирование
Рассмотрим самые распространенные способы оптимизировать затраты на тестирование без потери качества:
Написание тест-кейсов. Они подробно описывают весь контекст, тем самым помогая быстрее проверять функциональность продукта. С тест-кейсами тестировщикам не нужно каждый раз вспоминать, что именно нужно проверить, как это проверить, где взять тестовые данные.
Использование систем управления тестированием (Test Management System или TMS). Они ускоряют тестирование, позволяя тестировщикам легко находить нужные тест-кейсы и быстро проставлять статусы. Другими словами, такие системы автоматизируют рутинные задачи, что особенно важно, если приходится регулярно тестировать тысячи тест-кейсов.
Выбор значимых значений и авто-тесты. Чтобы тщательно проверить код, необязательно тестировать его со всеми возможными данными — достаточно выбрать только значимые значения. Будет еще эффективнее, если дополнить такой подход автоматизацией. Автоматические тесты выполняются быстро, без ошибок и без участия человека. Так они освобождают время тестировщика на более важные задачи.
Пирамида тестирования. Она помогает соблюдать верную иерархию уровней тестирования. Это эффективный инструмент с множеством нюансов, поэтому в подробностях мы обсудим его далее в курсе.
Сдвиг тестирования влево. Это стратегия, при которой тестировщики очень рано подключаются к работе над продуктом. Чем раньше мы находим ошибки, тем проще их исправлять. Поэтому тестирование стоит начинать не после разработки, а раньше — на этапе обдумывания идеи, формирования требований и дизайна интерфейса. При сдвиге тестирования влево к финалу разработки в продукте почти не остается дефектов, поэтому продукт быстрее достигает рынка.
Командная работа на каждом этапе. Чем больше специалистов задействовано на каждом этапе, тем меньше проблем в проекте. Для примера представим аналитика, который формирует требования к продукту в одиночку. Без участия разработчика, дизайнера и тестировщика он может упустить технические особенности, трудоемкие решения, сложные фичи и другие подводные камни. Все это приведет к дорогим и долгим исправлениям на поздних этапах.
Будет эффективнее, если команда обсудит требования и учтет все детали заранее. В этом случае не придется переделывать продукт на поздних этапах — продукт быстрее выйдет на рынок.
Линтеры. В языке программирования Java есть null pointer exception — эта ошибка, которая останавливает программу, если какая-то функция обращается к объекту со значением null. Работать с подобными ошибками можно так — тестировщики ищут ошибку, находят ее, ставят задачу на исправление, а затем разработчики переписывают код.
Но есть и более эффективный путь — линтер. Это программа, которая автоматически обнаруживает ошибки и предупреждает разработчика о них. С помощью линтеров разработчик пишет код и сразу отлаживает его. Так часть ошибок устраняется на раннем этапе, что экономит время тестировщика.
Непрерывная интеграция и деплой. Есть еще один тип ошибок — ошибки конфигурации. Справиться с ними помогает Docker — инструмент непрерывной интеграции и деплоя. У него есть ядро своей операционной системы, поэтому приложение работает в одной конфигурации на разных операционных системах. Таким образом, Docker не только ускоряет тестирование, но и обеспечивает большую стабильность и качество приложения.
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты
Для полного доступа к курсу нужен базовый план
Базовый план откроет полный доступ ко всем курсам, упражнениям и урокам Хекслета, проектам и пожизненный доступ к теории пройденных уроков. Подписку можно отменить в любой момент.
