Что делать, если нет тестовой документации?

Разбираем сложный случай: отсутствует тестовая документация

На собеседовании на вакансию QA специалиста – кандидата могут спросить, как он будет поступать, если нет тестовой документации. Иногда на такой вопрос не так-то просто ответить.

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

1. Метод проб и ошибок

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

Да, будет много ситуаций, когда программа выполняет непредвиденные и малопонятные операции. Но, по крайней мере, будет протестирована базовая функциональность. А к ней можно добавить и нефункциональное, например, юзабилити-тестирование.

2. Актуализация документации из предыдущих версий ПО

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

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

3. Исследование косвенных источников

Есть такое понятие, как «неявные требования». Они проистекают из косвенных источников информации о ПО, т.е. из другой (не-тестовой) документации. Такими косвенными источниками могут быть, например:

• Запросы, письма и другая документация от заказчика;
• Протоколы совещания по проекту;
• Прототипы и макеты продукта;
• Нормативные правовые акты (законы, постановления, указы и т.п.);
• Стандарты, принятые в отрасли, для которой это ПО разработано;
• Регламенты, описывающие область применения ПО;
• Справочная информация о компании-клиенте;
• Комментарии разработчиков к коду;
• Традиции и обычаи делового оборота;
• Договоренности в команде;
• Личный профессиональный опыт.

Все найденные неявные требования можно перевести в разряд явных – описать их в файле, который так и назвать: «Требования к ПО такому-то». А можно – представить в виде User Story. Их можно согласовать с заинтересованными сторонами и далее использовать для проведения работ по тестированию.

4. Метод черного ящика

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

Более подробно про метод черного ящика – см. в статье на нашем сайте.

5. Интервью с бизнес-аналитиками, дизайнерами, разработчиками

«Язык до Киева доведет». И уж точно – до требований ПО, если иметь удовольствие побеседовать с другими участниками проектной команды. Напишите список вопросов, которые Вас интересуют касательно разрабатываемого приложения, и задайте их:

• Бизнес-аналитикам, которые наверняка беседовали с клиентом о данном ПО;
• Дизайнерам, которые создавали макеты и т.д. для работы ПО;
• Разработчикам, которые имеют представление, как они будут реализовать те или иные функции ПО.

Беседовать можно индивидуально, а можно – всем вместе в форме общего совещания. Выбирайте, что Вам удобнее.

6. Метод «ad hoc»

Шестой вариант решения – применить метод исследовательского тестирования (ad hoc). Можно начать с самых очевидных сценариев использования ПО – и реализовать тест-кейсы для них. Проанализировать результаты первого шага и сформировать проверки для второго.

Действуя таким образом, шаг за шагом, сделать выводы о качестве ПО.

7. Изучение кода ПО

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

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

Резюме

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