Еще в 2018 году я писал о важности правильной тестовой документации и подчеркивал необходимость бережливого (lean) подхода:
Делайте документацию минимальной, но достаточной для качественного результата. Чем меньше времени вы тратите на описание, тем больше остается на саму работу.
В стартапах вы фокусируетесь на импактах и эффективности. В зависимости от компании и ситуации, вы можете сосредоточить внимание на других вещах, и в итоге прийти к разным выводам в отношении тестовой документации.
В целом, правильная тестовая документация — это та, которая достигает цели для нужной аудитории и с оптимальными затратами. Чаще всего это означает сосредоточение на минимальном объеме документации, необходимом для качественного выполнения вашей работы.
Главные вопросы
🎯 Цель
Всякий раз, когда мы пишем тестовую документацию, нам необходимо понять, чего мы пытаемся ею достичь. Мы пытаемся решить проблему? Передать что-то? Задать вопрос? Оформить свои идеи?
Имея достаточно четкую цель (даже если цель — просто написать что-то для саморефлексии), мы должны понять свою аудиторию.
🧑 Аудитория
Возьмем, к примеру, цель: «документировать, как работает функция». Мы предполагаем, что аудитория — это мы сами (или наша команда). Для достижения этой цели мы можем описать, как настроить функцию, перечислить несколько значений, которые она принимает. Затем предоставить минимальный контекст о ее предназначении и дать ссылку на документацию.
Если цель изменится на «документировать, как работает функция, для наших клиентов», придется приложить больше усилий, учитывая особенности аудитории. Мы можем нанять профессионального технического писателя, предоставить соответствующий контекст, чтобы помочь ему понять, что он читает, и использовать тон, соответствующий клиентской документации.
То же самое касается тестовой документации: кто ее основные читатели? Мы? Клиент (который получит отчет о тестировании)? Мы помогаем команде пользоваться нашим приложением (dogfooding)? Или мы предоставляем обратную связь внутренним стейкхолдерам? Важно помнить, что аудитории разные.
💰 Затраты
Создание и поддержка документации требуют времени и усилий, и, следовательно, требуют определенных затрат, как на создание, так и на поддержку. Как убедиться, что деньги потрачены с пользой?
Мы должны сосредоточиться на том, чтобы документация была эффективной, задав себе несколько вопросов:
- Используем ли мы правильную тестовую документацию в правильных местах? (Используя стандартную форму и шаблоны).
- Насколько нам нужна трассируемость? Если мы трассируем что-то, кто этим управляет? (Вам нужно иметь возможность указать на конкретных стейкхолдеров, чтобы оправдать затраты).
- Насколько поддерживаемой должна быть тестовая документация? Какой срок службы должен быть у этих документов? Это определит, являются ли затраты на документацию конечными или постоянными. (Убедитесь, что вы учли компромиссы: парадокс пестицида, скорость обучения и т. д.).
🧠 Собираем необходимую информацию
Программные приложения, как правило, представляют собой набор отдельных систем, которые созданы разными людьми.
Тестирование — это поиск информации. Чтобы собрать информацию о приложении, нам нужен способ создать небольшую выборку тестов (или экспериментов), которые помогут изучить приложение. Эта выборка тестов должна быть небольшой, но при этом достаточной для исследования приложения. Исходя из этого, мы определяем, приближаемся ли мы к нашей цели тестирования, и корректируем подход, если нет.
Как, помня об этих принципах, создать стратегию отбора тестов для сложного комплекса систем, чтобы успешно реализовать нашу задачу?
Нам нужно создавать модели, документировать подсистемы продукта, выявлять потенциальные риски и, как правило, использовать инструменты, которые помогают управлять сложностью системы и сводить эту сложность к чему-то осязаемому. Для этого понадобятся следующие тестовые артефакты:
- Тестовые хартии (Charters)
- Таблицы решений (Decision Tables)
- Диаграммы потоков данных (Data Flow Diagrams)
- Списки рисков (Risk Lists)
- Ментальные карты (Mindmaps)
Как только мы видим, что уже хорошо изучили систему, нам нужно выяснить, какие тесты следует применять и как. В результате могут появиться:
- Код
- Процедуры
- Таблицы
- Списки идей для тестирования (Lists of Test Ideas)
- Карты покрытия (Coverage Maps)
Сложность заключается в том, чтобы выбрать способ применения документации, который поможет нам добиться главных целей.
💡 Правильные подходы
Как менеджер, я давно утверждаю, что в большинстве случаев написание всей (или большей части) тестовой документации является ненужными затратами. Человек, которому поручено тестирование приложения, должен определить, что он должен делать, и найти наиболее эффективный способ сделать это. Это подразумевает создание правильной тестовой документации для конкретной потребности.
Возвращаемся к основному принципу:
Сосредоточьтесь на минимальном объеме документации, необходимом для качественного выполнения вашей работы. У вас ограниченное количество времени, и если вы потратите слишком много на создание документации, у вас останется меньше времени на выполнение самой работы.
Применяя эту политику — сосредотачиваясь на правильной документации для правильной цели, аудитории и затрат — мы пишем более качественные документы, и создаем более качественное программное обеспечение, тратя свое время на то, что действительно важно: тестирование.
