«Календарь тестировщика» за июль. Тестирование аналитики

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





    Модели рабочего процесса по тестированию аналитики


    Модель 1


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


    Минусы:


    • дефекты в аналитике не будут выявлены раньше стадии тестирования,
    • есть риск того, что задача из тестирования отправится снова в аналитику на доработку. Как следствие TimeToMarket задачи существенно увеличивается.

    Ошибки аналитики, выявленные при тестировании, стоят дорого или очень дорого.

    Плюсы:


    • сокращается время тестировщика для задач, где не требуется аналитик (инфраструктурные, рефакторинг).

    Модель 2


    Тестировщик подключается к задаче еще до того, как ее передали в разработку. Он смотрит прототипы по задаче или просто читает документацию. Все вопросы по задаче тестировщик задает аналитику. Аналитик оперативно исправляет замечания. Тестировщик составляет приемочные тесты.


    Минусы:


    • тестировщику придется учиться смежной области (оформлению аналитики и ТЗ),
    • перейдя на эту модель, тестировщику придется сначала потратить больше времени на тестирование, ведь процесс «пришла готовая задача — читаю аналитику — тестирую» растягивается до «пришло описание будущей задачи — читаю аналитику — тестирую аналитику — пришла готовая задача — тестирую».

    Плюсы:


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

    Если в команде разработки нет ревью работы аналитиков, тестирование аналитики улучшает качество продукта и уменьшает риск передачи задачи в разработку с ошибками в ТЗ.


    Когда мы рекомендовали вторую модель тестировщикам, работающим по первой модели, мы часто слышали:


    • «У нас в очереди и так хватает текущих задач, чтобы брать еще».
    • «А поговорите с менеджером».

    Перестройка процесса разработки — серьезная менеджерская задача.

    Внедрение тестирования аналитики до стадии разработки


    Почти год, как в проекте Контур.Норматив в процесс разработки встроен обязательный этап «тестирование аналитики». К этому команда пришла не сразу. Толчком стал рост количества возвратов задачи с тестирования на этап аналитики и дальнейшей доработки.


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


    Процесс тестирования аналитики не появляется по щелчку пальцев или какой-либо магии. Это кропотливая работа, но ее можно разбить на этапы.


    Этап 0. Продать команде идею тестирования аналитики


    Можно легко представить ситуацию, когда по своей работе внезапно получаешь обратную связь с замечаниями, предложениями и исправлениями. Первая мысль у любого нормального человека будет: «А почему решили меня проверить? Мне не доверяют? Следят за качеством моей работы?». На данном этапе очень важно, чтобы у аналитика не появилось ощущения, что его проверяют на качество, и, в случае неудачной проверки, уволят.


    Ряд вопросов можно снять, если преподнести информацию в ключе: «это даст нам возможность раньше узнавать о новой функциональности, ускорит этап тестирования, предотвратит внесение даже небольших дефектов в код».


    Когда этап 0 пройден, можно продвигаться дальше.


    Этап 1. Внедрение тестирования аналитики в процесс разработки


    Убедив команду, приступаем к внедрению тестирования аналитики в ежедневный рабочий процесс. Если изначально рабочий процесс выглядел так:



    То после внедрения:



    Если в вашей команде несколько аналитиков, которые проводят ревью друг друга перед тем, как отдать задачу в разработку, то приступаем к тестированию более качественного текста. Мы подразумеваем, что ревью аналитики не является ее тестированием, а лишь некоторой его частью.


    Этап 2. Тестирование аналитики


    Бывают задачи, когда прототипы заменяют текстовый вариант аналитики.


    В таком случае прототип проверяем также как текст. Если прототипы дополняют аналитику, то полезно перед чтением документации посмотреть на дизайн-макеты будущей функциональности. Это ваш единственный шанс взглянуть на задачу как пользователь, который не читал ТЗ и не знает, как всё устроено и должно работать.


    Что можно проверять в аналитике:


    1.Предложенное решение удовлетворяет цели задачи.


    Например, если цель задачи — собрать обратную связь с пользователей, то решение должно предполагать запись и хранение ответов пользователей.


    2.Однозначность интерпретации.


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


    3.Осуществимость решения.


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


    4.Тестируемость.


    Как проверить, что соблюдено условие «улучшить поисковую выдачу» — непонятно. Но если переписать условие на «поисковая выдача должна быть показана пользователю в течение 1 секунды после нажатия контрола «Поиск» — понятно.


    5.Наличие альтернативных сценариев.


    В формулировке «Если указаны номер и дата, то печатаем номер и дату. Если дата не указана, печатаем только номер» не хватает сценариев:


    • нет номера, а есть дата,
    • данных нет.

    6.Обработка исключений.


    В формулировке «Можно загрузить документ только в формате Excel» непонятно, что должно происходить, если мы загрузим файлы других форматов, и какую ошибку при их загрузке мы увидим.


    Артефакты при тестировании аналитики


    Какие артефакты могут остаться после тестирования аналитики:


    • составленные тест-кейсы,
    • чек-листы для разработчиков.

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


    Разработчика надо убедить проходить чек-лист тестировщика, снимая внутренние волнения разработчика «меня проверяют», делая акцент на «ускорение процесса, ускорение тестирования, повышение качества». В итоге у нас разработчик проходит данные чек-листы и радуется, что ошибки нашел не тестировщик, а он сам («никто не узнает, что я накосячил в таком ерундовом сценарии»).


    Что в итоге


    С первого взгляда кажется, что внедрение нового этапа в процесс разработки лишь увеличит TimeToMarket, но это иллюзия. Сначала, конечно, процесс тестирования аналитики будет новым и неопробованным, и тестировщик на него будет тратить больше времени. В дальнейшем, набираясь опыта, он сможет быстрее проводить его. А результаты, полученные на этапе тестирования аналитики, сократят время на этапе непосредственного тестирования и сведут количество возвратов к минимуму.


    Такой процесс проведения тестирования аналитики внедрен в нескольких командах Контура. Команды разработки получили ряд неоспоримых преимуществ:


    • экономия времени на этапе тестирования: нет затрат на тест-дизайн и тест-аналитику, так как всё уже заранее сделано,
    • ускорение обратной связи разработчику через чек-лист, раньше находим критичные баги,
    • все заинтересованные лица могут заранее провести ревью чек-листов и добавить некоторые проверки (на этапе тестирования данное действие обходится «дороже»).

    Мы верим, что и вы сможете получить эти преимущества, внедрив в своем проекте этап тестирования аналитики.

    • +12
    • 3,3k
    • 5

    Контур

    102,22

    Делаем веб-сервисы для бизнеса

    Поделиться публикацией
    Комментарии 5
      +1

      Всем привет)


      1. Когда мы общались с тестировщиками, работающими по первой модели, мы часто слышали:
        «У нас в очереди и так хватает текущих задач, чтобы брать еще».

        Не раскрыли за счет чего это произошло ?! Задач столько же. Растянули немного по времени. Задачи стали качественнее. Но их осталось столько же на входе.


      2. Хочется уточнить. При приемке аналитики в виде прототипов присутствуют только тестеры? Если на той же встрече есть ещё 1-2 разработчика (желательно те, кто будут принимать задачу в разработку), то и приемочных тестов не будет? Они здесь же слушают возможные сценарии от всех, включая тестировщиков, запоминают их и при разработке учитывают.
        Хочется узнать был ли опыт, когда существует процесс тестирования аналитики, но не писали приемочные тесты и видимо они же в виде чек-листа?! Что из этого получалось?


        0
        Привет!

        По первому вопросу мы немного исправили формулировку в статье. Был баг.

        Постараюсь ответить на твой второй вопрос.

        В идеале, при презентации аналитики в виде прототипов должен присутствовать заказчик (менеджер), разработчик и тестировщик. Каждый из них рассматривает прототипы со своей точки зрения. Не всегда получается так, что на встречу придут все те, кто точно будет заниматься данной задачей. А еще очень часто завершенная в аналитике задача просто попадает в очередь разработки, до которой разработчик доходит через n времени. Контекст по задаче теряется :(

        Приемочные тесты помогают сохранить контекст задачи. Служат точным описанием того, как в итоге это все должно работать.
        0
        ИМХО, необходимость тестирование аналитики прямо зависит от качеств аналитика.
        Если аналитик адекватный человек — он и так опишет задачу непротиворечиво и логично. А вот если нет — то получается, что тестировщик делает и свою работу, и доделывает за аналитиком.
          +1
          Исходя из вашей логики, если разработчик адекватный человек — он и так напишет код без багов с первого раза. Так зачем нам вообще тестирование в этом случае?
            +1
            Да, как-то не очень получилось :))
            Ну всё-таки пока тестировщиков не просят за разработчиками код переписывать. А вот доделать работу аналитика, собрать митинг чтобы обсудить требования, добиться, чтобы эти требования были непротиворечивыми и полными… таких задач у нас навалом.

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

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