Вопрос из зала: плохо формализованные задачи в ИТ-проекте

[psilonsk]

Comments

[shleyartem]

А можно по подробнее?
1. в чем выражены ее незнание и низкая квалификация?
2. что именно она должна искать в интернете?

Просто сам работаю в сфере разработки ПО и этот вопрос интересен.
В нашей команде мы решаем его сейчас через сценарии BDD и TDD и экспертную комиссию со стороны заказчика. Т.е. пока задача полностью не описаны и заказчик не согласен с принципом ее реализации и проверки результата - за нее даже не принимаются.

[shleyartem]

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

[pardon_mua]

Для начала неплохо было бы понять, этот способ постановки задач принят в компании за норму и так работают все, или это прикол конкретного ПМ

[vorobiev]

Как вариант: ввести практику утверждения тест-планов у РМ, аналитика. И пользоваться ими как поводом для общения и формализации требований.

Если же утверждают не глядя, то при финише итерации получим факап - программа тесты не пройдет.

Если отказываются утверждать, возвращается к дискуссии "из каких документов я могу это узнать?"

[pupirikin]

Когда информация "обтекает" участников проекта -- это всегда вина PM. Хотя тут также видны проблемы не очень опытного тестера

[radost_jane]

1. В чем неопытность тестировщика, на ваш взгляд?
2. "Требовать о письменном уведомлении" - как лучше это делать, напрямую у пм? Через начальника?

[pupirikin]

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

[ext_691068]

2 (на самом деле 3). Самое простое - присылать письмо самостоятельно по итогам устной договоренности. Если в процессе участвую аналитики или лиды разработчиков, можно возложить на них - но это уже от конкретной ситуации и договоренностей зависит.

По моему опыту - в самом начале все равно будет много вопросов. Нужно с этим смириться и показать адекватность при их решении. Не повторять один и тот же вопрос более 3-х раз, а со второго-третьего аналогичного случая в форме предложения или даблчека конкретного решения уже высылать.

[daniel_grishin]

1) собирать вопросы в пакеты, раз в один-два дня присылать их постановщику задачи. Письменно! Обсудить можно и устно

[radost_jane]

4 и 5 порадовали :)) про вопросы отлично конечно, но первый круг - а как это должно быть сделано, если скрины в задаче не предусмотрены для новой фичи? Ответ, а вот посмотри там загрузку файлов, тут также. Прошло какое-то время, тестировщик покапался в функционале, пошел 2ой круг и может быть третий. И получается тестировщик таким жужжащим существом с дурацкими вопросами.

[pupirikin]

Чудес не будет. Если проект плохо управляется, а тестировщика считают просто обузой, то остается только максимально обезопасить свою позицию.

[radost_jane]

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