Тест-анализ в мобильной разработке



    Меня зовут Лена, я руководитель отдела тестирования Touch Instinct.

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

    Расскажу, какие аналитические задачи встают перед тестированием в Touch Instinct и как мы их решаем.

    Тестирование документации


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

    На выходе имеем следующие артефакты:

    • навсхема, карта экранов приложения,
    • документация АПИ,
    • список задач в багтреккере,
    • описание требований.

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

    Очевидно, что есть риски — с момента озвучивания заказчиком своих требований к продукту до момента поступления их к разработчику очень много рук к этим требованиям прикоснулось. Чтобы не получилось письма Дяди Федора, их нужно протестировать.

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

    Устные требования могут и должны удовлетворять только двум критериям — непротиворечивость и выполнимость. А вот критериев качества документации куда больше. От некоторых критериев, перечисленных по ссылке выше, мы осознанно отказываемся в пользу экономии ресурсов. Так, навсхема и документация АПИ должны удовлетворять критерию полноты. Описание требований — необязательно, поскольку такой документ может оказаться избыточным при наличии остальной документации. В идеале вся документация должна быть однозначно интерпретируема. Но часто легче оставить список комментариев к требованию в форме вопрос-ответ, чем заставлять аналитика бесконечно переписывать документ, пока формулировки не станут идеальными.

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

    Тестирование документации — это профилактика лишних затрат. Такая активность позволяет снизить риски при разработке.

    Декомпозиция продукта


    Ознакомившись с имеющейся документацией, мы начинаем проектировать тесты и изучать продукт более подробно. Прежде всего необходимо понять, из каких компонентов состоит продукт. По какому признаку будем проводить декомпозицию, зависит от целей, поставленных перед тестированием на проекте. Например, если приоритетом для заказчика является красота и удобство приложения и большой упор делается на UI, имеет смысл проводить декомпозицию по экранам приложения. Если заказчика интересует в большей степени отработка определенных сценариев, можно провести декомпозицию по use-кейсам. Если наша цель — провести полное регрессионное тестирование, мы можем разбить проект на модули для дальнейшего поиска связей и зависимостей между ними. Для изучения логики и эффективного функционального тестирования мы делаем разбиение по объектам (сущностям) и изучаем возможные над этими объектами действия.

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

    Декомпозиция продукта — это первая стадия проектирования тестов, заключающаяся в изучении компонентов продукта и связей между ними. Такая активность позволяет подойти к тестированию системно.

    Анализ регрессионных рисков


    Это не стадия как таковая, это процесс, протяженный во времени всей работы над проектом. Если есть ресурсы — его можно задокументировать, чтобы быть уверенными на 100% в том, что нигде ничего не упущено. Суть в том, чтобы понимать, как правка в какой-то части функциональности может повлиять на другую функциональность, оценивать риски поломок и тестировать ту функциональность, где эти риски есть.

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

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

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

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

    Анализ рисков — это активность, позволяющая провести качественное регрессионное тестирование в условиях ограниченных временных ресурсов.

    В данной статье рассматривается только небольшая часть процесса обеспечения качества в нашей компании. Об остальных этапах мы расскажем в следующих статьях.
    • +11
    • 3,7k
    • 4
    Touch Instinct 82,38
    Разрабатываем мобильные приложения
    Поделиться публикацией
    Комментарии 4
    • 0
      Почитаешь такое, потом подумаешь о своем проекте и хочется закрыть лицо рукой. Как-то не верю я, что где-то все идеально и гладко а у тебя все страшно и гадко. Проблемы в ай-ти проектах в общих чертах везде одинаковые. Вот начальник отдела аквиза нам такие удивительные вещи про нас расказывает, по его словам мы просто чудесны свежи и прелестны. А процессы у заказчика лучше не становятся. Заказчик доволен нашей работой, но это по сравнению с другими подрядчиками, мы действительно косячим меньше. Но мы так далеки от эталонных процессов в разработке как это только можно себе представить. Процессы есть, они соблюдаются, но большую часть времени ты или ждешь когда другие сделают свою работу, например напишут требования, или что-то сломано по чужой вине и проверка твоего функционала невозможна (у нас над системой работает более дюжины разных подрядчиков) или в тулчейне проблемы и т.п. Как я люблю в шутку говорить «мы не пишем ПО, мы решаем проблемы».

      С нетерпением жду продолжения сказки про сказку :)
      • 0
        лично мне очень импонирует Ваш подход :) Однако охота подискутировать, так рождается истина

        У меня не получилось рассмотреть за текстом процессов — не ясны контрольные точки и коммуникации на каждом этапе. А это значит, непонятно
        — какие условия нужно было выстроить, чтобы все перечисленное работало, как положено. К примеру, не при всяких условиях можно узнать, что хочет заказчик и не в любой момент выяснить из каких компонентов состоит продукт.
        — как именно вы понимаете, сделаны ли эти работы хорошо. Как сами тестировщики это понимают?

        Или перечисленное скорее best practices отдела?

        В деталях:
        Про требования. Мне кажется тут не хватает проверки на согласованность требований… с целями заказчика. Если проект живет дольше одного релиза, с архитектурой проекта, уже существующими в нем другими функциональностями, данными.
        Про риски. Есть такое убеждение, что риски могут быть не только регрессионными.
        Для примера, вы разрабатываете новую функциональность, ммм… статус-кнопку, которая горит красным на ответ false от внешнего сервера и зеленым в случае true. Кнопка должна работать в режиме реального времени. Какие риски? Приложение может заспамить, а в худшем случае положить внешний сервер. Надо анализировать. Допустим риск оправдан. Очевидное решение — нужно кэшировать показатель кнопки, или реализовать очереди. Но тогда кнопка перестает работать в режиме реального времени — тоже риск, да такой, что надо обсуждать с заказчиком.
        Другой пример, вы разрабатываете какую-то внутреннюю механику, положим выгрузчик. На каждом этапе, он может не обработать данные, не выгрузить их, не суметь сохранить в БД. В чем риск? Все это нельзя будет достоверно проверить, если не будет соответствующих ручек и логов. Это уже дополнительная активность, чтобы в тестирование передали тестопригодный продукт. Ничто из перечисленного не является регрессией, но вроде является работой с рисками.
        • +1
          ekiyasheva и снова спасибо за ваш комментарий! =)
          Постараюсь прояснить некоторые моменты процессов.

          Мы аутсорс, и клиентоориентированность — основной аспект в нашей идеологии. Мы стараемся делать то, что нас просят, а не то, чего бы нам самим хотелось в связи со своими личными представлениями о прекрасном. Поэтому прежде, чем приступить к работе над новым скоупом работ на проекте — вне зависимости от того, первый это релиз или нет — тестировщик заполняет «опросник». В этом документе содержится информация о том, кто наш заказчик, какие у него бизнес-цели и бизнес-требования, какие приоритеты, кто наши пользователи и почему по мнению заказчика пользователь выберет именно этот продукт, а не аналоги на рынке. Так же в этом документе тестировщик кратко фиксирует информацию о сроках, планах, целях и роли тестирования на данном проекте, ссылки на перечисленные в начале статьи документы и прочие входные данные, необходимые для начала работ. Чаще всего тестировщик не общается с заказчиком напрямую, поэтому получить ответы на все перечисленные в опроснике вопросы — это целый квест. Тестировщик общается с аналитиком, менеджером проекта, продажником — со всеми, у кого есть доступ непосредственно к заказчику и понимание, что мы вообще должны в итоге получить. Иногда выявлением целей и сбором всей стартовой информации занимаюсь я как руководитель.
          Этот документ выкладывается в общий доступ для всей команды разработки, чтобы у всех была единая картина. Без ответов на все эти вопросы мы, конечно, можем как-то работать, но риск сделать не то, чего от нас хотят, повышается. Поэтому если нам не хватает информации, мы задаем вопросы до тех пор, пока не получим удовлетворительный ответ.

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

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

          Что же касается рисков — согласна, вы правы, риски бывают не только регрессионные, и они так же нуждаются в анализе. В статье я не стала акцентировать на этом внимание, поскольку этот анализ не лежит целиком и полностью на плечах тестирования. Все перечисленные вами примеры — это риски, которые чаще всего обнаруживаются либо еще до написания какой-либо проектной документации аналитиком и архитектором, либо на этапе тестирования требований. Если нет, то здесь вступают упомянутые выше митинги — как вы и сказали, истина рождается в споре (диалоге).
          В целом конечно, оценить, как именно нужно тестировать фичу, узкие места и рискованные области в новой функциональности, безусловно, необходимо — это является основной задачей любого тестировщика.
          • 0
            Есть над чем поразмыслить. Спасибо :)

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое