Почему нет требований
«Строго говоря, не существует приложений без требований. Это было бы приложение, которое не делает ничего конкретного, а просто представляет собой строки кода и больше ничего, лестница в никуда.
Любое приложение имеет требования, так как оно нацелено на решение конкретной задачи; или оно является решением проблемы пользователя. Поэтому приложения без требований невозможны.
Однако приложения без документированных требований — это реальность, с которой большинство из нас сталкивается достаточно часто. Бывают также ситуации, когда документация недостаточна, неточна или ужасно устарела. Такой кейс тоже будем считать «отсутствием требований».
В целом, нет замены хорошо прописанным функциональным/системным требованиям, с проработанными сценариями использования и макетами экранов. Хотя надо отметить, что ныне, в связи с ускорением циклов разработки и сменой парадигмы в сторону минимизации (или полного отсутствия) документации, отсутствие требований становится как бы правилом.
Ситуации
Данная статья представляет собой попытку рассказать о некоторых подходах, которые мы использовали, когда оказывались в подобных ситуациях.
Но для начала рассмотрим несколько причин, по которым документация может отсутствовать:
- Возобновление закрытого/отложенного проекта
- Документация не соответствует формату работы в проекте
- Документация может существовать, но не быть подробной и полной
- Непрерывные релизы и отсутствие архивации информации, связанной со старыми версиями, что приводит к разрыву в понимании того, как существующая функциональность влияет на новую
Все это — препятствия, которые мы, тестировщики, должны смело преодолевать и выходить из них победителями.
3 основных метода тестирования приложения без требований
Метод №1:
Работайте с любой документацией, которая попадет вам в руки. Это может быть просто бэклог в agile-проектах, help-файл, электронное письмо, старая версия BRD/FRD-требований, старые тест-кейсы и т.д.
Проведите «расследование», поспрашивайте, всегда найдется какой-нибудь документ, даже если он будет не слишком релевантным.
Если найти документацию не удается, не сбрасывайте со счетов свой опыт как пользователя. Например, если вам нужно протестировать операцию зачисления средств на банковский счет, никому не нужно рассказывать, как это сделать, не так ли? Ведь все мы, как клиенты интернет-банкинга, знаем, что и как, какие базовые требования.
Согласен, что не все ситуации будут такими простыми, но, опять же, они могут быть и такими.
Метод № 2:
Использовать старую/текущую версию приложения в качестве образца для тестирования будущего релиза. Конечно, это противоречит интуитивному правилу «Не писать тест-кейсы, имея лишь приложение». Однако, когда мы в не самой лучшей ситуации, приходится подстраивать правила под свои нужды.
При этом необходимо учитывать следующее:
- Приложение может содержать дефекты, поэтому если например после регистрации система сразу переводит вас на Screen1 (некий гипотетический экран для примера) — не считайте это правильным поведением. Кроме того, если поле содержит буквенно-цифровые символы, похожие на тестовые данные — уточните это и и так далее.
- Вообще будьте внимательны, используя старые версии, будьте критичны и все уточняйте.
Метод №3:
Пообщайтесь с членами команды проекта.
- Скорее всего вам нужно будет побывать на их митингах.
- Спросите, можете ли вы участвовать на этапах модульного и интеграционного тестирования.
- Если нет, спросите, может ли dev-команда поделиться результатами модульного и интеграционного тестирования.
- Договоритесь о времени передачи знаний в удобное для вас время.
На практике
Для примера, есть сайт магазина, на котором можно добавлять товары в корзину. В идеале, если бы была документация, в ней должно быть описано, как добавлять товары в корзину, сколько товаров в ней может быть в данный момент времени, что произойдет, если добавленный вами товар вдруг исчезнет из продажи, какое максимальное количество одинаковых товаров вы можете купить одновременно и т.д. Допустим наша ситуация такова, что на данный момент НИЧЕГО из этого у нас нет.
Применение метода № 1:
Найдите любую доступную документацию. Спросите у своей команды разработчиков, есть ли у них макеты экранов, вьюшки в ALM-инструменте, или вообще что-либо. Если что-то найдете, это будет хорошей отправной точкой.
Если же этот метод ничего не дает, можно воспользоваться интуицией тестировщика.
Мы все знаем, как работают корзины на сайтах магазинов, поэтому сделайте свои предположения и выработайте несколько основных тестовых сценариев, вроде этих:
- Товары могут быть добавлены в корзину после просмотра или поиска
- После добавления товаров в корзину список товаров должен обновляться
- Пользователь должен иметь возможность продолжить покупки после добавления нескольких товаров в корзину
- Добавление одного и того же товара дважды приводит к увеличению количества добавленных товаров
- Товары могут быть обновлены
- Товары могут быть удалены
- Итоговая сумма покупки должна быть равна сумме цен всех добавленных товаров
- Стоимость доставки должна быть добавлена соответствующим образом
Можно продолжать и дальше, но я уверен, что вы поняли.
Метод № 2:
Если имеется старая версия приложения, это должно помочь при написании тест-кейсов, поскольку в них должны быть точно описаны шаги, где что нажимать, где вводить, что проверять и т.д. Скриншоты и макеты — если они доступны, тоже будет отлично.
Как видно из приведенного ниже скриншота, эти вещи очевидны — названия полей, кнопки и другие визуальные элементы.
Старые тест-кейсы сценарии разумеется нужно будет дополнить новыми релевантными действиями проверки появившейся функциональности.
Метод №3:
Составьте свой список вопросов и отнесите/отправьте его бизнес-аналитику, разработчику, или даже клиенту, и попросите разъяснений.
Скорее всего, именно у бизнес-аналитика вы получите практически всю информацию, необходимую для тест-кейсов, с такой же уверенностью, как и при наличии подробной документации.»
