4 стратегических шага для структурированного процесса тестирования
Роль тестировщика неутомимо развивается вместе с изменениями технологий в разных отраслях и переходом к гибкой методологии. Это открывают массу возможностей для тестировщиков и не только, но очень часто из-за обилия информации мы не знаем на чем сосредоточить свое внимание. В этой статье мы рассмотрим структурированный подход к процессу тестирования в рамках методологических изменений.
Еще 10 лет назад виденье работы тестировщика существенно отличалось от нынешнего. Имел место быть следующий формат работы: каждое утро группе тестировщиков был предоставлен список заявок для тестирования и они расходились для поиска багов.
Обзоры производительности были просты: чем больше ошибок находили тестировщики, тем опытнее они считались. Не было ни стратегии, ни мотивации. Кофе-брейки чаще всего состояли из дискуссий о количестве ошибок, обнаруженных каждым членом команды, а вот о качестве найденных ошибок речи не шло.
Многих это стало заставлять задумываться, какую ценность продукту они могут дать, и могут ли дать её вообще? Или стоит и дальше просто продолжать проверять программное обеспечение на ошибки и не отклоняться от курса?
Вскоре стали появляться команды QA, которые в рамках тестирования функциональности также делали отладку, анализировали трассировку стека и обеспечивали объяснения основных причин проблем разработчикам. Здорово было видеть, что все сотрудничают как одна команда и объединены общей целью.
Со временем пришло понимание, что тестировщик это по сути не просто тот человек, который ищет баги, это также участник команды, который вносит существенный вклад в общее дело. По мере того, как тестировщики ставали неотъемлемой частью некоторых команд, внимание сосредоточилось на постоянном совершенствовании автоматизации и глубоком знании каждого компонента. Роль QA стала рассматриваться в совершенно новом свете.
Важным было осознание более структурированного подхода к обеспечению качества продукта. И ниже мы рассмотрим 4 стратегических шага для улучшения процесса QA.
1. Обзор проектной документации
Всегда полезно иметь как можно больше знаний о тестируемом продукте. Если доступны проектные и архитектурные документы, не ленитесь и прочтите их. Вы будете поражены тем, насколько больше и быстрее станете понимать архитектуру продукта, интегрированные компоненты и поток данных, чем если бы вы тестировали продукт без знаний. Делайте заметки и проводите параллели с тем, что вы тестируете и как взаимодействует система.
2. Исследование прошлых багов
Важно знать области риска и наиболее восприимчивую функциональность, которая может нарушить ваше приложение при каждом изменении. Такие данные могут быть в истории ошибок продукта.
Проведите некоторое исследование вашего исследуемого продукта и проанализируйте полученные ранее ошибки. Данные, полученные после этого анализа, помогут вам развить больше возможностей для автоматизации в этой области. Также этот приём поможет вам в дальнейшем в принятии решений о стратегии тестирования для различных выпусков продукта.
3. Устранение ошибок
QA обнаруживает проблему и сообщает о ней разработчику. Но что, если предположить, что ваша работа еще не закончена - вы можете идти дальше, задавая себе важные вопросы. Есть ли что-нибудь еще, что вы могли бы сделать? Знаете ли вы, почему возникла эта проблема и т.д.?
У вас есть доступ к журналу, коммитам и коду, поэтому вы можете приложить усилия, чтобы помочь решить возникшие ошибки. В зависимости от того, насколько являются глубокими ваши технические знания, вы можете исследовать ошибки далее. Уточните проблему и начните разговор с разработчиком. Они оценят подробную информацию.
4. Выйти за пределы отчетной проблемы
Иногда полезно не просто сосредотачиваться на тестировании функциональности. Подумайте о внутренних и внешних интерфейсах вашего приложения.
Например, приложение может работать как ожидалось, но с некоторыми ошибками, возникающими в конце. Является ли описание ошибок достаточно подробным? Есть ли исключения? Для взаимодействия с браузером откройте инструменты разработчика в своем браузере и выполните мониторинг сетевого компонента. Является ли ответ длительнее допустимого? Есть ли какой-то запрос, который не требуется при доступе к некоторым частям вашего приложения?
Все эти вопросы позволяют тестировщику заходить дальше того, что они «назначают» для тестирования. Также можно вести обсуждения с владельцем продукта и разработчиками, которые, возможно, не продумали некоторые сценарии.
Крайне важно иметь гибкий образ мышления при поиске недостатков продукта и путей для их решения.
Владение качеством продукции
Быть программным тестировщиком - это не просто искать ошибки и пытаться сломать приложение. Речь идет о постоянном улучшении, определении четкой стратегии тестирования и улучшения качества продукта. Следуя последовательному, структурированному подходу к QA, вы сможете получить больше знаний о тестируемом продукте, задавать правильные вопросы и иметь непосредственное влияние на качество тестируемого продукта.
18 октября / 2018
ул. Шота Руставели 40\10
info@start-it.ua
+380 63 742 50 52
© 2018 StartIT training center

Made on
Tilda