Матрица тестирования – это основа для совершенствования. Она может помочь спланировать тестирование еще до начала разработки. Во время разработки она может служить единым источником правды о том, что было сделано за день. Когда разработка и тестирование завершены, она может стать общей картиной нашего выбора и решений в области тестирования.
Приняли ли мы правильные решения? Иногда ответ на этот вопрос можно получить только в будущем. Но в будущем мы должны быть уверены, что сможем вспомнить наши решения в деталях, иначе уроки не будут усвоены. В ретроспективе может оказаться полезным, если общая картина нашей деятельности по тестированию может быть найдена с помощью одной матрицы.
Матрица
На вертикальной оси мы можем отобразить уровни, которые мы тестировали или планируем тестировать. Провели ли мы тестирование производительности на уровне отдельных модулей? А как насчет интеграционного тестирования и регрессионных тестов?
На горизонтальной оси мы можем использовать типы тестирования. Проводили ли мы тестирование производительности на уровне системы для функции A? Во время разработки мы решили, что в этом нет необходимости. Проводили ли мы регрессионное тестирование перед выпуском функции B? На каком уровне? Планируем ли мы какие-либо тесты безопасности? Что насчет функционального тестирования?
Уровень детализации матрицы
Я видел команды, использующие цветные галочки и крестики. Они решили, что им нужна в основном качественная информация. Количественная информация изображалась на основе размера галочки. Например, зеленая галочка в поле функционального модульного тестирования означала, что было выполнено достаточно функциональных модульных тестов. Серая галочка означала “несколько тестов”, а черная – “несколько тестов”. Крестик означает отсутствие тестов. Если интеграционное тестирование не проводилось вообще, то соответствующая строка удаляется. Если не проводилось тестирование безопасности, то соответствующий столбец удалялся.
Другие команды использовали эту матрицу для планирования тестирования. Перед началом разработки они разбивали свои задачи и указывали на матрице, кто и что будет тестировать. На ежедневной основе матрица помогала им выравнивать, какие тесты были выполнены, а какие остались. Матрица вызывала дискуссии, когда возникали проблемы или требовались уточнения.
Другая команда решила, что им нужна четкая картина того, что они тестировали. Они хотели видеть ее наглядно на доске к тому времени, когда новая функция будет готова к выпуску. Все, что им было нужно для каждого задания, – это две вещи: Доска Jira с их задачами и матрица тестирования. Эти две вещи в совокупности помогли добиться ясности и согласованности. Если они решали, что тестирование производительности пользовательского интерфейса не применимо, они удаляли соответствующее поле. Если оно было применимо, но по каким-то причинам было пропущено, то эта причина кратко описывалась в графе.
Тестирование всей командой
Одно из основных предположений в этой статье заключается в том, что тестирование проводят команды разработчиков. В команде могут быть тестировщики, разработчики программного обеспечения в тестировании или просто разработчики программного обеспечения. Независимо от того, какие роли в программной инженерии входят в команду, предполагается, что тестирование – это деятельность всей команды.
Разработчики и тестировщики обычно выполняют различные виды тестирования на разных уровнях. Матрица тестирования может помочь избежать недопонимания, обвинений и разочарований. Также может быть проведено парное тестирование между различными ролями. Функциональное тестирование на уровне системы может быть хорошим кандидатом для проведения парного тестирования, а также для устранения ошибок и исследовательского тестирования. Матрица тестирования может стать картой масштаба для такой деятельности.
Смешивайте и сочетайте по своему усмотрению
Типы и уровни, изображенные на матрице выше, являются ориентировочными. Они не высечены в камне. Не стесняйтесь смешивать и сопоставлять их по своему усмотрению. Возможно, вам нужны уровни модулей, API и пользовательского интерфейса или уровни модулей, интеграции и пользовательского интерфейса. Возможно, вам нужно позитивное и негативное тестирование на горизонтальной оси. Эта статья не о том, какие типы тестирования важны на том или ином уровне. Следовательно, этот выбор остается за читателем. Я лишь подробно рассказываю о том, как можно сочетать и подбирать матрицу тестирования в соответствии с вашими возможностями и потребностями.
Итоги обсуждений
Прежде всего, во время ретроспективы матрица тестирования может облегчить обсуждение, основанное на тестировании. В каком тестировании мы не уверены и на каком уровне? Есть ли результаты тестирования, которым мы не полностью доверяем? Есть ли результаты тестирования, которые не имеют смысла? Было ли такое тестирование, которое заняло гораздо больше времени, чем ожидалось? Можем ли мы понять, почему это произошло? Все ли наши решения о том, что мы тестировали, когда и как мы тестировали, ясны и законны? Подобные вопросы могут помочь команде сосредоточиться на тестировании и совершенствовании.
Но все это можно сделать с помощью других инструментов!
Может быть, и так, но матрица бесплатна. Вы можете просто нарисовать ее на листе бумаги и наклеить на свою доску. Вам не нужны ни лицензии, ни деньги, и вся эта информация у вас есть на одной матрице. Нет необходимости переходить от одного инструмента к другому.
Эволюция
По мере того, как мы развиваемся как группа или команда, будут развиваться и способы разработки и тестирования. Матрица тестирования также должна эволюционировать. Когда мы ее используем, как мы ее используем и на каком уровне детализации – все это, вероятно, изменится. Это хорошо при условии, что мы изменим нашу матрицу только для того, чтобы получить больше пользы.
Улучшения от матрицы
1. Осознанность и согласованность решений. Когда есть все варианты тестирования, команда может принимать обоснованные решения. Есть ли у них неделя на выпуск новой функции? За это время какие мероприятия по тестированию должны быть выполнены? Какие мероприятия по тестированию являются наиболее важными? Достаточно ли одной недели? Решения по таким вопросам могут быть доступны любому участнику матрицы.
2. Простой способ просмотра общей картины. Команде не нужно переключаться между просмотром коммитов кода или досок Jira каждый раз, когда они хотят увидеть принятые решения. Для этого они должны искать мелкозернистую информацию. Все основы стратегии тестирования и все детали высокого уровня могут быть отражены в матрице. Ищете более подробную информацию о деятельности по тестированию? Матрица может стать хорошей отправной точкой для перехода к нужным задачам или коммитам кода.
3. Обсуждения и улучшения. Основная ценность матрицы заключается в том, чтобы облегчить обсуждение тестирования. Подтверждение того, что мы тестируем, отличается от явного указания нашей деятельности по тестированию. Итак, как прошел наш последний этап? Какое тестирование мы можем улучшить? Какими новыми способами мы можем тестировать, чтобы получить больше пользы? Довольны ли наши клиенты? Сколько ошибок мы отловили и устранили, прежде чем передать продукт заказчику?
Подведение итогов
Матрица тестирования может быть полезна для организации и улучшения наших усилий по тестированию. Я видел, как стартапы, так и уже состоявшиеся компании извлекают из нее пользу. Если тестирование всей командой – это подход, которого придерживается ваша команда, то матрица тестирования, адаптированная к вашим потребностям, может оказаться полезной.
