Как выглядит качественное тестирование

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

От качества тестирования будет зависеть надежность, безопасность и производительность приложения. QA инженер из YuSMP Group рассказал о том, как выглядит не халявное тестирование. Сохраните материал, чтобы потом проверить своего подрядчика.

Кто и как занимается тестированием продукта

Тестированием занимается отдел QA — сокращенно от английского Quality Assurance или обеспечение качества. Но перед тем как тестировщики приступят к работе, каждый разработчик обязан проверить на работоспособность и пройти основные пользовательские кейсы самостоятельно. 

Смотрите также: тестирование программного обеспечения.

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

Этапы тестирования

Первый этап — это работа с требованиями. Тестировщик знакомится с требованиями от заказчика и формирует представление об итоговом продукте.

Участвует в обсуждениях, уточняет требования.

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

Третий этап идёт параллельно с непосредственной разработкой. 

Далее идёт создание тестовой документации. Это отчет по тестированию которую входит:

• чек-лист по фичам с проверками, которые необходимо выполнить;
• тестовые данные и их подготовка;
• настройка тестового комплекса при необходимости.

Когда фича уже разработана, QA подключаются и выполняют тестирование по чек-листам, которые они составили и заводят баги.

Следующим этапом идёт стабилизация фичи: происходит работа над устранением багов. Разработка чинит баги, а QA занимаются их верификацией и окончательной правкой документации по фиче.

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

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

Критерии качества ПО: 8 характеристик ISO/IEC 25010

Чтобы не спорить о тестировании на уровне ощущений, международный стандарт ISO/IEC 25010:2011 выделяет восемь характеристик, по которым можно объективно оценить качество программного продукта. QA-инженер проверяет каждую из них на своём этапе — от анализа требований до финального регресса.

Если подрядчик тестирует только «работает — не работает», он проверяет лишь первую характеристику из восьми. Остальные семь чаще всего всплывают уже после релиза — в виде жалоб пользователей.

Виды тестирования: как выбрать подход

Единого «правильного» вида тестирования не существует — QA-команда комбинирует несколько подходов в зависимости от задачи и этапа проекта.

• По степени автоматизации. Ручное тестирование — человек проходит сценарий и оценивает результат «глазами»; лучше подходит для новой функциональности и UX. Автоматизированное — скрипты прогоняют один и тот же набор проверок при каждой сборке; незаменимо для регресса.
• По знанию системы. Тестирование чёрного ящика — QA проверяет продукт как пользователь, не заглядывая в код. Тестирование белого ящика — специалист знает архитектуру и целенаправленно проверяет граничные случаи и внутреннюю логику.
• Функциональное и нефункциональное. Функциональное отвечает на вопрос «работает ли функция как задумано», нефункциональное — «выдержит ли она нагрузку, будет ли безопасной и удобной».
• Смоук-тестирование. Быстрая проверка после каждой сборки: не сломались ли ключевые сценарии — вход, оплата, главная страница.
• Регрессионное тестирование. Повторная проверка уже работавшей функциональности после изменений в коде — обязательный шаг перед каждым релизом.
• Приёмочное тестирование. Финальная проверка перед релизом с точки зрения заказчика: соответствует ли продукт исходному ТЗ.

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

Что помогает сделать тестирование лучше 

В своих рабочих буднях QA используют несколько подходов.

1) QA проверяют все задачи разработчиков на предмет соответствия результата изначальной постановке задачи. Сюда входит верификация багов и задач, SRS, дизайнов.

2) QA занимаются тест-дизайном. Подготавливается тестовая документация, включающая в себя чек-листы, баг-репорты и тест-кейсы.

3) Внедрение системы управления тестированием. Специалисты хранят и систематизируют документацию. Описывают процессы тестирования, процессы прохождения регрессионных периодов на проекте, процессы смоук-тестирования. Формируют отчеты о проведенном тестировании.

4) Распределение ролей в команде. Есть QA Lead и дежурный QA (передающаяся роль).

5) Регулярные митинги, где команда делится знаниями по проекту и новым фичам, а также лайфхаками и опытом в тестировании.

Чем больше на проекте будет автоматизировано рутинных процессов, тем быстрее будет расти команда QA.

Какими инструментами пользуются QA-инженеры

Набор инструментов зависит от масштаба проекта, но в большинстве команд встречаются одни и те же категории.

• Баг-трекинг и тест-менеджмент. Jira, YouTrack, TestRail — здесь хранят тест-кейсы, заводят баги и отслеживают их статус от находки до исправления.
• Автоматизация UI. Selenium, Playwright, Cypress — инструменты для автотестов, которые имитируют действия пользователя в браузере.
• Тестирование API. Postman, Insomnia — проверка запросов и ответов backend без участия интерфейса.
• Нагрузочное тестирование. JMeter, k6 — эмулируют одновременную работу тысяч пользователей, чтобы найти узкие места производительности заранее.
• Отчётность. Allure, ReportPortal — собирают результаты автотестов в наглядные отчёты для команды и заказчика.

Наличие инструментов само по себе не гарантирует качество: важно, чтобы ими действительно пользовались, а не заводили формально «для галочки» после каждого релиза.

Что важно запомнить

QA по-хорошему должны подключаться к проекту с самого начала: так они лучше понимают будущий продукт и не тратят время на лишние движения.

Тестирование состоит из нескольких этапов и сопровождает проект даже после релиза. Это сложный продолжительный процесс с большим объемом технической документации, поэтому для проекта лучше выбирать опытных QA.

Работа тестировщиков тесно связана с разработкой: поэтому важно, чтобы между отделом QA и программистами был налажен контакт. Намного лучше, если оба подразделения относятся к одной компании.

Частые вопросы про качественное тестирование

Как понять, что тестирование сайта или приложения проведено качественно?

Качественное тестирование покрывает все этапы — от анализа требований до регресса после релиза, опирается на задокументированные тест-кейсы и чек-листы, а не на выборочный «прогон руками», и проверяет продукт по восьми характеристикам ISO/IEC 25010. Если подрядчик может показать тест-план, баг-репорты и отчёт о регрессе — это признак зрелого процесса.

Сколько времени занимает тестирование перед релизом?

Точечное тестирование небольшого изменения занимает несколько часов, а полный цикл перед крупным релизом — от нескольких дней до пары недель. QA обычно работает параллельно с разработкой, поэтому финальное тестирование — это уже проверка стабилизированной версии, а не работа с нуля.

Чем ручное тестирование отличается от автоматизированного?

Ручное тестирование выполняет человек и лучше замечает визуальные и логические несостыковки, но не может быстро повторять одни и те же проверки. Автоматизированное — это скрипты, которые прогоняют один и тот же сценарий за секунды при каждой сборке. Эффективная связка: автотесты закрывают регресс, ручное тестирование — новую функциональность и юзабилити.

Можно ли обойтись без отдела QA на маленьком проекте?

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

Что такое регрессионное тестирование и когда оно нужно?

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

Как проверить, что подрядчик действительно тестирует продукт, а не имитирует процесс?

Попросите показать артефакты: тест-кейсы, чек-листы по фичам, баг-трекер с историей найденных и закрытых дефектов, отчёт о регрессионном тестировании перед релизом. Если в ответ есть только устное «мы всё проверили» без документов и без инструментов вроде Jira или TestRail — это повод насторожиться.