Меня зовут Лена, я руководитель отдела тестирования Touch Instinct.
У нас в компании делаются очень разные приложения, поэтому и требования к качеству могут сильно отличаться от проекта к проекту. Так что набор тестовых активностей, необходимых для обеспечения требуемого уровня качества, может сильно меняться. Но невозможно эффективно протестировать приложение, не изучив его.
Расскажу, какие аналитические задачи встают перед тестированием в Touch Instinct и как мы их решаем.
Тестирование документации
Заказчик приходит к нам и рассказывает, какой продукт он хотел бы получить, какой функциональностью этот продукт должен обладать и какие бизнес-цели выполнять. Так мы получаем требования бизнеса и пользователя к нашему продукту. Чаще всего их не документируют и они имеют устную форму. На основе этих устных требований продумываем дизайн и архитектуру АПИ и мобильных платформ. После этого менеджер проекта составляет список задач в разработку, а аналитик в случае надобности документирует функциональные требования в форме, оптимальной для данного проекта.
На выходе имеем следующие артефакты:
- навсхема, карта экранов приложения,
- документация АПИ,
- список задач в багтреккере,
- описание требований.
Все это являет собой множество функциональных требований, опираясь на которые разработчик будет писать код, а тестировщик будет проверять продукт.
Очевидно, что есть риски — с момента озвучивания заказчиком своих требований к продукту до момента поступления их к разработчику очень много рук к этим требованиям прикоснулось. Чтобы не получилось письма Дяди Федора, их нужно протестировать.
Под тестированием требований понимается проверка на соответствие некоторым критериям качества. В данном определении неважно, задокументированы ли проверяемые требования и в каком виде. Однако процесс тестирования и критерии качества будут различны в зависимости от типа требований. Поэтому тестирование документации мы выделяем задачей для нашего отдела, а в тестировании устных требований участвует вся команда на протяжении всего проекта.
Устные требования могут и должны удовлетворять только двум критериям — непротиворечивость и выполнимость. А вот критериев качества документации куда больше. От некоторых критериев, перечисленных по ссылке выше, мы осознанно отказываемся в пользу экономии ресурсов. Так, навсхема и документация АПИ должны удовлетворять критерию полноты. Описание требований — необязательно, поскольку такой документ может оказаться избыточным при наличии остальной документации. В идеале вся документация должна быть однозначно интерпретируема. Но часто легче оставить список комментариев к требованию в форме вопрос-ответ, чем заставлять аналитика бесконечно переписывать документ, пока формулировки не станут идеальными.
Порой мы можем даже не ставить целью протестировать требования на соответствие каким-либо критериям. Не всегда процесс, построенный на проекте, подразумевает такую активность. Однако тестировщик в любом случае должен ознакомиться со всей документацией на проекте перед началом тестирования. В 90% случаев возникают неудобные вопросы и находятся неточности в требованиях. Хорошо, если это произойдет до начала разработки. Но чаще всего требования уходят в разработку, как только появляются. В тестирование — примерно тогда же, потому что выставленные заказчиком сроки не позволяют откладывать разработку до окончания тестирования документации.
Тестирование документации — это профилактика лишних затрат. Такая активность позволяет снизить риски при разработке.
Декомпозиция продукта
Ознакомившись с имеющейся документацией, мы начинаем проектировать тесты и изучать продукт более подробно. Прежде всего необходимо понять, из каких компонентов состоит продукт. По какому признаку будем проводить декомпозицию, зависит от целей, поставленных перед тестированием на проекте. Например, если приоритетом для заказчика является красота и удобство приложения и большой упор делается на UI, имеет смысл проводить декомпозицию по экранам приложения. Если заказчика интересует в большей степени отработка определенных сценариев, можно провести декомпозицию по use-кейсам. Если наша цель — провести полное регрессионное тестирование, мы можем разбить проект на модули для дальнейшего поиска связей и зависимостей между ними. Для изучения логики и эффективного функционального тестирования мы делаем разбиение по объектам (сущностям) и изучаем возможные над этими объектами действия.
Чаще всего, когда мы приступаем к работе над проектом, какой-то вид декомпозиции уже сделан. Например, навсхема, которую мы получаем от дизайнеров, или список фич от менеджера проекта являют собой примеры декомпозиций. Иногда есть возможность получить от аналитика какие-нибудь наглядные схемы, которые помогут нам разобраться в продукте. Однако чаще всего этого недостаточно для эффективной работы — как в случае необходимости тестовой документации на проекте, так и в случае отказа от нее.
Декомпозиция продукта — это первая стадия проектирования тестов, заключающаяся в изучении компонентов продукта и связей между ними. Такая активность позволяет подойти к тестированию системно.
Анализ регрессионных рисков
Это не стадия как таковая, это процесс, протяженный во времени всей работы над проектом. Если есть ресурсы — его можно задокументировать, чтобы быть уверенными на 100% в том, что нигде ничего не упущено. Суть в том, чтобы понимать, как правка в какой-то части функциональности может повлиять на другую функциональность, оценивать риски поломок и тестировать ту функциональность, где эти риски есть.
Тестируя черный ящик для оценки рисков мы можем опираться на пользовательскую логику продукта, личный опыт, интуицию и слова разработчика. Мы можем задокументировать известную информацию о связях между функциональными блоками, составить таблицу и отметить, какую функциональность нужно проверять, если была правка в той или иной фиче. Однако чаще всего оцениваем риски на лету и не документируем связи в угоду экономии времени.
Другое дело, когда заранее проводится углубленный анализ всех связей между модулями внутри продукта. Это уже не тестирование черного ящика. Такая активность требует как дополнительных временных затрат, так и высокой квалификации специалиста. Метод примерно такой же — составление таблицы с отметками связей между функциональными блоками, только основанием служит непосредственно анализ кода. На данный момент мы не сталкивались с потребностью проведения полного анализа рисков ни на одном проекте, пока что ограничиваемся методом черного ящика.
При проверке промежуточных сборок мы всегда обсуждаем с разработчиками, какие риски видят они, и беспрерывно держим в голове вопрос «что мог сломать этот фикс».
При финальном тестировании перед релизом мы стремимся прогнать все тесты, потому что так вернее. Однако времени никогда не бывает достаточно, и приходится расставлять приоритеты функциональным областям, которые мы хотим проверить. При этом опираемся не только на приоритеты бизнеса, но и на наше представление о регрессионных рисках.
Анализ рисков — это активность, позволяющая провести качественное регрессионное тестирование в условиях ограниченных временных ресурсов.
В данной статье рассматривается только небольшая часть процесса обеспечения качества в нашей компании. Об остальных этапах мы расскажем в следующих статьях.
Автор: Touch Instinct
