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