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

[Sadnes]

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

Главный вопрос: стоит ли наказывать тестера за не найденные ошибки в проекте?

[Loboda]

Главный вопрос: стоит ли наказывать тестера за не найденные ошибки в проекте?

Вопрос риторический

Очень много факторов которые нужно учитывать при принятии решения (сроки, качество продукта, качество документации, опыт тестировщика, как часто допускает подобные промашки, душевное и физическое состояние на момент тестировании :) ...)

И о каком именно наказании идёт речь?

[notProgrammer]

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

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

Главный вопрос: стоит ли наказывать тестера за не найденные ошибки в проекте?

Зависит от многих факторов. От степени самой ошибки (minor ... crash). От того, как она влияет на эксплуатацию системы (блокирует ли дальнейшие действия пользователя). От времени, которое было выделено на тестирование. От осведомлённости тестера о фиче (дали ему документацию тогда, когда программисту, или за час до отдачи релиза заказчику).
В общем, много чего влияет. Возможно есть какая-то универсальная формула - если кто-то тут напишет - сама с удовольствием почитаю.

[Лелик32]

Программист обязательно должен проверять, что же он после себя написал.

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

[notProgrammer]

Программист обязательно должен проверять, что же он после себя написал.

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

Пусть тестеры и проверяют - ведь им же за это деньги платят (с)

[lives_mobile]

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

[Freiman]

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

Релиз назначен на понедельник, а в пятницу вечером выдается новый билд «с небольшими обновлениями».
Есессно, в нем есть новосозданные баги, тестировщики их не успели найти. Они виноваты?

[nuc]

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

Релиз назначен на понедельник, а в пятницу вечером выдается новый билд «с небольшими обновлениями».
Есессно, в нем есть новосозданные баги, тестировщики их не успели найти. Они виноваты?

Виноват тот, кто допустил такую ситуацию (разрешил залить недотестированный релиз в продуктив).
Но и тестировщик в такой ситуации ясно должен дать понять руководству, что выпуск такого релиза в продуктив крайне нежелателен.

[Sezam]

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

Можно узнать - какая выборка?
Спасибо.

[Sadnes]

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

В любой ситуации ответ конечно может быть разным, но суть все равно в том, что вопрос будет поставлен именно в ключе "Кто это тестировал?".

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

Некоторые компании вроде как используют систему штрафов для программистов. За каждую ошибку разработчика его штрафуют. Правильно ли это? И правильно ли будет если мы станем штрафовать тестера за пропущенную ошибку?

В принципе, именно после того как я узнал о системе штрафов, я задался вопросом, за что отвечает тестер и когда он прав, а когда нет.

[notProgrammer]

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

[Cler]

В нормальной ситуации вопрос ставиться не о том, что надо ли наказывать тестера, а о том,
1. почему баг не был найден (мало времени, неполное покрытие тестами и т.п.)
2. что сделать, чтобы такой ситуации в будущем не было.

Иногда описанный выше конструктивный подход заменяется неконструктивными поисками и наказаниями виновных.

После добросовестной проработки вышеописанных (как минимум) 2х пунктов виновник(и) сами осознают, где они недоработали.

[notProgrammer]

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

Баги остаются всегда. Это аксиома. Главное, чтобы не оставались очевидные баги.

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

Нет.

Вообще, мне кажется, народ долго не будет задерживаться там, где принято штрафовать за каждую ошибку. Не важно кто они: тестировщики, программисты или уборщица.

[Future]

Ох ты ж, опять 25. Вы работаете в команде, отвечает за всё команда! Почему тестер не нашел баг? А почему программист его туда посадил? А если это не баг, то почему аналитик так описал требования? Вы команда и виноват не конкретный человек, а все. Хотите вызывать кого-то на ковер, дело ваше, я с такого места ушел. Не бывает Zero bugs... НЕ БЫВАЕТ... Приносит удовольствие кого-то дрючить, ваше дело можете дальше продолжать работать совковыми методами вот и всё.

[Sadnes]

Ох ты ж, опять 25. Вы работаете в команде, отвечает за всё команда! Почему тестер не нашел баг? А почему программист его туда посадил? А если это не баг, то почему аналитик так описал требования? Вы команда и виноват не конкретный человек, а все. Хотите вызывать кого-то на ковер, дело ваше, я с такого места ушел. Не бывает Zero bugs... НЕ БЫВАЕТ... Приносит удовольствие кого-то дрючить, ваше дело можете дальше продолжать работать совковыми методами вот и всё.

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

[Vasiliy]

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

[Future]

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

[SALar]

кто виноват?

Вроде как, Деминг на эту тему достаточно однозначно ответил: "Минимум за 96% брака ответственность несет менеджер".

Чего спорить то?

[jjjzmey]

Главный вопрос: стоит ли наказывать тестера за не найденные ошибки в проекте?

Стоит наладить процесс и такого типа ошибок больше не пропускать.
Вследующий релиз выплывую другие ошибки, опять улучшать процесс и т.д. до прихода в Светлое Будущее!