Вступление
Всё начиналось с простой мысли: «Пора тестировать». У проекта появились пользователи, баги вылезают, как всегда, в самый неподходящий момент… При этом аналитика показывает странные метрики и всё чаще возникает ощущение, что продукт как будто живёт своей отдельной жизнью. Казалось бы — найми тестировщика или аутсорс, и готово. Но на деле выясняется: сначала нужно понять, что именно нужно тестировать. А хочется по-современному и быстро. И вот к вам приходят с прайсом на автоматизацию, а вы не уверены, что это вообще нужно. Или кто-то советует нагрузочное, а насколько оно необходимо в вашем проекте? Все вокруг что-то тестируют, а вы гадаете, за что браться — функциональность, UX, безопасность или ещё что-то?
Эта статья — не энциклопедия и не реклама. Это попытка на пальцах объяснить: как не превратить тестирование в ритуал ради галочки и не потратить бюджет на ненужное. Вы — техлид, продакт, СТО, руководитель — и хотите, чтобы всё работало, а пользователи не страдали. Погнали.
Почему «давайте протестим всё» — плохая идея
Ну вообще-то, когда заказчик говорит «проведите тестирование», он может иметь в виду всё что угодно {на уровне своих знаний}: от одного баг-репорта до автоматизации в три фреймворка и сотни тест-кейсов. Но тестирование — это никогда не «всё подряд«, а конкретный набор задач. Ошибка начинается, когда вместо того, чтобы разобраться в проблеме, хватаются сразу за инструмент.
Типичная ситуация: приходят за автоматизацией, потому что «так делают все». По факту проект на стадии MVP, фичи меняются каждую неделю, нет стабильной версии, всё собирается вручную. Автотесты там живут два спринта максимум, а потом их никто не поддерживает. Ну и для чего там тратить деньги и время на автоматизацию? Лучшим решением будет грамотное ручное тестирование по приоритетам и чек-листы с фокусом на критичное. Тогда и результат всех устроит. Получите стабильность, понимание покрытия и экономию бюджета.
Или другой вариант. Все всё отработали, проект сдали, но заказчик жалуется, что «да, всё работает, но никто не покупает». По собранным данным, 70% пользователей уходят с сайта после добавления товара в корзину, но без покупки. Скорее всего, если проверить UX в первую очередь, то причина оттока пользователей найдется в блоке с оформлением заказа.
Поэтому не тестируйте ради тестирования. А осознанно выбирайте то, что действительно влияет на продукт. И чтобы это сделать, нужно понимать, какие виды тестирования вообще бывают — и что каждый из них делает.
Краткий ликбез. Какие виды тестирования бывают
Не вдаваясь в занудство и ISTQB-шные формулировки, пройдемся по сути.
- Функциональное тестирование проверяет, работает ли продукт по бизнес-логике. Кнопка «оформить заказ» оформляет заказ? Письмо приходит? Деньги списываются? Всё. Подходит для любых проектов, на любом этапе. Сработать может и джун, если есть чёткие чек-листы. При нестандартной логике — лучше нанять специалиста с опытом.
- UX/юзабилити тестирование — тестируем не «работает ли», а «понятно ли пользователю«. Можно делать на ранних прототипах или в живом продукте. Часто выполняется вручную. Здесь нужен специалист с насмотренностью и пониманием поведенческих паттернов — уверенный мидл, иногда лучше с дизайнерским бэкграундом. Джун без сопровождения может не заметить ключевые проблемы. {хорошо, что наши джуны всегда работают с сопровождением}
- Безопасность (SAST, DAST, ручное) проверяют для анализа уязвимостей. SAST требует доступа к коду и понимания архитектуры. Тут нужен опытный qa-инженер или специализированный специалист. DAST можно автоматизировать частично, но ручное тестирование проводится сеньором или безопасником, иначе есть риск пропустить критичную дыру.
- Нагрузочное тестирование представляет собой симуляцию потока пользователей и сценариев. Настройка требует технической экспертизы, особенно при нестандартных архитектурах. Джун сможет запустить готовый сценарий, но проектировать сценарии, анализировать результаты — задача для мидла или тимлида по нагрузке.
- Регрессионное тестирование, как понятно по названию, повторно проверяет старый функционал после изменений. Фактически может быть ручным или автоматизированным. Любой специалист справится при наличии регламентов. Они не всегда есть, но с ними гораздо удобнее. Автоматизацию стоит докинуть при частых релизах и стабильных сценариях. Может работать джун по автоматизации, но поддержка все равно задача QA уровня мидл+.
- Тестирование совместимости нужно для приложений, которые запускаются в разных средах. Очень часто такие проверки поручают джунам после того, как более опытный специалист составил стратегию тестов и выбор девайсов. Хотя толковый начинающий специалист по тестированию с этим и сам сможет разобраться, просто понадобится чуть больше времени.
- Ручное vs автоматизация. А вот тут часто почему-то «или-или» допускают. Но ведь автоматизация — это не замена, а усиление. Автотесты эффективны там, где стабильный функционал и частые релизы. Но они не заменят ручного анализа, UX, багов «по ощущениям» и проблем с интеграцией. На старте начинающий может писать простые автотесты, но для сложных сценариев и CI-интеграции определенно нужен мидл или выше.
Кейсы из практики
«Нам нужна автоматизация» — а нужно было ручное
Клиент пришёл с запросом: «Хотим автотесты, всё автоматизировать, чтобы было быстро, красиво и современно». Международный маркет-плейс с завязкой на сотни точек геолокации, десятки форм, тысячи товаров… И при этом нестабильный бэк и меняющийся фронт. Автоматизация здесь не просто на грабли бы наступила, прыгала бы по ним, как на батуте, без шансов на стабильность.
Что сделали специалисты ЛК? Провели аудит, предложили грамотное ручное тестирование с фокусом на критические пути пользователя. Включили приоритеты, добавили чек-листы, подсветили проблемы, которые автотест бы не поймал. Благодаря профессионализму и опыту нашего Senior’а по ручному тестированию были изменены процессы и подход к тестированию, заказчик увидел, что ему нужна не автоматизация, а грамотно построенные процессы. Все изменения в системе обязательно проходили этап тестирования и в прод попадали самые стабильные версии. Результат — стабильность, понимание покрытия и в три раза меньше багов на проде. Без роботов.
«У нас никто не покупает». Ну так ваша корзина — квест
Кейс e-commerce проекта. У клиента было всё: реклама, трафик, продукт. Но процент заказов — обнять и плакать, бизнес в минусе. Эксперты провели UX-тестирование. Оказалось, пользователи не доходили до оформления, потому что {Упс!} корзина в мобильной версии закрывала самые важные кнопки, не работала свайп-навигация, а подтверждение заказа пряталось за экран. А ведь с мобильных люди покупают уже давно и чаще, чем с ПК! Починили блок, упростили навигацию, протестировали снова — и вот уже заказы пошли. Не потому что баг был, а потому что UX был антипользовательский. Такое тестированием не найдёшь, если просто «всё работает».
FAQ
Для тех, кто не уверен, ниже вопросы, которые стоит себе задать:
- Что для нас критично: безопасность, скорость работы, удобство, бизнес-функциональность?
- Что уже тестировалось — и кем?
- Где были основные проблемы: на проде? при релизах? в саппорте?
- Кто наша аудитория? И какие у неё устройства, привычки, страхи?
- Насколько часто мы обновляем продукт?
- Какие штрафы/риски мы не можем себе позволить?
Если хотя бы на часть этих вопросов у вас нет ответа — начните с аудита. Или спросите подрядчика не «что вы можете?», а «что вы мне порекомендуете и почему именно это?»
Подберите вид тестирования для себя
1. Вы запускаете MVP — вам нужно функциональное тестирование + ручной smoke-тест, иногда — базовое UX (дойдут ли люди до регистрации?). Без автоматизации. Быстро, просто, по чек-листу.
2. У вас e-commerce / маркетплейс — функционал, UX, совместимость, иногда безопасность (если платежи). Нагрузочное — если планируются акции и высокая посещаемость.
3. Вы финтех / храните данные / у вас SaaS — привет, безопасность. И да, автоматизация может пригодиться, но не в ущерб регрессу и UX.
4. У вас всё работает, но падает конверсия — точно в UX. Может, человек просто не находит кнопку купить.
5. Вы часто релизитесь — автоматизация регрессов, smoke-тесты, регрессионное тестирование руками. Без этого будете фиксить прод по ночам.
6. Вы делаете продукт под госкомпанию / сертификацию — готовьтесь к требованиям: безопасность, совместимость, тестовая документация. Без лишнего пафоса, но строго по ГОСТу.
7. Разработчики тестируют сами — возможно, они молодцы. Но скорее всего, смотрят под одним углом. Вам нужен QA хотя бы на приёмку и критические сценарии.
И табличный вариант для визуалов:
Подводим итог
Тестировать не значит «чекнуть всё, чтобы было». Надо, чтобы продукт работал, пользователи приходили снова и снова, а вы не бегали по ночам с багфиксами. Правильно выбранный вид тестирования экономит деньги, нервы и командные ресурсы. Неправильный — тратит их без пользы.
Если вы не уверены, с чего начать — начните не с автотестов и не с покупки нагрузки. А с вопросов к себе и аудитом текущей ситуации. Что уже проверяли, что ломалось, где теряете пользователей и деньги. В идеале — найдите тех, кто не будет продавать вам автоматизацию «потому что модно», а честно скажет: «вам хватит ручного тут и тут». Или наоборот: «нужен регресс на автомате, иначе прод снова рухнет». Главное — не тестируйте ради галочки. Тестируйте ради результата.
Хотите такой разговор — приходите. Мы не будем уговаривать. Мы просто поможем понять, где у вас болит и чем лечить. Даже если лечить там нечего, а нужно просто чутка поднажать на UX и не трогать остальное.
