Должен ли разработчик заниматься ручным тестированием?

Question

[Halfmast]

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

Comments

[Максим Федоров]

Должен ли разработчик заниматься ручным тестированием?

Даже с тестировщиком на борту -- ты же не отдашь тестеру не проверенную наверняка таску! Это ж какой футбол выйдет...

[Strannyk]

В пределах разумного.


Знавал компанию без тестеров, в которой было два популярных вопроса на ретроспективах:
1. Почему у нас столько багов на проде?
2. Зачем нам тестировщики?

Answer 1

[rustler2000]

>Иногда за такие косяки могут влепить штраф.

Беги оттуда!!!

Баги будут всегда - если начальство ожидает от тебя 0 багов, или снижает ЗП (при этом сами скорее всего не имеют даже definiton of done, жлобят на тест инженера), то ничего хорошего там не будет.

Comments

[Виталий Хоменко]

Вы не спросили, а за какой именно косяк могут влепить штраф? Одно дело какая-то мелочь, а другое - по глупости или халатности завалить продакшн и нанести значительный ущерб. А если подобные косяки случаются часто? За подобное не только могут оштрафовать, за такое увольняют. Потому сперва нужно разобраться.

[rustler2000]

Виталий Хоменко, если косяки случаются часто, то в нормальных командах процессы подправляют - и первый вопрос "что нам сделать, чтобы не повторилось". А не как у топик-стартера - "ты ж написал, ты ж тестил - тебе штраф".

Ну и периодически performance review проводят. Может там с мотивацией проблемы или еще чего, типа тест инженера не хватает. В конце концов pr ведь в обе стороны проходит, если организация здоровая.
А штрафы - это очень по совковому - поиск крайнего.

[HellWalk]

Виталий Хоменко,

А если подобные косяки случаются часто?

Как уже правильно сказали выше - обычно настраивают нормальные рабочие процессы. А вот если кто-то не хочет встраиваться в нормальные процессы (например "не хочу писать авто-тесты!") - от него обычно избавляются, а не штрафуют.

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

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

Если в компании есть система штрафов - в 99% случаев там нет смысла работать. 1% можно пренебречь.

[Виталий Хоменко]

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

[rustler2000]

Виталий Хоменко, даже с парой разрабов не важно какой косяк - штрафа быть не должно. даже с одним.

[Виталий Хоменко]

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

Answer 2

[Tyranron]

Поставьте себя на место заказчика и смените область, к примеру, на создание автомобиля. Вы заказываете у мастера автомобиль ручной сборки. Он его собирает, проверяет заводится он или нет, и отдаём Вам в пользование. Вы садитесь в автомобиль, выезжаете на любимый автобан и даёте жару в 100 км/час. На 101 км/час у Вас отваливаются передние колёса. Приятная ситуация? А ведь мастер "просто собрал машину".

Если смотреть на бизнес по-взрослому, то всё просто:

• Есть Заказчик. У него стоит задача создать Продукт, с помощью которого он бы зарабатывал деньги (ну или другая цель, не суть).
  
• Есть Исполнитель (разработчик или команда разработчиков). Исполнитель обязуется за обусловленный Гонорар создать и поддерживать Продукт, который бы отвечал критериям качества Заказчика.
  
• Если Исполнитель делает Продукт не соответствующий критериям качества Заказчика, значит он не выполняет условия Договора.
  
• Если Заказчик не выплачивает Гонорар в должном объеме и вовремя, или требует чего-то не обусловленного в рамках Договора, значит он не выполняет условия Договора, а то и нарушает.
  
• И Исполнитель и Заказчик должны понимать, что они создают Продукт, и должным образом очертить в рамках Договора критерии к созданию/поддержке этого Продукта. Дабы однозначность этого вопроса была явная и юридическая.
  

Всё остальное - лирика.

Если Ваша команда (как Исполнитель) не обладает штатом тестировщиков, то соответствующие обязанности по обеспечению качества Продукта Вы должны осознанно брать на себя. Нет никаких "разработчик просто пишет код". Есть "разработчик создаёт Продукт". Команда разработки обязуется согласно Договору создать Продукт ожидаемого качества и всё. Как это качество обеспечивается - вопрос уже второстепенный и зависит от состава команды, существующих технических средств, да и самого Продукта как такового (много каверзных кейсов не поддаются вменяемой автоматизации). Соответственно, бюджет на обеспечение качество Продукта должен закладывать в любом случае, независимо от того есть ли тестировщик или нет.

Comments

[rustler2000]

> А ведь мастер "просто собрал машину".

Но в суд вы подадите на юр лицо. А у юр лица есть страховка.

Это какойто адовийше совковый менталитет перекладывать риски на исполнителя на окладе, но забирать себе всю прибыль.

В любой нормально стране риски несет собственник бизнеса, иначе бы никто никогда "на западе" в доктора бы не пошел. И собственник же получает прибыль. И чтобы ее получить он заботится о компании. А не "доит" и если что "опускает" наемного сотрудника (на часть ЗП).

[Tyranron]

rustler2000,

Но в суд вы подадите на юр лицо.

В суд подадим на Исполнителя с которым заключен Договор. Юр лицо он или нет - зависит. Соль не в этом. Есть много разработчиков, которые предоставляют услуги как физ. лицо. В том числе, между прочим, и я. Это бывает удобнее.

А у юр лица есть страховка.

Тоже ведь не суть. Ну есть - хорошо. Ну нету - какая разница для Заказчика?

Это какойто адовийше совковый менталитет перекладывать риски на исполнителя на окладе, но забирать себе всю прибыль.

Не спорю. Договор нужно составлять разумно так, чтобы он устраивал все стороны. Если Вас не устраивают условия, которые выдвигает Заказчик - не соглашайтесь на такой Договор.

В любой нормально стране риски несет собственник бизнеса

Он как бы в любом случае их несёт.

И чтобы ее получить он заботится о компании.

Если Заказчик не заботится о своём бизнесе, то он просто загниёт и сдохнет. Это очевидно.

А не "доит" и если что "опускает" наемного сотрудника (на часть ЗП).

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

P.S. Я всё это написал не для того, чтобы оправдывать плохой тон бизнеса и заказчиков-козлов. Такие есть, без спору. Я это написал для того, чтобы была ясность во взаимоотношения Заказчик - Исполнитель. По взрослому всё именно так, как Вы и описали. Заказчик несёт риски и получает основную прибыль, а Исполнитель качественно выполняет работу и получает свой Гонорар. Чтобы не было перекосов - нужно внятное взаимоотношение.

[nApoBo3]

Систематическое оказание услуг как "физ.лицо не законно, вы в какой то форме должны легализоваться. Есть существенное отличие между заказом продукта и разработкой продукта. Во многом оно определяется кто является собственником продукта и прибыли, а так же, соответственно несёт риски. Если мы говорим об отношении к собственноей разработке как к внешней, то есть акты приемки, есть ТЗ, есть ограниченные гарантии( обычно as is ). Но обычно в локальной разработке и строгого ТЗ нет, и приемки.

[Tyranron]

nApoBo3,

Систематическое оказание услуг как "физ.лицо не законно, вы в какой то форме должны легализоваться.

Зависит от законодательства. В ряде стран Вы вполне можете легализироваться как физ. лицо и вести законную деятельность с уплатой соответствующих налогов.

то есть акты приемки, есть ТЗ, есть ограниченные гарантии

Это всё всего лишь юридические инструменты. Они при правильном подходе помогают и дают гарантии, а при неправильном только мешают и являются причиной конфликтов и споров.

Суть же именно во внятном и взрослом отношении и подходе к совместному делу. Локальная разработка, заказная разработка - не имеет значения. Требования качества есть что там, что сям.

Выполняешь работу качественно и получаешь за этого справедливую оплату - это хорошо и правильно.

Выпускаешь в прод продукт не озаботившись обеспечением качества - это плохо. Собственник не соблюдает финансовые обязательства (в том числе и лепит штрафы не предусмотренные сотрудничеством) - это плохо.

[nApoBo3]

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

Answer 3

[Иван Шумов]

Зависит от размера организации. В небольших компаниях это практически норма

Comments

[Ivan Yakushenko]

галера не компания

[rustler2000]

pygame, ну тут галера на двух веслах и оба по левому борту ))

[Ivan Yakushenko]

pygame, в галерах говорят, что есть тестеры, что бы взять с клиента побольше долларо-часов, а на самом деле их нет, что бы не платить тестерам.

Answer 4

[Dimonchik]

Тестировщика в компании нет.

это маркер, не стоит там работать

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

но если нет тестировщика - лучше там не работать, необходимость доказана от ПМов до психологов

Answer 5

[res2001]

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

PS: работал в свое время в организации, которая в своем продакшене по факту тестировала официально купленное не дешевое ПО с поддержкой. Хорошо хоть разрабы работали практически в он-лайне и была с ними прямая связь. Багов хватало, в т.ч. достаточно серьезных.

Answer 6

[Евгений Залецкий]

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

Answer 7

[Владимир Куц]

Должен ли разработчик заниматься ручным тестированием

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

Answer 8

[evgeniy_lm]

Должен ли разработчик заниматься ручным тестированием?

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

ЗЫ. Не факт, что подобная фигня будет прописана в договоре буквально в виде пункта. Там может быть записано что разработчик обязан предоставить работающее ПО, при этом отдельный тестеровщик не предусматривается.
ЗЫ ЗЫ. Предусмотреть всего невозможно по этому все тесты оговариваются заранее и включаются в ТЗ. Если возникла нештатная ситуация то это уже проблема заказчика (работодателя)

Answer 9

[Mikhail Osher]

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

Вот такие "С его точки зрения, как ему кажется, он выполнил тестирование и его код должен работать" - это снятие ответственности с себя. Каждый разработчик обязан руками проверить свои изменения, и, так же, проверить все смежные модули, которые затрагивались в рамках задачи. И неважно, есть integration/e2e тесты, или нет.

Comments

[Mimuss]

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

Answer 10

[Vitaly Karasik]

пишет к коду тесты.

Если начальство понимает, что это необходимо и дает на это время - все прекрасно!
Учитесь писать тесты, прогонять их автоматически.

Answer 11

[nApoBo3]

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