Ответственность за баги при нетривиальном поведении?
Есть интерфейс с картой и формой под ним. в зависимости от выбранного состояния контролов (много разных чекбоксов, инпутов, селектов и даже 2 сабмита) на карте показываются маркера
соответсвенно тысяча вариантов различных комбинаций заполнения контролов и исходящих результатов
после получения задания я выяснил все возможные варианты поведения которые смог представить в голове. после того как сделал - было совещание с участием менеджера, тимлида, тестера на котором они посмотрели и внесли малые корректировки допустим 3 штуки. добавив их я отправил все в превью, тимлид открыв интерфейс и дернув контролы в другом порядке выдал:
- Бла-бла вот тут баг, че не тестируешь?
- Такое поведения у меня не получается воспроизводить заранее. я тестировал это все 1000 раз но эту комбинацию в голову не пришло сделать
- Я тестирую одну минуту и уже нашел баг бла-бла
- Да но это после того как на 3х совещаниях 4 человека смотрели-тестировали и ничего не видели
- это же очевидно. бла-бла все херово.
ладно забыли
сейчас пришло очень недовольное письмо от заказчика и от начальника компании. заказчик дернул контолы неким новым образом.
теперь начальник пишет в письме что "это же очевидно" "заказчик нашел баг за одну минуту". завтра он спросит с менеджера и тимлида, которые попробуют свалить все на меня. Помогите ))))
magary4 Как мне кажется, конкретно в описанной ситуации, вы переживаете, что вас попытаются обвинить в том, что вы не проработали все возможные варианты сочетаний тригеров. Так вот, описание и проверка всех возможных сценариев работы должно лежать на плечах тестировщика.
Девелопер не должен заниматься тестированием. Вообще. Девелопер должен писать код - плохой или хороший, это уже другой вопрос. Другое дело, что не все руководители (тим-лиды) это понимают, а если и понимают, то не в каждой организации есть возможность так поставить процесс разработки.
Антон: может где-то у вас есть ссылка на статью где написано что такое "описание и проверка всех возможных сценариев работы должно лежать на плечах тестировщика." должен делать QA, а не программист и не "секретарша-тестер-уборщица" по совместительству
Девелопер не должен заниматься тестированием. Вообще.
Если в данной конкретной организации это входит в его обязанности - то, очевидно, должен.
Распределение обязанностей зависит от организации, специфики бизнеса, процесса разработки т.д. Также разумно учитывать, что распределение бывает де факто и де юре.
я тестировал это все 1000 раз но эту комбинацию в голову не пришло сделать
может имеет смысл принять на вооружение методику pairwise и инструмент PICT.
По этой теме есть доклады, вот один из них для примера https://www.youtube.com/watch?v=Bqmuw3ZJ75g
Цель методики заключается в том чтобы из бесчисленного количества возможных комбинаций выбрать те которые обеспечат максимальное покрытие, при минимальном наборе тестов.
P.S. ну и автоматизация тестирования в обязательном порядке, если ее еще нет.
Все очень просто. Требовать в ТЗ наличие тест-кейсов. Или составлять свой доп к ТЗ и утверждать его. По идее, это должны делать QA, но я так понял их нет у вас, так что делать вам.
После этого - посчитать время в внести в бюджет затраты на автоматизацию этих тест-кейсов.
Задача дергать все контролы - это не задача программиста. Если тимлид и руководство требует это от программиста - это просто самодурство и некомпетентность. Программисты тестировать свой код не умеют. Это аксиома.
>> Программисты тестировать свой код не умеют. Это аксиома
ну не совсем так 90% возможных багов программист найти может
но дальше наступает порог когда только QA может "сломать"
>> QA но я так понял их нет у вас
нет, есть типа "девочка-тестер-секретарша-еще+"
ну она как я выше написал тестировала - и ничего не нашла что не удивительно.
У других людей совершенно другой шаблон мышления.
Поэтому вполне обычно, что каждый дергает контролы в своей последовательности. Тестировать баги должен тестировщик - править разработчик. Совершенно понятно, что все нельзя протестировать разработчику.
вот и я о том же что довольно часто разработчик не может обнаружить баг, так как он имеет свою модель поведения в корне отличающуюся от поведения заказчика
да то тут разработчик?
после меня еще сам тимлид тестил а после еще и менеджер и все пропустили
Вообще отвечает за все бос - за это и получает большие деньги. Начальник должен наладить бизнес процесс и пинать всех остальных, чтобы они не лажали и тестировщика и программиста. Недостаточно попинал, значит ошибка на его плечах.
Ошибка разработчика в том, что он сделал что-то наперекор босу, то, что его не просили или он не проинформировал. За остальные ошибки отвечает руководство, считай - некомпетентно управляют людьми.
Просто есть такая фишка - свалить вину, найти крайнего.. У сильного всегда бессильный виноват.. Тут приходится выбирать, либо принять не заслуженную вину либо другие последствия...
Игорь: Есть производственный процесс в к котором у каждого своя область ответственности. То что баг пропущен - это больше виноват тестировщик. Это его работа. А затем начальство должно решить хорошо он тестировал или нет, проверить его работу. Если плохо - то это маячок - предупреждение, если повторно плохо - выговор. Вопрос в количестве багов и функционирование тестировщика. В случае если программер кучу багов делает - надо на него начальству настучать и сказать, что он рукожоп, а там уж пусть они решают сами. Но валить вину на программера это неправильно в любом случае.
Игорь: Такие моменты надо оговаривать при трудоустройстве сразу, объяснять сотрудникам бизнес-процессы. То есть де факто ты программист и тестировщик , а де юре только программист. "Нам нужен в штат и швец и жнец и на дуде игрец, поэтому он и будет получать кучу денег и за косяки по башке.." Короче есть правила игры по которым нужно играть, а не выдумывать. Может программист виноват в том, что электричество отключили или уборщица плохо пол помыла? Есть организации где все через ... короче сплошной беспорядок, но стоит ли на них равняться?
Игорь: И к чему Вы клоните? С такой логикой программист должен еще и утюги чинить? Если фирма нормальная, то там программист программирует, тестировщик тестирует. Каждый отвечает за своё. Если фирма-колхоз, то там и окна могут красить и комнату пылесосить заставлять...
К тому, что вы не в курсе как там оно де юре, хотя пишите об этом. Представление о том, что такое де юре у вас неверное. Цитирую:
То есть де факто ты программист и тестировщик , а де юре только программист.
Так вот де факто от ТСа требуют оттестировать код. А как де юре - написано у него в должностной инструкции, которую никто из нас не видел (подозреваю, что и ТС не в курсе, что там написано, хотя он её должен был подписывать). Я примерно представляю, что там написано, потому что я такие инструкции составлял сам.
В общем де юре - это по документам, а не то, что вам хочется считать.
Если фирма нормальная, то там программист программирует, тестировщик тестирует. Каждый отвечает за своё. Если фирма-колхоз, то там и окна могут красить и комнату пылесосить заставлять...
А это кто должен определять как правильно? Лично вы? Вы крупный специалист по выстраиванию бизнес-процессов или команд? С чего должно быть так, как вы считаете?
Игорь: > Я примерно представляю, что там написано, потому что я такие инструкции составлял сам.
Ну тогда Вы тоже не знаете, там может быть написано, что угодно. Я веду речь о том, что если ничего не написано, то и разговор сразу закрыт.
>В общем де юре - это по документам, а не то, что вам хочется считать.
Ну я собственно так и говорю, вижу, что то, что я пишу Вы читаете между строк :D
> это кто должен определять как правильно? Лично вы? Вы крупный специалист по выстраиванию бизнес
>процессов или команд? С чего должно быть так, как вы считаете?
Рынок это определяет. Если команда выпускает качественный продукт, который продается десяток лет, то бизнес процессы там налажены. Если продукта нет, а есть отмывание денег и прикрывание пятой точки, то фирма- колхоз. Они функционируют до наступления кризиса и потом оттуда все бегут. По-моему это очевидно.
В данном случае с заказчиком проблемы - и следовательно бизнес процесс настроен неправильно. Получит по башке разработчик, а тестировщик так и будет косячить, начальник получит премию и так повториться еще не раз, прибыли станет меньше - фирма разориться.
Ну тогда Вы тоже не знаете, там может быть написано, что угодно. Я веду речь о том, что если ничего не написано, то и разговор сразу закрыт.
С большой долей вероятности там написано что-то типа "обеспечивать разработку и программирование". И, поскольку, нет определения, входит в это тестирование или нет (как то точно входит, разраб же запускает приложение, пробует что-то как минимум), то де юре вполне тестирование входит в обязанности программиста в данной организации.
Ну я собственно так и говорю, вижу, что то, что я пишу Вы читаете между строк :D
это я не понял.
Рынок это определяет.
А вы типа от имени рынка говорите как должно быть? Это вас сам рынок такими полномочиями наделил?
Игорь:
>то де юре вполне тестирование входит в обязанности программиста в данной организации.
Если захотят свалить вину, то свалят.
>А вы типа от имени рынка говорите как должно быть? Это вас сам рынок такими полномочиями наделил?
У рынка есть невидимая рука.
То есть Вы не видите причинно-следственной связи, между успехами компании, высокими зарплатами и хорошим отзывами сотрудников о компании и налаженными бизнес-процессами?
Конечно свалят. Только не надо рассказывать, что де юре они будут не правы. Кстати и де факто тоже будут правы, если в компании нет тестировщиков и там принято тестировать самому.
(С оговоркой на методику оценки качества приёмочного тестирования конечно).
У рынка есть невидимая рука.
Угу, про эту "руку" уже только ленивый не шутил. А вы, я вижу, изучали работы Адама Смита. Знаете, наверное, что этот термин означает и когда применяется. Что насчёт других экономистов, изучали? Более современные экономические теории там всякие.
То есть Вы не видите причинно-следственной связи, между успехами компании, высокими зарплатами
Конечно вижу. Например - обратная связь. Вот в макдональдсе какие зарплаты?
и хорошим отзывами сотрудников о компании
Это часто никак не влияет, особенно в малом и среднем бизнесе. Да и в крупной промышленности также зачастую.
и налаженными бизнес-процессами
Вы, случаем, не путаете налаженные бизнес-процессы и раздувание штата?
Ну это когда объёмы работ такие, что работу и один человек может выполнять (к примеру разрабатывать и тестировать), а вместо этого берут двух человек, и каждый из них пол дня во вконтактике сидит?
И это я ещё не говорю, что двух человек уже организовывать нужно, плюс коммуникационные издержки.
Игорь:
>Конечно свалят. Только не надо рассказывать, что де юре они будут не правы. Кстати и де факто тоже будут >правы, если в компании нет тестировщиков и там принято тестировать самому.
Вопрос в том, кто из-за этого теряет деньги? Программист уйдет в нормальную контору и заказчик тоже. У ТС все таки был тестировщик. Ну а если тестировщика нет, то все равно программист не сможет все так полноценно протестировать, как тестировщик, у него тем более вообще свои шаблоны проверки, а юзер сядет и ткнет совершенно не туда. Закон Мерфи... И если руководство возлагает ответственность на программиста, то оно рискует. Кто прав и кто виноват на самом деле не важно.
>Это часто никак не влияет, особенно в малом и среднем бизнесе. Да и в крупной промышленности также зачастую.
Из компании где все фигово сотрудник просто валят туда где получше... А отзываться плохо о компании откуда кто-то свалил вряд ли кто будет :)
>Что насчёт других экономистов, изучали? Более современные экономические теории там всякие.
Вижу сказать ничего конкретного нет.
>Конечно вижу. Например - обратная связь. Вот в макдональдсе какие зарплаты?
Для квалификации таких сотрудников весьма неплохо - прямая связь.
>Вы, случаем, не путаете налаженные бизнес-процессы и раздувание штата?
Если в штате 5 программистов, почему бы не нанять одного тестировщика? Ну или наладить как вариант круговое тестирование или заставить программиста написать юнитесты.
>а вместо этого берут двух человек, и каждый из них пол дня во вконтактике сидит?
Не знаю почему Вы себе так налаженные бизнес процессы представляете. Если человек сидит вконтакте, то это явно в них полный провал. Налаженные бизнес-процессы - оптимизация рабочего времени и денег.
Вопрос в том, кто из-за этого теряет деньги? Программист уйдет в нормальную контору и заказчик тоже.
Возможно никто и не теряет. И программист никуда не уйдёт (не шибко то он нарасхват я думаю), да и заказчик не факт что уйдёт. Есть куча других факторов, которые могут держать (уникальный продукт, цена, связи и т.д.).
Это вам, как программисту, кажется, что отдел разработки - прям центр формирования прибыли. А возможно, там прибыль формируется отделом маркетинга. А чего там программисты наработают - дело десятое.
У ТС все таки был тестировщик.
Действительно был. Как то я не заметил.
Ну а если тестировщика нет, то все равно программист не сможет все так полноценно протестировать
Если ему позволяет квалификация, то может.
И если руководство возлагает ответственность на программиста, то оно рискует.
Руководство рискует так или иначе. Работа такая. Возможно в данном случае это не настолько серьёзные риски, чтобы у руководства об этом голова болела. У руководства задач полно, в т.ч. наверняка более важных.
Из компании где все фигово сотрудник просто валят туда где получше
Это если есть куда свалить. Прям всех ждут с распростёртыми объятиями. Если было бы так, то все бы работали в идеальных компаниях. Но что-то мы этого не наблюдаем.
>Что насчёт других экономистов, изучали? Более современные экономические теории там всякие.
Вижу сказать ничего конкретного нет.
Какой конкретики вы ждёте? Расскажите, изучали других экономистов? В курсе, что положения, на котором основаны идеи "невидимой руки рынка", давно уже признаны несостоятельными?
Говорить про "невидимую руку рынка" в наше время, всё равно что ссылаться на законы алхимии.
Для квалификации таких сотрудников весьма неплохо - прямая связь.
В чём именно связь? Чего им не повышают зарплаты то? Вы ж говорите:
То есть Вы не видите причинно-следственной связи, между успехами компании, высокими зарплатами
Если в штате 5 программистов, почему бы не нанять одного тестировщика?
Не знаю, возможно не нужно. Везде своя ситуация.
Ну или наладить как вариант круговое тестирование или заставить программиста написать юнитесты.
Ну вот почему бы программистам самим это не делать? Почему нужен кто-то, кто будет заставлять? Ну раз такие грамотные?
Или может не такие грамотные? Ну тогда пусть сидят и помалкивают.
>а вместо этого берут двух человек, и каждый из них пол дня во вконтактике сидит?
Не знаю почему Вы себе так налаженные бизнес процессы представляете.
С чего вы взяли, что я их себе так представляю? Вы внимательно прочитали, что я написал?
Налаженные бизнес-процессы - оптимизация рабочего времени и денег.
Вот именно. Поэтому первый вопрос, который нужно задать - не будет ли проведение оптимизации стоить больше, чем на ней потом сэкономят. Оптимизация (и построение бизнес-процессов) сама по себе не происходит, она денег стоит.
Средний
