Автор: Джоеп Шууркс (Joep Shuurkes)
Оригинал статьи
Перевод: Ольга Алифанова

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

Прежде чем я перейду к сути, отмечу, чего эта статья не касается. Я не буду вдаваться в то, как тест-кейсы влияют на выполнение тестов, и хороши ли кейсы для применения в тестировании. Лично я не думаю, что они несут пользу, и писал о своей неспособности ими пользоваться в июле 2013 года. Если вы хотите глубже изучить вопрос, рекомендую статью Джеймса Баха и Аарона Ходдера "Тест-кейсы – это не тестирование" (часть 1, часть 2).

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

И, наконец, обдумывание этой темы заставило меня осознать неимоверную сложность создания хорошей системы управления кейсами (если эта идея приходит кому-то в голову). Она должна быть очень отзывчивой и быстрой, чтобы не замедлять мою мыслительную деятельность. Она, однако, также должна поддерживать синхронное сотрудничество и запускаться на любой машине (на одном из моих проектов мне нужно было выполнять тесты на одной машине, а обновлять тест-кейсы на другой, находящейся в другом помещении). Она должна поддерживать изображения (рисунки?)и видео, а также иметь массу полей, по которым работает поиск. Навигация по этим данным должна быть простой и быстрой. Я бы хотел иметь возможность привязывать релизы к юзер-сторис, юзер-сторис – к результатам кейсов, результаты кейсов – к кейсам, а также юзер-сторис к фичам, а фичи – к кейсам. Это означает, что фичам и кейсам нужна история изменений, потому что они постоянны, а релизы, юзер-сторис и результаты кейсов относятся к конкретному моменту времени. И, наконец, в ней должны быть продвинутые функции для супер-пользователей, и она должна быть дружелюбной к тем, кто пользуется ей от случая к случаю – возможно, не желая этого. Короче говоря, создание хорошей системы управления кейсами не стоит свеч.

Что такое тест-кейс?

Похоже, существует два основных расхожих определения тест-кейсов.

Первое соответствует определениям, данным ISTQB, TMap, стандартам IEEE 610 (1990) и ISO 29119. Тест-кейс – это набор условий, данных на входе, действий, и ожидаемых результатов. Это определение не уточняет, что кейсы появляются в результате применения техник тест-дизайна, однако их применение подразумевается.

Второе определение встречается мне чаще: тест-кейс – это нечто, что вы хотите протестировать, это относительно специфическая и конкретная тест-идея.

Для проверки своего понимания я опубликовал твит:

"Работаю над статьей, и мне бы пригодились ваши мнения для проверки моих определений и опыта:

1. 1. Используете ли вы кейсы в тестировании?
2. 2. Если да, как они выглядят? Можете показать пример?
3. 3. Фиксируете ли вы эти кейсы и их результаты в инструменте управления тестированием?"

Я получил четыре ответа – что тоже о чем-то говорит, не уверен только, о чем именно. Два человека не использовали кейсы, один вроде как пользовался ими, описывая их как "высокоуровневые заголовки", и один использующий их человек описал их как "список шагов и ожидаемых результатов". Что же касается инструмента управления кейсами, ответы варьировали от "да" до документирования в Jira/Git/Confluence, и до "Нет", потому что "Я хочу, чтобы люди действительно читали и оценивали то, что я пишу".

Повторное использование кейсов

Тест-кейс – это промежуточный продукт

Тестирование требует тест-дизайна и выполнения тестов. Тест-кейсы на самом деле – промежуточный продукт, потому что они – результат тест-дизайна. Проблема с промежуточными продуктами в том, что срок их жизни ограничен. В ходе исследовательского тестирования тест-дизайн и запуск тестов тесно скручены в петлю обратной связи. На другом конце спектра тест может проектироваться несколько дней, прежде чем вы перейдете к его запуску. В любом случае промежуточный продукт (кейс) не становится финальным. Сам по себе он не имеет ценности.

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

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

Повторное использование в легаси и водопаде

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

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

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

Это похоже на бэклоги и трекеры ошибок

И, наконец, управление коллекцией кейсов несет те же проблемы, что и управление коллекцией элементов бэклога или дефектов в баг-трекере. Как-то раз я работал над проектом, в котором ID новых дефектов находился в диапазоне от 3000, а самый старый открытый баг имел ID 42. Когда я поднял этот вопрос в разговоре с тест-менеджером, он сказал, что у него настроен фильтр, игнорирующий все дефекты с ID ниже 2000. Грамотное управление коллекцией тест-кейсов требует смехотворно огромного уровня дисциплины, больших усилий, и хороших инструментов.

Речь не про автоматизацию

И, наконец, отметим, что я не утверждаю, что для повторного использования кейса его надо просто автоматизировать. Для моей позиции нет никакой разницы, кем выполняется тест, человеком или машиной. Я также не думаю, что автоматизация ручных кейсов – это хороший подход к автоматизации. Не буду вдаваться в детали, эта статья про регресс-тестирования и CI/CD описывает мою точку зрения на этот вопрос.

Отчет о результатах прогона кейсов

Покрытие тест-кейсов бессмысленно без формального тест-дизайна

Отчетность о результатах прогона кейсов (количество выполненных кейсов, количество пройденных и упавших) имеет смысл, если вы используете формальные техники тест-дизайна, создавая кейсы на основании набора требований. Количество кейсов тут определяется техниками и требованиями. Если дать одинаковый набор двум разным тестировщикам, они создадут одинаковые тест-кейсы. Подход тут таков: определить все кейсы согласно требованиям тест-стратегии, выполнить все кейсы, и полное (относительно тест-стратегии) покрытие достигнуто!

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

Даже в случае применения формальных тест-кейсов сообщение, что мы прогнали 73 из 114 кейсов, несет ограниченный и крайне зависящий от контекста смысл. Чем более расплывчато определение, что же такое тест-кейс, тем расплывчатее делается заявление, сколько кейсов из общего (актуального) числа вы выполнили.

Как насчет результатов CI/CD?

Если у вас настроены CI/CD, запускающие автотесты, как вы отчитываетесь об их результатах? Их можно импортировать в инструмент управления кейсами, но это противоречит самой сути CI/CD. Они должны быть единственным источником истины, а не какой-то другой инструмент. Разумнее ссылаться на результаты кейсов в конвейере, но для конвейера зеленый результат – это зеленый результат. Нужна ли в нем такая отсылка, если только она не необходима для аудита?

Количество пройденных и упавших кейсов – так себе начало беседы

Продолжая мысль о подсчете тест-кейсов – еще худшей идеей будет отчетность о количестве пройденных и упавших кейсов. Как-то раз консультант показал мне дашборд тест-результатов в инструменте управления кейсами, который он разрабатывал. Я сказал "А, я не пользуюсь таким типом дашбордов". "Любопытно", ответил он, "обычно людям нравятся эти дашборды, но вы ответили точно так же, как ваш менеджер".

Проблема с числами, подсчетами и графиками в ощущении, что они говорят нам что-то важное, что мы получаем хороший обзор состояния дел – но на самом деле это не так. Можно возразить, что эти числа – хороший способ начать разговор. 90% пройденных тестов поведут разговор не в том направлении, куда пойдет беседа о 60% пройденных тестов. Но для старта разговора вам эти числа не нужны. Майкл Болтон пишет, что вопрос "Как дела с тестированием" требует ответа из трех частей: история о продукте и его статусе, история о тестировании, и история о качестве этого тестирования. Соотношение пройденных и упавших тестов – крайне узкий подход к этим трем историям.

Для более глубокого освещения темы рекомендую доклад Рикарда Эдгрена "Вылечим нашу бинарную болезнь".

Тест-кейсы поощряют менеджмент на основании кейсов

Инструменты управления кейсами приглашают менеджеров руководить командой на основании (количества) тест-кейсов. Бывшая коллега рассказывала, что участвовала в проекте, где нужно было прогонять определенное количество кейсов в день. В итоге были придуманы условные кейсы. Если в ходе тестирования в голову приходила тест-идея, она вносилась в "условный" кейс. Если по количеству тестов в день был недобор, можно было прогнать несколько таких условных кейсов. Управление через тест-кейсы настолько же плохо, как плохо управление программистами через строчки кода или количество коммитов. Задача разработчика не в создании строчек кода – хоть они и будут способом достижения цели. То же самое касается тестировщика – их работа не в запуске тест-кейсов, а в предоставлении информации о продукте.

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

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

Как насчет аудита?

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

Альтернатива

Но чем же пользоваться, если не инструментами управления кейсами? На самом деле это два вопроса – что документировать, и посредством какого инструмента это делать.

Для ответа на первый вопрос я предлагаю комбинацию двух вещей – моделей продукта и эвристик для тест-идей.

Модели могут принимать различные формы, воплощения и размеры: архитектурные диаграммы (известные как "прямоугольники и стрелочки"), диаграммы последовательностей, модель SFDIPOT, таблица ACC (Атрибут – компонент – способность)… Это может быть что-то поменьше и поконкретнее ,вроде списка разных типов пользователей – аноним, авторизованный, администратор компании, администратор платформы.

Ряд хороших эвристик для тест-идей можно найти в чит-листе Элизабет Хендриксон и книге Рикарда Эдгрена "Записная книжка тест-дизайнера". В идеале у вас должны быть эвристики для конкретно вашего продукта, основанные на опыте команды.

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

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

Обсудить в форуме