Эта статья — вводная к матрице тестов, которой я на самом деле хочу поделиться и поделюсь во второй части.

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

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

Лирическое отступление

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

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

Поэтому я призываю думать о Цели и руководителей, и исполнителей.

Просто подстрахуйте друг друга от ошибок, вы же команда!



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

К чему я об этом? К тому, что часто так бывает, что выполнение задачи «проведите полное ручное функциональное тестирование» не приводит к повышению эффективности команды разработки. Уходит много ресурсов, а результат низкий, да и задача почти некогда до конца не выполняется. Как часто вы задумываетесь, что на самом деле вам нужно что-то другое? Дайте угадаю, чем это заканчивалось! Нанять больше monkey-clickers или автоматизировать регресс. На этом ваши размышления, наверняка, часто и останавливались.

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

Условная терминология.

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

Представим дерево задач. Наверху Цель. Далее идут задачи, которые я называю «верхнеуровневые». Именно эти задачи «поступают сверху», идут от руководителя. Каждая верхнеуровневая задача декомпозируется до произвольной глубины. В этом процессе могут быть задействованы как исполнители, так и руководители, в зависимости от самостоятельности подчиненных и иерархии команды.

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

Множество целей и задач

Определение цели — сложный процесс. Есть много методов и техник, которым должны обучаться руководители проектов. Здесь я только вскользь упомяну о том разнообразии целей, которые могут получиться на выходе из грамотного процесса определения цели. Это нужно для того, чтобы вы поняли, что у каждой проектной команды цель отличается от цели другой команды, и ставить задачи для достижения цели наверняка нужно разные.

Цель проектной команды зависит от нескольких факторов одновременно. Предположим, от следующих:

• Давно ли существует проект?
• Частота поставок релизов в прод.
• Ущерб от нестабильности системы.
• Количество и критичность известных незакрытых дефектов.
• Взаимоотношения с заказчиком.

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

Пример 1. Стартап.

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

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

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

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

Не надо ставить рамки, говоря «как сделать». Говорите «чего нужно добиться».

Пример 2. Поддержка СЭД, интегрированной в инфраструктуру нескольких предприятий.

Проекту несколько лет. Команда, которая занималась кастомизацией и внедрением, передала код на поддержку другой команде. Есть график обновлений ядра, поставляемый всем клиентам и получаемый от вендора. Хотфиксы должны заливаться в течении 2 суток. Есть штрафы за нарушение сроков. Есть открытые дефекты, не обнаруженные еще заказчиком, а заведенные внутри команды. Часть дефектов уже есть в проде, часть — появились после получения новой поставки от вендора. Если заказчик будет не доволен, он не продлит лицензию на будущий год, а уйдет к конкурентам.
Возьмём ту же цель: «повысить качество софта». Стратегические задачи:

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

Вы видите в этом списке фразу «займитесь регрессом», или «сделайте 100% покрытие» или «автоматизируйте смоук»? Нет. И не надо. Такие задачи должны ставятся при декомпозиции задач и не упуская из внимания Цель. Если вы опустите стратегические задачи, которые вам покажутся «очевидными» и «само собой разумеющимися», а оставите только голую Цель «повысить качество» — и ряд требований о том, какими именно инструментами это сделать — вы упустите возможности добиться цели эффективно, либо не добьетесь еще вообще никогда, и заказчик уйдёт к конкуренту, или стартап прикроют из-за отсутствия финансирования. Есть еще серединка — остаться в текущем положении, периодически огребая от вышестоящего руководства и постоянно испытывая коллективное чувство вины и собственной некомпетентности.

Стратегические задачи конкретизируют цель, делая ее по-настоящему очевидной.

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

От чего зависит выбор тестов

Существуют факторы, которые на постановку цели не влияют, а на постановку задачи для тестировщиков — еще как.

Фактор 1. Вид разрабатываемого приложения / информационной системы

Самый очевидный фактор. Под видом подразумевается архитектура, компоненты. Есть ли UI? Есть ли БД? Веб-приложение? Множество сервисов, которые запускаются самостоятельно?

В зависимости от первого фактора всё множество возможных задач на тестирование сокращается на неприменимые (например, не тестируем юзабилити сервисов, запускаемых планировщиком задач) и выделяется множество обязательных (для веб-интерфейса общедоступного приложения обязательно проверяем на уязвимости). Но всё это касается объектов тестирования. в рамках задачи «проведите функциональное тестирование» множество необходимых и достаточных тестов определяется исполнителями при создании тест плана. Знание того, как определять это множество входит в компетенцию QA-специалистов. А значит, эти факторы не влияют не только на определение цели, но и на постановку задач верхнего уровня.

Фактор 2. Объем данных и количество пользователей.

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

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

Фактор 3. Взаимоотношения с разработчиками.

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

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

Фактор 4. Наличие и полнота спецификации.

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

От наличия и полноты документации зависит подготовленность тестов — ad hock или по тестовой модели.

Ну и сама документация может быть объектом тестирования. Нет спеки — нет тестирования спецификации.

Фактор 5. Инструментарий.

Мало смысла в автотестах, если нет CIS. Не будет тестирования белого ящика, если нет доступа к исходникам по средствам VCS. Нагрузочные тесты вообще полностью зависят от того, чем их гонять.

Голыми руками на самом деле очень мало что можно сделать.

Фактор 6. Возможность «залезть в код».

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

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

Наверняка, есть еще какие-то факторы, которые я поленилась сейчас вспомнить. Напишите в комментариях, будьте добры!