Здравствуйте! Я хоть и не начинающий тестировщик, но на последнем проекте, где я работаю, есть проблема с документацией требований к функционалу. Соответственно задача на тестирование часто приходит в неготовом виде, приходится собирать информацию по крупицам, чтобы понять, что необходимо проверить, и это реальная боль. В последнее время участились случаи, что приходят задачи с настолько неявными требованиями, что даже сложно догадаться, что существует еще какое-то неописанное в задаче требование, которое необходимо найти для успешного завершения задачи. У меня на этой почве разгораются нешуточные баталии с аналитиком и менеджментом. Хотелось бы попросить помощи бывалых в оценке двух кейсов: чисто абстрактно - что не хватает в этой постановке задачи, как бы вы походили к изысканию дополнительной информации к этой задаче, какие бы вопросы себе задали:
Кейс 1.
Постановка задачи: Необходимо переделать все наши печатные формы после настройки синхронизации справочника ААА с конфигурацией БББ. Далее идет перечень форм.
Далее в комментариях к задаче выясняется, что формы проверять не надо, а надо проверять синхронизацию данных между конфигурацией1 и конфигурацией2. Это все не отдельной задачей - а в комментариях к основной задаче на проверку форм.
Далее разработчик указывает данные, которые должны прийти из конф.2 в конф.1.
Тестировщик проверяет, что при синхронизации данные из конф.2 успешно приходят в конф.1. Перед синхронизацией данных выполняется типовое регламентное задание, без которого синхронизация не может произойти.
Далее задача успешно отправляется к заказчику и так же успешно от него возвращается на доработку с припиской, что синхронизация не происходит, данные не приходят.
Аналитик обвиняет тестировщика, что протестировано неверно. В разговоре выясняется, что на проде нельзя по определенным причинам выполнять описанное выше регламентное задание, без которого не происходит синхронизация. Разработчик этого не учел. Тестировщик о подобном нюансе не знал.
Вопрос - как избежать подобных эпикфейлов в будущем. Есть ли ошибка в постановке задачи. Как тестировщик мог узнать о таких тонкостях, если в документации по проекту такие ограничения не прописаны? Предположить об их существовании он не мог.
Кейс 2. Постановка задачи: Реализовать выгрузку из ААА в банк-клиент валютных платежей в формате xml.
Разработчик пишет инструкцию по проверке:
- Открыть обработку "Обмен с банком"
- В левом нижнем углу отображается кнопка "Выгрузить в xml-файл".
- Выбрать Период, Организацию, счет (валютный)
- В табличной части выбрать платежки для выгрузки
- Нажать кнопку "Выгрузить в xml-файл".
- Ожидаемый результат: появится диалог выбора каталога для сохранения файла. Указать в нем имя файла, либо выбрать имеющийся документ xml.
- После нажатия на кнопку "Сохранить" в диалоговом окне выбранные документы будут выгружены в указанный файл. Сообщение о недопустимых символах будет выведено информационно.
Тестировщик проверяет. Платежки выгружаются в файл корректно. Файл создается в нужном формате.
Задача возвращается на доработку по причине, что оказывается не должно быть на форме отдельной кнопки "Выгрузить в xml-файл", а файл должен создаваться при нажатии стандартной кнопки выгрузки в банк, при этом система должна распознать, что выгружается именно валютная платежка и вместо стандартного текстового файла обмена, который создавался для рублевых платежей, создать xml-файл с валютными платежами.
Соответственно обвиняют тестировщика, что он не знал, что должно работать именно так. Разработчик получается тоже не знал, что это так должно работать и реализовал выгрузку через отдельную кнопку. По мнению аналитика, тестировщик должен был задаться вопросом, почему реализовали отдельную кнопку и вернуть задачу разработчику, чтобы тот переделал в соответствии с вскрывшимися позднее подробностями к задаче.
Вопрос - где лажает тестировщик? Как в будущем тестировщику избежать подобных ошибок?
Спасибо за внимание и за дельные советы)