Перейти к содержимому

Программирование на C# для тестировщиков
онлайн, начало 19 июля
SQL: Инструменты тестировщика
онлайн, начало 18 июля
Командная строка: инструменты тестировщика
онлайн, начало 18 июля
Chrome DevTools: Инструменты тестировщика
онлайн, начало 18 июля
Фотография

"Воспитание" разработчиков через неполные баг-репорты


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 25

#1 aksi

aksi

    Активный участник

  • Members
  • PipPip
  • 112 сообщений
  • ФИО:Ольга Алифанова
  • Город:Санкт-Петербург


Отправлено 18 Июнь 2015 - 07:11

Наткнулась тут на пост западного тестировщика, который пишет, что дрессирует своих разработчиков, заводя сообщения об опечатках, но не указывая, где опечатка найдена. Мол, вот помучаются они, поищут - будут в следующий раз внимательнее текст набирать, а не абы как, все равно тестировщик найдет.

 

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

 

Ну или как-то так:

img_3728.1434611214.jpg

 

Бывают ли вообще ситуации, в которых оправдано применение подобной тактики (не для опечаток, а в принципе - намеренно упустить что-то в баг-репорте, чтобы разработчик глубже копнул)?


  • 0

#2 Molechka

Molechka

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 203 сообщений
  • ФИО:Ольга Назина (Киселева)
  • Город:Москва


Отправлено 18 Июнь 2015 - 07:13

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

А вот по поводу картинки ржу — у меня архитектор периодически говорит "Я в коде видел пару баг, которые до сих пор не завели. Не скажу где, раз не нашли → 

это никому не нужно" )))


  • 1
Автор сайта для начинающих тестировщиков http://testbase.ru/
Автор портала проверки названий багов http://bugred.ru/
Веду блог http://okiseleva.blogspot.com/

#3 horhe

horhe

    Активный участник

  • Members
  • PipPip
  • 100 сообщений
  • ФИО:Юрко
  • Город:Kraków

Отправлено 18 Июнь 2015 - 07:36

Офигеть эффективно, когда разработчик вместо того чтобы быстро пофиксить, тратит пол дня на поиски.  Не говоря уже об элементарном уважении чужого труда и времени. Ничего кроме дополнительных конфликтных ситуаций это не даст. Если, конечно, тестировщику не абсолютно всё равно на результат. Моим за такие багрепорты влетало. 


  • 0
Piobaireachd isn't mysterious, difficult or hard - it's just music...

#4 aid

aid

    Опытный участник

  • Members
  • PipPipPipPip
  • 445 сообщений
  • ФИО:Николай


Отправлено 18 Июнь 2015 - 07:43

 

Бывают ли вообще ситуации, в которых оправдано применение подобной тактики (не для опечаток, а в принципе - намеренно упустить что-то в баг-репорте, чтобы разработчик глубже копнул)?

 

Да. Когда вы работаете не в одной компании с разработчиками и ограничены в средствах, которыми можете проводить тестирование. Я несколько раз слал репорт фактически без описания шагов воспроизведения, только результат.


  • 0

#5 aksi

aksi

    Активный участник

  • Members
  • PipPip
  • 112 сообщений
  • ФИО:Ольга Алифанова
  • Город:Санкт-Петербург


Отправлено 18 Июнь 2015 - 07:46

 

 

Бывают ли вообще ситуации, в которых оправдано применение подобной тактики (не для опечаток, а в принципе - намеренно упустить что-то в баг-репорте, чтобы разработчик глубже копнул)?

 

Да. Когда вы работаете не в одной компании с разработчиками и ограничены в средствах, которыми можете проводить тестирование. Я несколько раз слал репорт фактически без описания шагов воспроизведения, только результат.

 

 

Я работала в компании, где репорты мы в Корею отправляли, и не имели возможности копаться в коде - нам бы корейские партнеры просто завернули репорт без шагов

 

 

Офигеть эффективно, когда разработчик вместо того чтобы быстро пофиксить, тратит пол дня на поиски.  Не говоря уже об элементарном уважении чужого труда и времени. Ничего кроме дополнительных конфликтных ситуаций это не даст. Если, конечно, тестировщику не абсолютно всё равно на результат. Моим за такие багрепорты влетало. 

 

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


  • 0

#6 aid

aid

    Опытный участник

  • Members
  • PipPipPipPip
  • 445 сообщений
  • ФИО:Николай


Отправлено 18 Июнь 2015 - 07:49

 

 

 

Бывают ли вообще ситуации, в которых оправдано применение подобной тактики (не для опечаток, а в принципе - намеренно упустить что-то в баг-репорте, чтобы разработчик глубже копнул)?

 

Да. Когда вы работаете не в одной компании с разработчиками и ограничены в средствах, которыми можете проводить тестирование. Я несколько раз слал репорт фактически без описания шагов воспроизведения, только результат.

 

 

Я работала в компании, где репорты мы в Корею отправляли, и не имели возможности копаться в коде - нам бы корейские партнеры просто завернули репорт без шагов

 

А вы работали на одну компанию и на один продукт? У меня не завернули бы. Была волшебная кнопка "оставить без денег".


  • 0

#7 aksi

aksi

    Активный участник

  • Members
  • PipPip
  • 112 сообщений
  • ФИО:Ольга Алифанова
  • Город:Санкт-Петербург


Отправлено 18 Июнь 2015 - 07:51

 

А вы работали на одну компанию и на один продукт? У меня не завернули бы. Была волшебная кнопка "оставить без денег".

 

Они делали игру, а мы ее в России крутили, игру эту. Они получают отчисления и заинтересованы, чтобы наши игроки были довольны. Но в репорте все равно должны были быть подробности, видео, скриншоты, максимум всего, что поможет им разобраться (учитывая, что переписка на неродном для обеих сторон языке, это само по себе уже "шум" в переписке создает).


  • 0

#8 aid

aid

    Опытный участник

  • Members
  • PipPipPipPip
  • 445 сообщений
  • ФИО:Николай


Отправлено 18 Июнь 2015 - 08:05

 

 

А вы работали на одну компанию и на один продукт? У меня не завернули бы. Была волшебная кнопка "оставить без денег".

 

Они делали игру, а мы ее в России крутили, игру эту. Они получают отчисления и заинтересованы, чтобы наши игроки были довольны. Но в репорте все равно должны были быть подробности, видео, скриншоты, максимум всего, что поможет им разобраться (учитывая, что переписка на неродном для обеих сторон языке, это само по себе уже "шум" в переписке создает).

 

Верно. У вас были общие цели. А когда цели могут и различаются? Я именно про эту ситуацию. 


  • 0

#9 pachkun

pachkun

    Новый участник

  • Members
  • Pip
  • 29 сообщений


Отправлено 18 Июнь 2015 - 08:20

Таким методом можно тока врагов наживать.

 


Верно. У вас были общие цели. А когда цели могут и различаются? Я именно про эту ситуацию. 

 

 

В это случаи мне кажется, это должно решаться не на уровне тестировщика, а на уровне того кто нанял этого тестировщика.


  • 0

#10 aid

aid

    Опытный участник

  • Members
  • PipPipPipPip
  • 445 сообщений
  • ФИО:Николай


Отправлено 18 Июнь 2015 - 08:31

В это случаи мне кажется, это должно решаться не на уровне тестировщика, а на уровне того кто нанял этого тестировщика.

 

Простите великодушно, а что решит уровень, который нанял тестировщика? И о каком в данном случае уровне речь? Директор? QA Lead? 


  • 0

#11 Сергей

Сергей

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 017 сообщений
  • Город:Москва

Отправлено 18 Июнь 2015 - 08:36

Блин, нашли что обсуждать, тестировщик и разработчик не взлюбили друг друга. Это нормальное явление, скорее всего оба муда-и. Дрессировщик, блин, нашелся. Увольнять надо обоих, не зависимо от квалификации. Один геморрой от таких работников.


  • 0

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс


#12 pachkun

pachkun

    Новый участник

  • Members
  • Pip
  • 29 сообщений


Отправлено 18 Июнь 2015 - 08:43

 

В это случаи мне кажется, это должно решаться не на уровне тестировщика, а на уровне того кто нанял этого тестировщика.

 

Простите великодушно, а что решит уровень, который нанял тестировщика? И о каком в данном случае уровне речь? Директор? QA Lead? 

 

Решить в какой форме взаимодействовать с разработчиками; нужно ли их дрессировать и если нужно, то как это делать.

Решает, тот, у кого волшебная кнопка "оставить без денег".


  • 0

#13 aid

aid

    Опытный участник

  • Members
  • PipPipPipPip
  • 445 сообщений
  • ФИО:Николай


Отправлено 18 Июнь 2015 - 08:48

 

 

В это случаи мне кажется, это должно решаться не на уровне тестировщика, а на уровне того кто нанял этого тестировщика.

 

Простите великодушно, а что решит уровень, который нанял тестировщика? И о каком в данном случае уровне речь? Директор? QA Lead? 

 

Решить в какой форме взаимодействовать с разработчиками; нужно ли их дрессировать и если нужно, то как это делать.

Решает, тот, у кого волшебная кнопка "оставить без денег".

 

 

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


  • 1

#14 SHINNOK

SHINNOK

    Постоянный участник

  • Members
  • PipPipPip
  • 208 сообщений
  • ФИО:Кравченко Артём
  • Город:Таганрог


Отправлено 18 Июнь 2015 - 09:25

Наткнулась тут на пост западного тестировщика, который пишет, что дрессирует своих разработчиков, заводя сообщения об опечатках, но не указывая, где опечатка найдена. Мол, вот помучаются они, поищут - будут в следующий раз внимательнее текст набирать, а не абы как, все равно тестировщик найдет.

 

Надо было ответить - "Пока не скажешь где, не получишь зарплату" :)
А вообще, что за детский сад? Если тестировщик выпендривается и плохо делает свою работу, то встаёт вопрос, а нужен ли он вообще в команде?


  • 0
Второй активно используемый ник - Victim

#15 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 821 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 18 Июнь 2015 - 09:46

 

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

 

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


  • 0

Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium


#16 aid

aid

    Опытный участник

  • Members
  • PipPipPipPip
  • 445 сообщений
  • ФИО:Николай


Отправлено 18 Июнь 2015 - 10:00

 

 

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

 

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

 

 

Пример из практики. Вы работаете в платёжной системе, тестируете сервис партнёра. А партнёр, в свою очередь подвизался с мошенническими схемами. 30 процентов трафика легального, 70 нелегального. Начинаете искать, находите сайты, сервисы, откуда этот трафик идёт. Далее, трафик останавливаете, оформляете экзотичный баг-репорт, где описывается, что и как не так. Но из него нужно убрать все подробности, которые могут дать понять, какие именно сервисы вы нашли. Потому что найти всё, задача сложная. А полностью описав, что и где, вы просто сподвигните прикрыть то, что вы нашли, а не всю схему.

 

Аналогично с какими то сервисами, на которых у вас есть аккаунты. Когда я тестировал, всегда был наш 1 аккаунт, о котором знали партнёры и ещё пара-тройка моих личных. И когда описываешь, что и как, всегда был соблазн у партнёров по быстрому что то пофиксить для 1 нашего (если такое было технически возможно), а проблему решить "потом когда нибудь".


  • 0

#17 Lusya

Lusya

    Новый участник

  • Members
  • Pip
  • 19 сообщений
  • ФИО:Lusya


Отправлено 18 Июнь 2015 - 12:31

Бывают ли вообще ситуации, в которых оправдано применение подобной тактики (не для опечаток, а в принципе - намеренно упустить что-то в баг-репорте, чтобы разработчик глубже копнул)?

 

Считаю такую ситуацию недопустимой. У команды есть цель - сделать проект, который будет удовлетворять потребностям заказчика. При этом проект должен быть сделан в срок и с надлежащим качеством. А дрессировать разработчиков подобным образом - это пустая трата времени, сил и нервов (не только ваших, но и команды в целом). Лучше от этого никому не станет + это подорвет отношение в команде между тестировщиков и разработчиками. Всегда можно попросить разработчиков (в личной беседе за чашечкой кофе или на митинге) быть чуточку внимательнее и т.д. Это намного эффективнее, что указанная выше "дрессировка".


  • 0

#18 bu4er

bu4er

    Постоянный участник

  • Members
  • PipPipPip
  • 150 сообщений
  • ФИО:Шмыга Артём


Отправлено 18 Июнь 2015 - 13:00

Чтобы дрессировать нужно понимать как появляются ошибки. С теми же опечатками - я сам иногда печатаю так что одна буква раньше нужной встает. Тут нужно перепроверять. А если на проекте тонна текста?

Метод бредовый конечно - "там ошибка, сам найди" 
Если желание тестировщика в том, чтобы программист совершал меньше опечаток и меньше их пропускал - метод "там ошибка, сам найди" не как достижению этого желания не поможет. 

Это как:

"Я хочу доехать до Парижа и поэтому я буду рисовать дорогу".

Но погоди, как одно с другим соотноситься? Как это поможет тебе доехать до Парижа?

Если воспитывать разработчиков(тестировщиков, менеджеров, маму, детей...) то нужно для начала узнать чего он хочет. И уже отталкиваясь от полученной информации думать и искать точки соприкосновения.

Если программист не хочет "перепроверять свой текст на опечатки" ты как ему это не запихивай - он спишет все на "а тестировщики зачем?"
Кто то хочет больше зп, кто то повышение, кто то продукт без ошибок. 
И я сейчас не про то, чтобы повышать зп разрабу только для того чтобы он опечаток не совершал, нет.
Если есть какой то канал связи с разрабом у тестировщика - можно сказать: "Чувак, я знаю ты хочешь больше зп. Чтоб у менеджера попросить нужно ему это как то обосновать. Если ты будешь перепроверять за собой текст на опечатки ты можешь менеджеру сказать что делаешь меньше ошибок, а я это подтвержу."
Это грубый пример конечно...  


  • 0

#19 bcxtim

bcxtim

    Новый участник

  • Members
  • Pip
  • 41 сообщений
  • ФИО:Тим Руссо


Отправлено 18 Июнь 2015 - 13:07

Меня бы уволили после такого баг-репорта. Тобишь разработчик получается, должен становиться тестировщиком и еще искать, где ошибка. Особенно если проект разрабатывается, уже на этапе релиза  - это вообще жесть.

Я понимаю, когда тестировщик уловил баг допустим, когда он воспроизводится, но найти причину почему, уже может только разработчик. У него есть код на руках, нужные доступы  и т.д.


  • 0

#20 Molechka

Molechka

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 203 сообщений
  • ФИО:Ольга Назина (Киселева)
  • Город:Москва


Отправлено 18 Июнь 2015 - 15:33

Только что Заказчик прислал сообщение:

 

там в инструкции опечатка, я хотел исправить, но не хватило прав :D
в последних строчках
 

 

 

)))))) Сразу вспомнила о темке

  • 0
Автор сайта для начинающих тестировщиков http://testbase.ru/
Автор портала проверки названий багов http://bugred.ru/
Веду блог http://okiseleva.blogspot.com/


Инструменты тестировщика: Командная строка
онлайн
Практикум по тест-дизайну 2.0
онлайн
Программирование на Phyton для тестировщиков
онлайн
Тестирование производительности (JMeter)
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале