Жизнь прекрасна, если имеется вся необходимая тестовая документация. А что делать, если нет? Предлагаем сразу несколько решений этой проблемы.
Жизнь прекрасна, если имеется вся необходимая тестовая документация. А что делать, если нет? Предлагаем сразу несколько решений этой проблемы.
Оглавление
ToggleНа собеседовании на вакансию QA специалиста – кандидата могут спросить, как он будет поступать, если нет тестовой документации. Иногда на такой вопрос не так-то просто ответить.
И в жизни бывают ситуации, когда действительно нет стандартной тестовой документации (или катастрофически мало). Как поступать в таком случае? Представляем 7 вариантов возможных решений.
Самый простое решение — начать изучение программного обеспечения «как есть». Т.е. нажимаем все кнопки, заполняем все поля, кликаем на все ссылки. Одним словом, пробуем все и разными способами, в этом и состоит метод проб и ошибок.
Да, будет много ситуаций, когда программа выполняет непредвиденные и малопонятные операции. Но, по крайней мере, будет протестирована базовая функциональность. А к ней можно добавить и нефункциональное, например, юзабилити-тестирование.
Очень помогает, если имеются описание функционала и другие важные документы, подготовленные в свое время для предыдущей версии ПО. В идеале – если есть тест-кейсы и прочие зафиксированные проверки.
Отталкиваясь от документации прошлых версий, можно подойти к тестированию нынешней сборки. Некоторые тезисы и тесты, конечно, придется актуализировать, но это все равно легче, чем создавать заново.
Есть такое понятие, как «неявные требования». Они проистекают из косвенных источников информации о ПО, т.е. из другой (не-тестовой) документации. Такими косвенными источниками могут быть, например:
Все найденные неявные требования можно перевести в разряд явных – описать их в файле, который так и назвать: «Требования к ПО такому-то». А можно – представить в виде User Story. Их можно согласовать с заинтересованными сторонами и далее использовать для проведения работ по тестированию.
Четвертый вариант решения – это представление программы в виде «черного ящика». Можно создать массив входных данных, пропустить его через ПО и затем проанализировать получившиеся выходные данные. Таким образом получается заметить определенные закономерности и, базируясь на них, проверить ПО на наличие дефектов.
Более подробно про метод черного ящика – см. в статье на нашем сайте.
«Язык до Киева доведет». И уж точно – до требований ПО, если иметь удовольствие побеседовать с другими участниками проектной команды. Напишите список вопросов, которые Вас интересуют касательно разрабатываемого приложения, и задайте их:
Беседовать можно индивидуально, а можно – всем вместе в форме общего совещания. Выбирайте, что Вам удобнее.
Шестой вариант решения – применить метод исследовательского тестирования (ad hoc). Можно начать с самых очевидных сценариев использования ПО – и реализовать тест-кейсы для них. Проанализировать результаты первого шага и сформировать проверки для второго.
Действуя таким образом, шаг за шагом, сделать выводы о качестве ПО.
Код приложения, вообще говоря, тоже документация. Значит, из нее тоже можно извлечь требования. По крайней мере, в ней можно посмотреть, как будут выполняться функции ПО.
Если Вы не сильны в прочтении кода – можно попросить разработчика, чтобы он пояснил примененные алгоритмы. Это поможет разобраться, какие сценарии следует использовать для проверок.
Если тестовой документации еще нет, а тестировать уже надо, то есть 7 вариантов для решения такой проблемы. Их можно использовать по отдельности, а можно в разных комбинациях друг с другом. Тестировщику желательно знать их, чтобы подготовиться к собеседованию в лучшем виде.
Автор Михаил Кулешов
Михаил, профессиональный партнерский маркетолог, является основателем компании South Media OÜ, которая была создана в 2018 году и базируется в Таллинне. С 2016 года Михаил уехал из Финляндии и жил как настоящий «цифровой кочевник» в IT-индустрии, путешествуя по миру только с ноутбуком. Михаил работает и пишет статьи, связанные с IT-индустрией.
© Copyright 2023 Testirovshik.com