Привет! Меня зовут Станислав Беленов, я работаю старшим специалистом по тестированию в AWG.
Бывали ли у вас такие ситуации, когда необходимо было определить готовность продукта и его соответствие требованиям? Каждый тестировщик сталкивается с таким вопросом при начале работы с новым продуктом. В нашей команде есть больший список критериев для определения качества разрабатываемого продукта. Сейчас попробую поделиться некоторыми основными тезисами или правилами.
Начать надо с понимания, что тестировщик необходим с начала разработки идей продукта. Его компетенция поможет определить узкие места разрабатываемого приложения, поможет определить необходимое распределение нагрузки на модули, а правильно составленный тест‑план на этапе разработки концепта поможет определить сроки для проведения качественного тестирования.
Тестировщик для нашей команды — это та невидимая нить, которая пронизывает и связывает все коммуникации внутри разрабатываемого продукта. Его компетенция и коммуникация позволяет смотреть по‑другому не только на подходы к определению и тестированию требований заказчика, но и влиять на процесс разработки, аналитики, да и на процесс установки требований заказчиком.
При работе в команде можно выделить несколько уровней тестирования:
Тестирование аналитики — совместная работа тестировщика и аналитика над функционалом продукта, разработка тестовых сценариев, формирование из них тестовых прогонов. Хорошей практикой может оказаться анализ аналитиком и разработчиком тестовых кейс��в, это поможет и тестировщику с корректировкой тестовых данных, и аналитику с правками в описаний работы приложения. Иногда тестирование аналитики помогает разработчикам в написании юниттестов, что помогает разработчикам на начальных этапах проверить разрабатываемое приложение.
Тестирование API. Такое тестирование позволяет быстро и эффективно проверить бизнес‑логику продукта еще до разработки интерфейса. Возможность автоматизации таких тестов позволяет практически в реальном времени следить за состоянием инфраструктуры продукта. Использование сторонних приложений, таких как Postman и аналогичных, позволяет создавать нагрузку на разные точки входа в приложение, как результат может получиться нахождение дефектов. На этом этапе разработки исправление таких багов обходится еще дешево.
Модульное тестирование. Тестирование отдельных компонентов продукта. Момент «тесной» коммуникации между тестировщиков и разработчиком. Этап, когда проще всего найти дефекты и дешевле всего их поправить. Написание тест‑кейсов, создание тестовых прогонов и вообще это время тестировщика проявлять свое мастерство и компетенцию. Здесь легко определить, были ли выполнены требования заказчика и выполняет ли продукт задачи, для которых он разрабатывался. Модульное тестирование побуждает разработчиков писать более изолированный и поддерживаемый код. Разбиение программного кода на модули и их независимая проверка помогает соблюдать принципы чистоты кода, упрощает его понимание и структурирование.
Интеграционное тестирование. Все тестировщики «собираются» вместе и тестируют, как компоненты, которые прошли модульное тестирование, взаимодействуют между собой. Иногда может провериться без лития UI элементов, что делает похожим на тестирование API.
Сравнение результатов тестирования и активное взаимодействие с заказчиком. После каждого тестирования необходимо составлять отчет о тестировании, в котором необходимо отражать актуальные результаты тестов. Основываясь на этих результатах, тестировщик, команда и заказчик может видеть в каких местах есть дефекты. Тесное взаимодействие тестировщика и заказчика позволяет оперативно решать возникающие конфликты и, возможно, корректировать требования. Важно помнить, что процесс проверки соответствия требований заказчика должен быть активным и важно вовлекать заказчика на всех этапах для обеспечения полной удовлетворенности его потребностей.
E2E (end‑to‑end) или приемочное тестирование. Момент истины. Предназначено для проверки функциональности системы в ее окружении, начиная от пользовательского интерфейса и взаимодействия с пользователем до взаимодействия с внешними системами и базами данных. E2E тесты помогают обеспечить высокое качество программного обеспечения, так как они проверяют систему в целом, а не только отдельные ее компоненты или модули.
Представленные пункты это только примерный скелет для отслеживания соблюдений требований заказчика. Для каждого нового проекта не могут быть ис��ользованы одинаковые методологии тестирования. Как минимум одна из качественных метрик работы тестировщика — это участие во всех звонках или коммуникациях внутри продукта: изменение требований, добавление новой аналитики, подключение к разработке нового сотрудника, замена коллег в команде заказчика — отслеживание всего этого помогает следить тестировщику за изменением требований и добавлением корректировок в свой тест‑план.
В разных проектах по‑разному, но классическим этапом тестирования продукта является закрытое (для смелых заказчиков даже открытое) тестирование продукта в бою, своего рода Бета‑тестирование. Даже после выпуска продукта на рынок, тестировщику есть необходимость следить за тем, как дальше работает его продукт. А возможность тестировщика следить за использованием продукта позволяет:
Получая обратную связь от реальных пользователей, инженер по качеству (то есть тестировщик) может корректировать тестовые сценарии, но что более важно, может подсказывать заказчику, какие сценарии популярны, а какой функционал может быть необходимо закрыть. Эту информацию можно использовать для дальнейшего усовершенствования продукта. Тестировщику необходимо обмениваться информацией и давать обратную связь команде разработки по результатам эксплуатации продукта. Это поможет всем участникам процесса разработки непрерывно улучшать свои навыки и процессы работы.
Следить за качеством и установленными требованиями. Одним из результатов ��ета тестирования является определение правильно ли были представлены требования к продукту. Во время использования продукта некоторые функциональности (а так бывало часто) оказываются не столь эффективными, как ожидал заказчик. Это ведет к пересмотру требований а соответственно для тестировщика это ведет к новым корректировкам в свой тест‑план.
Увеличить доверие к команде. Для заказчика служит отличным опытом взаимодействие с командой разработки и отдельно к тестировщику. Отсутствие дефектов в бою для заказчика — это прекрасная реклама для тестировщика. Увеличение доверия от заказчика тестировщику позволяет более быстро и благосклонно вносить и обсуждать новые идеи и корректировки для продукта.
Получить пользовательский опыт. Тестировщик в момент бета‑тестирования получает реальное представление о том как пользователи взаимодействуют с продуктом. Это помогает идентифицировать улучшения пользовательского интерфейса, улучшить удобство использования программного обеспечения и обеспечить пользователей положительным и гармоничным опытом.
Бета‑тестирование играет одну из ключевых ролей в определении реализованы ли требования заказчика в рамках реального опыта и реальных ожиданий от команды, заказчика, тестировщика и пользователей.
Без определения конкретного конечного результата тестирование можно проводить долго и возможно оно будет избыточным. Чтобы не потерять в качестве разрабатываемого продукта, можно совместно с заказчиком составить чек‑лист для определения параметров тестирования:
Четкие сроки для тестирования. Четкие сроки позволяют определить, сколько времени и какие ресурсы будут использованы для тестирования. Это помогает более эффективно распределить задачи и обеспечить достаточное количество времени для выполнения тестов. Определение сроков тестирования помогает управлять ожиданиями заинтересованных сторон, таких как заказчики или руководство проекта. Это дает возможность видеть конкретные даты и понимать, когда ожидать результаты.
Определить, на какую нагрузку рассчитан разрабатываемый продукт. Количество пользователей в момент времени, объем передаваемых данных и другие параметры позволяют тестировщику и заказчику представить, какой уровень производительности необходим для разрабатываемого продукта. Определение нагрузки помогает сформировать требования и ограничения, связанные с использованием продукта, и обеспечить его эффективную работу.
Формирование и согласование вместе с заказчиком четкого тест‑плана. Дает реальное понимание объема тестирования, в нем отражены функциональность и требования к продукту. Правильно составленный тест‑план может служить форматом коммуникации между тестировщиком и заказчиком, в котором будут отражено, какие тесты будут выполнятся, какие ресурсы будут использованы, какие ожидания возлагаются на тестировщика.
Самостоятельность инженера по тестированию помогает привносить новые идеи и способы тестирования для улучшения качества продукта и определения проблем продукта, которые могли быть пропущены на этапах формирования требований от заказчика. Взаимодействие со всеми членами команды дает возможность вносить свою экспертизу в процесс разработки и тестирования продукта.
Так как разработка продукта в основном носит итеративный характер (самые популярные методологии разработки agile, scrum и т. д. Ведут поэтапно разработку), требования от заказчика и аналитика могут меняться каждую итерацию — тестировщику важно успевать адаптироваться под изменения и уделять достаточное количество времени для изменения своих тестовых сценариев.
Вообще тестировщику необходимо быть гибким в процессе тестирования, так как цели заказчика могут меняться из‑за изменений бизнес‑стратегии или появления новых возможностей рынка. Нередки случаи, когда в процессе длительной разработки продукта приходилось обновлять стандарты безопасности или переходить на новые версии программного обеспечения, необходимого при разработке — тестировщику важно и необходимо следить за этими изменениями и вносить в тест‑план соответствующие корректировки для покрытия новых требований.
Продукт, который соответствует требованиям заказчика, имеет больше шансов быть купленным. Это может привести к увеличению продаж и прибыли для компании. Тестировщик должен иметь свою точную и объективную позицию в команде. Объективность и независимость инженера по качеству позволяет давать качественную оценку разрабатываемому продукту, не ощущая на себе давление заказчика или остальных членов команды. В конечном итоге свободный в своей компетенции тестировщик, имея опыт работы с разными продуктами, грамотно реализующий свою работу, следящий за состоянием тест‑планов, коммуницируя со всеми другими компетенциями на проекте, своим решением может ответить, соответствует ли продукт требованиям заказчика.
