Можно ли протестировать техническое задание за полчаса?
Вы уже 18-й день готовите тест-кейсы на новый модуль системы. Написана не одна сотня сценариев. Вдруг обнаруживаете, что один из отчетов накладывает ограничение, которое не было нигде задокументировано. Действительно, аналитик забыл ограничить множество значений, а вам теперь переделывать 30% тестовой документации. Естественно, без возможности увеличить сроки своей работы. И как же теперь быть? Сроки поджимают, заказчик ждет результатов, нехватка времени давит со всех сторон, все злятся друг на друга. Можно ли было этого избежать? Определенно да, если уделить немного времени тестированию технической документации.
Как правило, на тестирование требований не выделяют время проекта. Но есть методы экспресс-оценки, которые позволят без больших трудозатрат выявить большую часть ошибок в требованиях — мы рассмотрим их в порядке увеличения затрачиваемого времени.
1 метод. Маркеры неопределенности (< 15 мин на документ до 100 страниц[1])
Метод заключается в поиске по документу (самый простой способ — с использованием поиска через CTRL+F в текстовой редакторе) ключевых слов — маркеров, которые свидетельствуют об ошибках или невозможности протестировать программный продукт.
Например, маркер-конструкция “от… до”: в поле “Сумма займа” допускается ввод целочисленных значений от 10 000 до 600 000 рублей.
Вы, вероятно, видите, в чем здесь ошибка требований: не указано, включаются ли границы множества. Опытный (или, как минимум, знающий теоретические основы тестирования) инженер, добравшись до такого требования, пойдет уточнять у аналитика или команды, потратив некоторое время на ожидание ответа. Новичок же и вовсе может интерпретировать эту фразу, как сам посчитает нужным.
Ниже представлена карта маркеров неопределенности, разделенных на 5 групп:
В зависимости от типа ошибки строится и запрос на исправление или дополнение требования:
Вся новая информация, которую вам предоставят, должна фиксироваться в документе требований или листе согласования. Главное, чтобы ответы не остались в чатах мессенджеров или устных договоренностях.
Текущий список маркеров неопределенности не покрывает всех возможных неопределенных слов. Вы можете использовать его как базу, постоянно дополняя терминами, с которыми встречаетесь на своем проекте.
А для того, чтобы база была наиболее полной и вы в любое время могли обратиться к ней независимо от проекта, я предлагаю совместными силами создать МЕГА-список маркеров неопределенности. Такая своего рода шпаргалка позволит максимально сократить время поиска и не держать большое количество информации в голове. Добавляйте формулировки и отдельные слова, которые считаете неоднозначными или непроверяемыми, в форму. А мы обработаем все результаты и через месяц опубликуем ссылку на общую таблицу, которую все смогут использовать в своей работе. Таблица будет регулярно актуализироваться.
2 метод. Поиск признаков неполноты и неоднозначности (3-5 минут на страницу текста)
Второй метод тестирования технической документации требует уже стопроцентного внимания, но без анализа подробностей. Вы просматриваете документ по диагонали, не вчитываясь в смысл, а цепляя внимание на формулировках и конкретных словах.
Что должно привлечь ваше внимание:
Сложные условия, содержащие несколько логических операторов (И/ИЛИ/НЕ). В текстовом виде просто упустить какие-либо условия. Лучше, если все требования со сложной логикой описываются в виде блок-схем или таблиц.
- “Если номер подарочной карты не найден в БД и пользователь не ввел валидный промокод, стоимость рассчитывается в полном объеме”.
А что, если номер карты введен? А что, если пользователь ввел валидный промокод? Что будет при разных комбинациях условий?
Отсутствующие исключения — условия, для которых не прописана реакция системы в случае негативных сценариев.
- “Система допускает ввод в поле целочисленных значений > 5 000 рублей” (что будет, если мы попробуем ввести 5 000 или меньше?) или “Поле для загрузки файла формата png размером до 10 МБайт” (что, если мы попробуем загрузить файл большего объема или другого формата?)
Отсутствующие исключения могут содержаться в сложных условиях, но могут и не содержаться. Отсутствующее исключение — ошибка всегда. Сложные условия — рисковая зона, на которую следует обратить внимание.
Использование естественного языка. “Покупатель”, “оформить”, “купить”, “подписать”, “согласовать”, “директор” и другие слова, к которым мы привыкли в обыденной жизни и свойственные предметной области. Обращайте на них свое внимание и проверяйте на определенность термина.
- “Пользователь, купивший товар” в интернет-магазине только оплатил товар или получил? Это авторизованный пользователь или любой, кто купил (например, многие интернет-магазины разрешают оставлять отзыв даже незарегистрированным пользователям).
3 способ. Моделирование (время не определено)
Построение различных моделей, схем и таблиц, определяющих внешний вид, свойства и функциональность системы, — один из наиболее эффективных способов тестирования технической документации.
В контексте экспресс-проверки мы не строим комплексные многомерные модели систем, но можем выбирать единичные схемы в зависимости от решаемых задач, Например:
1. Задача: Проверить изменение состояний объекта.
Решение: Модель состояний и переходов. Все возможное статусы объекта располагаются в первой строке и первом столбце. В ячейках указывается, может ли объект перейти из статуса А (строка) в статус В (столбец) и при каком условии. Например, объект переходит из статуса (1) Ожидает обработки в статус (2) Обрабатывается,когда менеджер берет заказ в обработку.
2. Задача: Проверить, что описаны базовые (создание, редактирование, просмотр, удаление) функции.
Решение: Матрица CRUD. В строках отображаются все сущности и связи между ними, в столбцах — Create (сценарии создания), Read (сценарии просмотра), Update (сценарии изменения), Delete (сценарии удаления). В ячейках указываются ссылки на соответствующие сценарии. Например, Сущность “Новость”, Тип сценария “Update”, сценарий “Создание новости”.
3. Задача: Проверить работу функции, агрегирующей данные из разных модулей/форм (например, генерацию отчета)
Решение: Диаграмма окон (возможно использование компонентной диаграммы). Отображаем основную форму и формы, в которых осуществляется управление исходными данными, как прямоугольники, а данные, которыми осуществляется обмен, стрелками. Так вы сможете быстро определить, какие исходные данные надо заменить для проверки и где это сделать.
аким образом, мы рассмотрели, как за ограниченный период времени можно протестировать требования к программному обеспечению (если они есть).
А проводится ли у вас тестирование требований к ПО на проекте и в каком объеме? Хотите улучшить этот процесс и получить подборку самых удобных инструментов и дополнительных рекомендаций? Пожалуйста, ответьте на небольшой опрос, а мы обработаем его результаты и уже в следующей статье постараемся решить все ваши самые актуальные проблемы, возникающие при тестировании требований.
Для того, чтобы вы смогли глубже понимать весь процесс тестирования требований, а также как и где получить исчерпывающую информацию о тестируемом ПО, приглашаем вас на курс “Тестирование без требований: выявление и восстановление информации о продукте“. Под руководством опытного тренера вы научитесь:
- анализировать требования и техническую документацию о продукте;
- получать исчерпывающую информацию;
- задавать правильные вопросы;
- качественно тестировать требования;
- вести коммуникации с руководством о необходимости актуализации требований;
- составлять прозрачные отчеты о качестве ПО.
Также вы получите необходимые чек-листы, таблицы и шаблоны, которые помогут в процессе будущей работы. Практические задания дадут возможность закрепить полученный материал, а обратная связь от тренера — убедиться в верном понимании теории и применении ее на практике.
[1] дано примерное время проверки на наличие ошибок. Дальнейшее время работы зависит от количества найденных маркеров