Портал №1 по управлению цифровыми
и информационными технологиями

Организация и совершенствование команд разработчиков: Матрица тестирования

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

Матрица
На вертикальной оси мы можем отобразить уровни, которые мы тестировали или планируем тестировать. Провели ли мы тестирование производительности на уровне отдельных модулей? А как насчет интеграционного тестирования и регрессионных тестов?

На горизонтальной оси мы можем использовать типы тестирования. Проводили ли мы тестирование производительности на уровне системы для функции A? Во время разработки мы решили, что в этом нет необходимости. Проводили ли мы регрессионное тестирование перед выпуском функции B? На каком уровне? Планируем ли мы какие-либо тесты безопасности? Что насчет функционального тестирования?

Уровень детализации матрицы

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

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

Другая команда решила, что им нужна четкая картина того, что они тестировали. Они хотели видеть ее наглядно на доске к тому времени, когда новая функция будет готова к выпуску. Все, что им было нужно для каждого задания, — это две вещи: Доска Jira с их задачами и матрица тестирования. Эти две вещи в совокупности помогли добиться ясности и согласованности. Если они решали, что тестирование производительности пользовательского интерфейса не применимо, они удаляли соответствующее поле. Если оно было применимо, но по каким-то причинам было пропущено, то эта причина кратко описывалась в графе.

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

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

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

Смешивайте и сочетайте по своему усмотрению

Типы и уровни, изображенные на матрице выше, являются ориентировочными. Они не высечены в камне. Не стесняйтесь смешивать и сопоставлять их по своему усмотрению. Возможно, вам нужны уровни модулей, API и пользовательского интерфейса или уровни модулей, интеграции и пользовательского интерфейса. Возможно, вам нужно позитивное и негативное тестирование на горизонтальной оси. Эта статья не о том, какие типы тестирования важны на том или ином уровне. Следовательно, этот выбор остается за читателем. Я лишь подробно рассказываю о том, как можно сочетать и подбирать матрицу тестирования в соответствии с вашими возможностями и потребностями.

Итоги обсуждений

Прежде всего, во время ретроспективы матрица тестирования может облегчить обсуждение, основанное на тестировании. В каком тестировании мы не уверены и на каком уровне? Есть ли результаты тестирования, которым мы не полностью доверяем? Есть ли результаты тестирования, которые не имеют смысла? Было ли такое тестирование, которое заняло гораздо больше времени, чем ожидалось? Можем ли мы понять, почему это произошло? Все ли наши решения о том, что мы тестировали, когда и как мы тестировали, ясны и законны? Подобные вопросы могут помочь команде сосредоточиться на тестировании и совершенствовании.

Но все это можно сделать с помощью других инструментов!

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

Эволюция

По мере того, как мы развиваемся как группа или команда, будут развиваться и способы разработки и тестирования. Матрица тестирования также должна эволюционировать. Когда мы ее используем, как мы ее используем и на каком уровне детализации — все это, вероятно, изменится. Это хорошо при условии, что мы изменим нашу матрицу только для того, чтобы получить больше пользы.

Улучшения от матрицы

1. Осознанность и согласованность решений. Когда есть все варианты тестирования, команда может принимать обоснованные решения. Есть ли у них неделя на выпуск новой функции? За это время какие мероприятия по тестированию должны быть выполнены? Какие мероприятия по тестированию являются наиболее важными? Достаточно ли одной недели? Решения по таким вопросам могут быть доступны любому участнику матрицы.

2. Простой способ просмотра общей картины. Команде не нужно переключаться между просмотром коммитов кода или досок Jira каждый раз, когда они хотят увидеть принятые решения. Для этого они должны искать мелкозернистую информацию. Все основы стратегии тестирования и все детали высокого уровня могут быть отражены в матрице. Ищете более подробную информацию о деятельности по тестированию? Матрица может стать хорошей отправной точкой для перехода к нужным задачам или коммитам кода.

3. Обсуждения и улучшения. Основная ценность матрицы заключается в том, чтобы облегчить обсуждение тестирования. Подтверждение того, что мы тестируем, отличается от явного указания нашей деятельности по тестированию. Итак, как прошел наш последний этап? Какое тестирование мы можем улучшить? Какими новыми способами мы можем тестировать, чтобы получить больше пользы? Довольны ли наши клиенты? Сколько ошибок мы отловили и устранили, прежде чем передать продукт заказчику?

Подведение итогов

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

Оригинал статьи

«Flow Metrics: управление потоковым производством на основе данных»
Учебный курс про метрики на реальных примерах

Добавить комментарий

Ваш адрес email не будет опубликован.

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Внедрение ИИ для вашей службы поддержкиВнедрение ИИ для вашей службы поддержки
      Но что на самом деле означает внедрение ИИ для возможностей ITSM вашей организации, особенно для службы технической поддержки?
    • Бесплатная конференция IT-Entrance для тех, кто хочет стать айтишниками
        28 мая в Минске пройдет бесплатная 11-я международная конференция IT-Entrance. Это мероприятие для тех, кто хочет попасть в IT, для начинающих IT-специалистов уровня junior с
    • ITIL 4 Specialist: High-velocity IT. Что внутри?
      В дополнение к уже опубликованным обзорам курсов по направлению Managing Professional (MP) сертификационной линейки ITIL4, сегодня мы рассмотрим еще один модуль – ITIL 4 Specialist: High-velocity IT (HVIT).
    • Весення уборка в бэклоге продукта: порядок за четыре шага!
      Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы. 
    • Warranty и Utility в ITIL4
      У услуг, которыми мы управляем в рамках Service есть две основные характеристики: гарантия — Warranty и Utility — полезность. Эти характеристики нужны нам, чтобы определить, будет ли услуга способствовать достижению результатов, которые нужны пользователю, а как следствие — создавать для них ценность.
    • Шесть практик для лучшего взаимодействия бизнеса и ИТ
      Хотели бы вы, чтобы руководители предприятий и ИТ могли лучше работать вместе, совместно работать над проектами и в полной мере обмениваться информацией? Если вы похожи на большинство ИТ-руководителей, ответ — да. Преимущества эффективного сотрудничества между бизнесом и ИТ включают в себя специальные проекты, которые лучше соответствуют бизнес-целям, улучшенное управление изменениями и более активное участие в новых инициативах.
    • Используйте технологии для повышения эффективности рабочего процесса вашей ИТ-команды
      Эффективное рабочее место создает, так сказать, хорошо смазанную машину, повышая итоговую прибыль и, как следствие, успех вашего бизнеса. Дополнительное время на работе не всегда означает большее достижение. Важно то, что вы делаете с тем временем, которое у вас есть, а это все об эффективности рабочего процесса.
    • Хранение данных и «внутренний хомяк»
      Хранение информации, которая больше не пригодится, сопряжено со огромным количеством рисков. Иллюстрация этому — череда сливов персональных данных пользователей крупных сервисов, которую мы могли наблюдать с января по март. Кажется, что предприятиям нужны правила, когда и как избавляться от данных.
    • Action BiasAction Bias — известная ловушка, в которую мы всё равно постоянно попадаем
      Action Bias: склонность к реагированию и действию, даже если это не приведёт к положительным результатам. «Делать хоть что-то» создаёт иллюзию загрузки ресурсов полезной работой.
    • бэклог27 антипаттернов бэклога продукта
      Эта статья показывает 27 распространённых антипаттернов продуктового бэклога, включая процесс уточнения бэклога продукта, ограничивающих успех вашей Скрам-команды.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT