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