Сообщений в теме: 22

[Elena_Fiolent]

Здравствуйте! Я хоть и не начинающий тестировщик, но на последнем проекте, где я работаю, есть проблема с документацией требований к функционалу. Соответственно задача на тестирование часто приходит в неготовом виде, приходится собирать информацию по крупицам, чтобы понять, что необходимо проверить, и это реальная боль. В последнее время участились случаи, что приходят задачи с настолько неявными требованиями, что даже сложно догадаться, что существует еще какое-то неописанное в задаче требование, которое необходимо найти для успешного завершения задачи. У меня на этой почве разгораются нешуточные баталии с аналитиком и менеджментом. Хотелось бы попросить помощи бывалых в оценке двух кейсов: чисто абстрактно - что не хватает в этой постановке задачи, как бы вы походили к изысканию дополнительной информации к этой задаче, какие бы вопросы себе задали:

 

Кейс 1.

Постановка задачи: Необходимо переделать все наши печатные формы после настройки синхронизации справочника ААА с конфигурацией БББ. Далее идет перечень форм.

Далее в комментариях к задаче выясняется, что формы проверять не надо, а надо проверять синхронизацию данных между конфигурацией1 и конфигурацией2. Это все не отдельной задачей - а в комментариях к основной задаче на проверку форм.

Далее разработчик указывает данные, которые должны прийти из конф.2 в конф.1. 

Тестировщик проверяет, что при синхронизации данные из конф.2 успешно приходят в конф.1. Перед синхронизацией данных выполняется типовое регламентное задание, без которого синхронизация не может произойти.

Далее задача успешно отправляется к заказчику и так же успешно от него возвращается на доработку с припиской, что синхронизация не происходит, данные не приходят.

Аналитик обвиняет тестировщика, что протестировано неверно. В разговоре выясняется, что на проде нельзя по определенным причинам выполнять описанное выше регламентное задание, без которого не происходит синхронизация. Разработчик этого не учел. Тестировщик о подобном нюансе не знал.

Вопрос - как избежать подобных эпикфейлов в будущем. Есть ли ошибка в постановке задачи. Как тестировщик мог узнать о таких тонкостях, если в документации по проекту такие ограничения не прописаны? Предположить об их существовании он не мог.

 

Кейс 2. Постановка задачи: Реализовать выгрузку из ААА в банк-клиент валютных платежей в формате xml.

Разработчик пишет инструкцию по проверке:

1. Открыть обработку "Обмен с банком"
2. В левом нижнем углу отображается кнопка "Выгрузить в xml-файл".
3. Выбрать Период, Организацию, счет (валютный)
4. В табличной части выбрать платежки для выгрузки
5. Нажать кнопку "Выгрузить в xml-файл".
6. Ожидаемый результат: появится диалог выбора каталога для сохранения файла. Указать в нем имя файла, либо выбрать имеющийся документ xml.
7. После нажатия на кнопку "Сохранить" в диалоговом окне выбранные документы будут выгружены в указанный файл. Сообщение о недопустимых символах будет выведено информационно. 

Тестировщик проверяет. Платежки выгружаются в файл корректно. Файл создается в нужном формате.

 

Задача возвращается на доработку по причине, что оказывается не должно быть на форме отдельной кнопки "Выгрузить в xml-файл", а файл должен создаваться при нажатии стандартной кнопки выгрузки в банк, при этом система должна распознать, что выгружается именно валютная платежка и вместо стандартного текстового файла обмена, который создавался для рублевых платежей, создать xml-файл с валютными платежами.

 

Соответственно обвиняют тестировщика, что он не знал, что должно работать именно так. Разработчик получается тоже не знал, что это так должно работать и реализовал выгрузку через отдельную кнопку. По мнению аналитика, тестировщик должен был задаться вопросом, почему реализовали отдельную кнопку и вернуть задачу разработчику, чтобы тот переделал в соответствии с вскрывшимися позднее подробностями к задаче.

 

Вопрос - где лажает тестировщик? Как в будущем тестировщику избежать подобных ошибок?

 

Спасибо за внимание и за дельные советы)

[Сергей]

Лажает не тестировщик, лажает ваш г-но процесс.

[Vasiliy]

Ну да, до тестирования тут еще все ошиблись. Почему вопросы к тестированию то именно?

Менеджмент что говорит на этот бардак?

[Elena_Fiolent]

Ну да, до тестирования тут еще все ошиблись. Почему вопросы к тестированию то именно?

Менеджмент что говорит на этот бардак?

Руководство, непосредственно наблюдающее все это, это руководитель разработки, который в тестировании не понимает, и скрам мастер. Они также склоняются к тому, что тут виноват тестировщик, тк недостаточно копал, чтобы все разузнать и предотварить ошибки. В частности, в кейсе 1 - виноват, что не описал, что делает регламентное задание перед синхронизацией. А тестировщик просто выполнял по типовому механизму, описанному в документации вендора ПО. Т.е. рассчитывал, что аналитик априори знает типовой механизм проведения синхронизации и запустит рег.задание, тк аналитик занимается поддержкой продукта и консультированием пользователей.

[Freiman]

О, люди снова обозвали бардак аджайлом? :)

 

Виноват аналитик, к тестировщику вопросы минимальны.

[Vasiliy]

У вас в каждом пункте указано: разработчик не знал, разработчик не учел. С этим как быть?

 

Ну тогда спросите что значит в их понимании " тестировщик не раскопал"? И почему он должен копать, а не прочитать это в спецификации? 

 

P.S. Есть такая специфика и сами тестировщики ее частенько поддерживают, что требований нет, но это ок и тестировщик должен преодолеть, раскопать, дойти до заказчика и все сделать сам. Хорошо хоть код не предлагается писать)) Я от этого ушел и стараюсь делать процессы, чтобы требования были. А если их и нет, то это недоработка аналитика. И если стадия кодирования уже прошла, то еще вопрос к разработке, что и как они сделали, если требования еще не определены?

[Elena_Fiolent]

У вас в каждом пункте указано: разработчик не знал, разработчик не учел. С этим как быть?

 

Ну тогда спросите что значит в их понимании " тестировщик не раскопал"? И почему он должен копать, а не прочитать это в спецификации? 

 

P.S. Есть такая специфика и сами тестировщики ее частенько поддерживают, что требований нет, но это ок и тестировщик должен преодолеть, раскопать, дойти до заказчика и все сделать сам. Хорошо хоть код не предлагается писать)) Я от этого ушел и стараюсь делать процессы, чтобы требования были. А если их и нет, то это недоработка аналитика. И если стадия кодирования уже прошла, то еще вопрос к разработке, что и как они сделали, если требования еще не определены?

1. Про разработчик не знал и не учел - это отдельная боль((( Часто тоже бывает, что разработчик неправильно понял постановку и выясняется это либо на тестировании, либо уже на приемке. Если это просочится на приемке, то виноват тестер, тк не обнаружил несоответствие на тестировании - и не волнует, что это неявно описано в задаче - ты должен раскопать. Также есть аутсорс-разработчики, которых меняют почти ежемесячно, так что они не успевают понять продукт. Эти уже относятся к категории "не знал" - и опять же тестер должен его проконтролировать в плане соответствия его наработок общепринятым стандартам по продукту. С одной стороны это вроде бы звучит как справедливое требование - ведт  тестировщик на тои тестировщик, чтобы находить несоответствия. Но когда речь заходит о новом функционале - то тут тестер уже не поймет - это так задумано, чтоб задача так работала, или это ошибка разработчика, тк на новый функционал и доработки часто задача приходит в виде "полечите мне температуру".

 

Что ж, я рада слышать, что все же есть места, где процессы рулят, и нормальная постановки задачи - работа аналитика. Я думала, это только в идеале и в книгах есть, а в реальных фирмах - все так же - бардак, и во всем виноват тестер, и он должен сам собирать инфу и уметь работать без требований. Печаль конечно, когда работаешь без требований, на свое усмотрение принимаешь то или иное решение, а потом при приемке условия додумываются на лету, и тестировщика обвиняют во всех грехах...

[Сергей]

Самое тупое что может быть - свалить все на тестировщика.

[Elena_Fiolent]

О, люди снова обозвали бардак аджайлом? :)

 

Виноват аналитик, к тестировщику вопросы минимальны.

Так а разве не аджайл? Именно это наш рук и называет аджайлом))))

[Elena_Fiolent]

Самое тупое что может быть - свалить все на тестировщика.

Это еще не самое тупое. Когда я начинаю им объяснять, почему так произошло, и почему опять пришла постановка задачи не в том виде, и в каком виде мне бы хотелось видеть задачу, чтобы ее решить успешно, а также какие мне нужны еще регдокументы, чтобы на них опираться - вот это вот все называется перекладыванием вины на других))))

[Vasiliy]

 

Самое тупое что может быть - свалить все на тестировщика.

Это еще не самое тупое. Когда я начинаю им объяснять, почему так произошло, и почему опять пришла постановка задачи не в том виде, и в каком виде мне бы хотелось видеть задачу, чтобы ее решить успешно, а также какие мне нужны еще регдокументы, чтобы на них опираться - вот это вот все называется перекладыванием вины на других))))

 

А вы не пробовали сменить работодателя?)

[Elena_Fiolent]

 

 

Самое тупое что может быть - свалить все на тестировщика.

Это еще не самое тупое. Когда я начинаю им объяснять, почему так произошло, и почему опять пришла постановка задачи не в том виде, и в каком виде мне бы хотелось видеть задачу, чтобы ее решить успешно, а также какие мне нужны еще регдокументы, чтобы на них опираться - вот это вот все называется перекладыванием вины на других))))

 

А вы не пробовали сменить работодателя?)

 

да вот уже подумываю))) хотела получить луч надежды, что таки есть места, где работа налажена)))

[wisegrey]

 

 

 

Самое тупое что может быть - свалить все на тестировщика.

Это еще не самое тупое. Когда я начинаю им объяснять, почему так произошло, и почему опять пришла постановка задачи не в том виде, и в каком виде мне бы хотелось видеть задачу, чтобы ее решить успешно, а также какие мне нужны еще регдокументы, чтобы на них опираться - вот это вот все называется перекладыванием вины на других))))

 

А вы не пробовали сменить работодателя?)

 

да вот уже подумываю))) хотела получить луч надежды, что таки есть места, где работа налажена)))

 

Есть такие места. И их, в общем то, наверное даже побольше чем тех, где не налажена. 
Ну, особенно с учётом что налажена\неналажена, это не переключатель, а - шкала =)

[Freiman]

 

 

Самое тупое что может быть - свалить все на тестировщика.

Это еще не самое тупое. Когда я начинаю им объяснять, почему так произошло, и почему опять пришла постановка задачи не в том виде, и в каком виде мне бы хотелось видеть задачу, чтобы ее решить успешно, а также какие мне нужны еще регдокументы, чтобы на них опираться - вот это вот все называется перекладыванием вины на других))))

 

А вы не пробовали сменить работодателя?)

Василий, ханть, человек с головой и за дело болеет :) Это уже половина успеха.

[Vasiliy]

У нас комплект) Да и я сейчас не обладаю подобными полномочиями))

Но тут Сергей в теме. Он ищет, обычно))

[Сергей]

Был бы человек хороший, а вакансия найдётся).

[Elena_Fiolent]

 

 

 

Самое тупое что может быть - свалить все на тестировщика.

Это еще не самое тупое. Когда я начинаю им объяснять, почему так произошло, и почему опять пришла постановка задачи не в том виде, и в каком виде мне бы хотелось видеть задачу, чтобы ее решить успешно, а также какие мне нужны еще регдокументы, чтобы на них опираться - вот это вот все называется перекладыванием вины на других))))

 

А вы не пробовали сменить работодателя?)

Василий, ханть, человек с головой и за дело болеет :) Это уже половина успеха.

 

я еще на машинке вышивать умею (с) 

[Little_CJIOH]

С одной стороны это вроде бы звучит как справедливое требование - ведт  тестировщик на тои тестировщик, чтобы находить несоответствия

 

несоответствия чего с чем?
Если ожидаемый результат тестировщик должен доставать из заказчика - значит аналитик филонил.

[Little_CJIOH]

 

 

 

Самое тупое что может быть - свалить все на тестировщика.

Это еще не самое тупое. Когда я начинаю им объяснять, почему так произошло, и почему опять пришла постановка задачи не в том виде, и в каком виде мне бы хотелось видеть задачу, чтобы ее решить успешно, а также какие мне нужны еще регдокументы, чтобы на них опираться - вот это вот все называется перекладыванием вины на других))))

 

А вы не пробовали сменить работодателя?)

 

да вот уже подумываю))) хотела получить луч надежды, что таки есть места, где работа налажена)))

 

В вашем случае не с процессами проблема, а с мудаками. Процессами это не лечится.

[Elena_Fiolent]

 

 

 

 

Самое тупое что может быть - свалить все на тестировщика.

Это еще не самое тупое. Когда я начинаю им объяснять, почему так произошло, и почему опять пришла постановка задачи не в том виде, и в каком виде мне бы хотелось видеть задачу, чтобы ее решить успешно, а также какие мне нужны еще регдокументы, чтобы на них опираться - вот это вот все называется перекладыванием вины на других))))

 

А вы не пробовали сменить работодателя?)

 

да вот уже подумываю))) хотела получить луч надежды, что таки есть места, где работа налажена)))

 

В вашем случае не с процессами проблема, а с мудаками. Процессами это не лечится.

 

Все, теперь мне с этим жить((( до получения нового оффера