Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Заказчики все больше интегрируются в процесс разработки, забирая определенную часть работы тестировщиков на себя.
Но в других сферах жизни так не делают. За качество отвечает тот, кто производит товар или услугу, то есть исполнитель. В нашем случае это и есть сам разработчик
Что дешевле, время заказчика или время тестировщика?
Ну а программисты чаще всего нужны при задачах не копирования готового продукта, а созданиии нового. А этот процесс «с первого раза и без ошибок» невозможен в принципе.
Заказчик или его уполномоченный… могут взять на себя приемку готовой работы в конце итерации или другого срока ее выполнения. Это звучит вполне логично — тот, кто заказывал работу, должен ее и принять. Причем, лучше это ни у кого не получится сделать. Тестировщик не может брать на себя такую ответственность.
Разработчики могут взять на себя обеспечение технологического процесса разработки, в котором минимальна вероятность ошибки. В этом им отлично помогут инженерные практики: Code Review, парное программирование, Continuous Integration, TDD и прочие. Ну и конечно же автоматизированное тестирование на всех уровнях (модульное, интеграционное, функциональное), что у разработчиков получается гораздо лучше.
Разработчики могут взять на себя обеспечение устойчивости к регрессии, автоматизировав процессы прогона приемочных тестов и сделав их регулярно повторяющимися на каждое изменение в коде продукта.
Разработчик же не может найти ошибки сам, есть масса причин, по которым он даже подсознательно использует свое приложение так, как оно работает, а не так, как оно не работает.
Ошибки всегда были и будут. Никакой CodeReview, парное программирование, CI, TDD и прочее не спасут, например, от неверного понимания задачи.
Невозможно всё автоматизировать. Автоматизируйте проверку, что поля не поехали, что картинки не исказились, что TabOrder у элементов на форме правильный и т.д.
Речь идет о TDD на уровне продукта. До того как все обсудили и поняли задачу, сформулировав свои знания в виде приемочных тестов, примеров поведения и просто примеров использования, браться за разработку бессмысленно.
Поэтому, загляните, пожалуйста, хотя бы в википедию, чтобы мы с вами говорили все-таки на одном языке.
Если вы полностью автоматизировали процесс КОНТРОЛЯ (хотя я не сильно в это верю), то это не значит, что ваши разработчики им занимаются.
Когда-то давно ОТК отделили от прочих инженерных подразделений по одной очень простой причине — когда сверху давят (типичнейшая заказная разработка), то инженеры склонны «не замечать» и недооценивать дефекты. Поэтому перенос на них ответственности по контролю (еще раз — именно контролю) — очень плохая идея.
Контроль качества — это оценка качества выпускаемого продукта. Не проверка работы, а оценка качества. Измерение.
… и автоматизировать проверку. Маню уволить.
Если это то, что ему нравится, то закрепить ее в качестве стандарта (приемочного теста) и автоматизировать проверку. Маню уволить. После этого выпускать точно такие же, показывая каждую сотую, чтобы вдруг не оказалось, что рынок поменялся.
Контроль за качеством на всех этапах. В традиционных производственных системах качество выполненной работы проверяют только по ее завершении. Технология стройного производства Toyota предусматривает контроль за качеством на каждом этапе процесса. В отдельных случаях рабочие имеют право остановить конвейер2, при этом они руководствуются жесткими инструкциями, основная цель которых — обеспечить единый стандарт выполнения работ и обслуживания техники, чтобы минимизировать поломки и прочие сбои в работе оборудования. В идеале любой дефект должен быть устранен до того, как продукция перейдет на следующий этап обработки. Это уменьшает количество дорогостоящих доделок и повышает ответственность работников. Система стройного производства рассматривает остановку оборудования как потерю, поэтому на производственных предприятиях действует так называемая система общего превентивного обслуживания. Ее цель — за счет постоянного контроля со стороны работников не допустить поломок оборудования и простоя.
Конечной задачей Б является недопущение некачественной работы со стороны А.
За качество отвечает тот, кто производит товар или услугу, то есть исполнитель. В нашем случае это и есть сам разработчик.
Но в других сферах жизни так не делают. За качество отвечает тот, кто производит товар или услугу, то есть исполнитель. В нашем случае это и есть сам разработчик.
Из своей практики, предположим разрабатываете вы систему управления для загрузчика ядерного топлива в АЭС.
Так же вы описали коня в вакууме, НЕ БЫВАЕТ команды на 100% из супер профессионалов, невозможно им сразу родится, и конкуренция на рынке всегда есть, сегодня у вас их 10 а завтра уже 8, и вы берете 2 мидлов, которые могут допустить ошибки.
И действительно тут правильно указали, время разработчика дороже, нежели тестера. И это так же нужно учитывать.
Автоматизация никогда не покроет 100% возможных кейсов.
Так же добавлю, любой профи человек, с девушкой поссорился, вчера перепил на свадьбе, гриппует, сидит с температурой +40. И тут хоть какой вы супер менеджер, но человек может допустить ошибку, и уйти на больничный. И что вы предлагаете? Взять второго ( у которого загрузка 100%) и попросить его проверить, что вчера Вася налабал с жутким похмельем? И на завтра у вас -1 профессионал.
Но в других сферах жизни так не делают. За качество отвечает тот, кто производит товар или услугу, то есть исполнитель. В нашем случае это и есть сам разработчик. Поэтому отвечать за обеспечение качества своей работы он должен самостоятельно.
сам разработчик особо не переживает и может делать некачественное решение
За качество отвечает тот, кто производит товар или услугу, то есть исполнитель. В нашем случае это и есть сам разработчик
Но разработчики как писали хреновый код так и будут продолжать
Отдельно повеселило предложение заказчику проводить приемное тестирование по окончании итерации. Представляю себе
Если вы уже решили перейти на личности и светануть в качестве аргумента моим профилем в LinkedIn, то хочу вас уведомить о специфике своей работы в компании. Я занимаюсь запуском заказных продуктов с нуля. В большинстве своем это сложные распределенные системы: социальные сети, программы лояльности, интеллектуальные краулеры интернета. Два проекта в 2011 году вошли в топ 100 мировых успешных стартапов. Так что это не тот классический аутсорсинг, о котором вы по выходным читаете в уютном кресле за чашкой чая. И описанные в статье подходы отлично работали и работают по сей день.
Вы видимо мало что слышали о современных подходах к разработке и тестированию: Scrum, XP, Kanban. Я уже не говорю про Lean философию и Agile принципы в целом.
Отдельное спасибо за «деформацию мышления» и сомнения в моих обучающих способностях, в которых вы не имели возможности убедиться лично.
человек, который делает продукт, человек, который оценивает качество и человек, который контролирует качество не могут быть одним и тем же человеком.
Другое дело, насколько его метрики и методики оценки совпадают с таковыми у заказчика и пользователей
А теперь пишут домохозяйки, лифтеры, полицейские, так что кто во что горазд… :)
программист виноват в том, что не задал вопрос, а реализовал как ему показалось правильным. Если бы все на своих рабочих местах делали так как им лично кажется, то был бы полный беспредел вездепо-вашему, получается, что программист виноват в том, что он программирует. нет, в самом деле, если бы все на своих рабочих местах задавали вопросы, то ни кто бы не программировал, а все бы задавали вопросы.
Команда в Scrum кроссфункциональна. В нее входят люди с дополняющими навыками разработчики, аналитики, тестировщики. Нет заранее определенных и поделенных ролей в команде, ограничивающих область действий членов команды. Команда состоит из инженеров, которые вносят свой вклад в общий успех проекта в соответствии со своими способностями и проектной необходимостью.
А за архитектуру и дизайн отвечает вся команда, все решения принимаются сообща.
хоть программист и делает кучу дефектов и тут и там, его работа по-прежнему может считаться качественной.
За качество и выпуск самого продукта отвечает команда!в смысле — юридически (кто является исполнителем, с которым заказчик заключает договор, и что, в общих чертах, представляет собой предмет такого договора)?
Жизнь без тестировщиков: миф или реальность?