Comments 165
> Но многие известные зарубежные проекты не имеют выделенных тестировщиков
Например?
Например?
Tumblr, Instagram, Google (там Software Engineer in Test — тот же разработчик), Twitter. По крайней мере докладчики с этих компаний так утверждают и я склонен им верить.
Вникните глубже в то, что они говорят. У них нет тестировщиков, которые тыкают в кнопки по инструкции. У них есть инженеры QA.
Да, есть определённые сферы, где можно тестировать на пользователях. Например, Facebook рассказывал, что сначала выкатывает обновление только для 1% пользователей. Тут как раз эти пользователи работают обезьянками-тестерами.
Не уверен, что этот способ подойдет для систем, которые управляют деньгами, складскими запасами или технологическими процессами.
Да, есть определённые сферы, где можно тестировать на пользователях. Например, Facebook рассказывал, что сначала выкатывает обновление только для 1% пользователей. Тут как раз эти пользователи работают обезьянками-тестерами.
Не уверен, что этот способ подойдет для систем, которые управляют деньгами, складскими запасами или технологическими процессами.
Первые две вообще состоят только из разработчиков и менеджеров продуктов. И да, A/B тестирование активно применяется, но не для того, чтобы совершенно бажный продукт отдать на тестирование. Цель — понять нужна ли фича и в каком виде. Это скорее бизнес цель.
Не путайте Software Engineer и Software Engineer in Test. Это разные люди, разные профессии, разные инструменты, разные цели. Это напрямую противоречит тому, что Вы пишете об отсутствии тестировщиков.
Software Engineer in Test — это как раз та интеллектуальная роль тестировщика, которую не всегда сможет выполнить кто-то другой. Но при этом квалификация таких людей на порядок выше чем у рядовых тестировщиков на просторах нашей необъятной…
Software Engineer in Test — это автоматизация тестирования.
Рекомендую ознакомиться вот с этой статьей, она должна несколько расширить ваше представление.
Software Engineer in Test — это разработчики инструментариев для автоматизации тестирования.
Вопрос: А как вы думатете почему «Tumblr, Instagram, Google, Twitter и и же с ними» живут без выделеных тестировщиков?
Подсказка..
Ответ: Да потому что они (Tumblr, Instagram, Google, Twitter,...) могут позволить себе то, что называется емким и точным термином «отлаживать сырой код на пользователях».
Вывод
Поэтому, если Вы, занимаетесь разработкой не очередного бесплатного веб-сервиса для «широких масс хомячков», а, например, чего-нибудь «посерьезней», вроде систем биллинга, т.е. если каждый ваш косяк выраженный в бабле может легко потянуть на шестизначную сумму, то, моя вам настоятельная рекомендация: даже не пытайтесь «косить под гугль» — вам может быть от этого мучительно плохо;)
Вообще говоря, ответ другой, достаточно погуглить
Например, вот такой
www.linkedin.com/search/fpsearch?title=qa+engineer&company=google¤tCompany=C&pplSearchOrigin=TSEO_SN&trk=TSEO_SN&csrfToken=guest_token&domainCountryName=
Например, вот такой
www.linkedin.com/search/fpsearch?title=qa+engineer&company=google¤tCompany=C&pplSearchOrigin=TSEO_SN&trk=TSEO_SN&csrfToken=guest_token&domainCountryName=
Вообще у них есть просто Test Engineer, но они тоже пишут код и вообще у них широкий круг обязанностей googletesting.blogspot.com/2013/01/test-engineers-google.html
Некоторые российские разработчики АБС (не буду показывать пальцем) тестируют на заказчиках…
Заказчики все больше интегрируются в процесс разработки, забирая определенную часть работы тестировщиков на себя.
Что дешевле, время заказчика или время тестировщика?
Но в других сферах жизни так не делают. За качество отвечает тот, кто производит товар или услугу, то есть исполнитель. В нашем случае это и есть сам разработчик
Не стоит смешивать в одну кучу производство разработанного продукта и R&D. При такой постановке можно утверждать, что производитель гарантирует, что при копировании отлаженного продукта ошибок не будет. Их и не будет. Но стоит посмотреть в любое КБ или R&D-департамент компании из «другой сферы жизни», и вот они — родные ошибки, тут как тут. И отделы тестирования там такие, что многие IT-компании удавились бы от зависти.
Ну а программисты чаще всего нужны при задачах не копирования готового продукта, а созданиии нового. А этот процесс «с первого раза и без ошибок» невозможен в принципе.
Что дешевле, время заказчика или время тестировщика?
Вопрос не в том, что это должен быть именно сам заказчик (тот человек или компания, которые заказали разработку продукта). Часто нанимают специального менеджера продукта и его время не так уж и дорого по сравнению с временем тестировщика. Зато он может сделать настоящую приемку.
Ну а программисты чаще всего нужны при задачах не копирования готового продукта, а созданиии нового. А этот процесс «с первого раза и без ошибок» невозможен в принципе.
Речь идет о том, что когда разработчик говорит «ГОТОВО», оно должно быть действительно готово. Речь не идет об ошибках продуктового типа, когда просто не туда пошли или не ожидали такого масштабирования. Все гораздо банальнее…
Заказчик или его уполномоченный… могут взять на себя приемку готовой работы в конце итерации или другого срока ее выполнения. Это звучит вполне логично — тот, кто заказывал работу, должен ее и принять. Причем, лучше это ни у кого не получится сделать. Тестировщик не может брать на себя такую ответственность.
Уважайте тех, кто вам платит. Проверяйте сначала сами. Иначе после пары итераций заказчик поймет, что сдача проекта — это не сдача, а его тестирование, и сильно огорчится.
Разработчик же не может найти ошибки сам, есть масса причин, по которым он даже подсознательно использует свое приложение так, как оно работает, а не так, как оно не работает.
Разработчики могут взять на себя обеспечение технологического процесса разработки, в котором минимальна вероятность ошибки. В этом им отлично помогут инженерные практики: Code Review, парное программирование, Continuous Integration, TDD и прочие. Ну и конечно же автоматизированное тестирование на всех уровнях (модульное, интеграционное, функциональное), что у разработчиков получается гораздо лучше.
Ошибки всегда были и будут. Никакой CodeReview, парное программирование, CI, TDD и прочее не спасут, например, от неверного понимания задачи.
Никакое автотестирование не покроет все варианты использования.
А про то, что у кого лучше получается — и говорить не стоит. Несколько веков назад произошло так называемое «разделение труда». С тех практика показывает, что разделение труда более эффективно. В разработке тоже. Хирург должен оперировать, а певец — петь.
Разработчики могут взять на себя обеспечение устойчивости к регрессии, автоматизировав процессы прогона приемочных тестов и сделав их регулярно повторяющимися на каждое изменение в коде продукта.
Невозможно всё автоматизировать. Автоматизируйте проверку, что поля не поехали, что картинки не исказились, что TabOrder у элементов на форме правильный и т.д.
Разработчик же не может найти ошибки сам, есть масса причин, по которым он даже подсознательно использует свое приложение так, как оно работает, а не так, как оно не работает.
Именно в этом и помогает TDD — сначала думаем как должно работать, а уже потом делаем. И не наоборот.
Ошибки всегда были и будут. Никакой CodeReview, парное программирование, CI, TDD и прочее не спасут, например, от неверного понимания задачи.
Неверное понимание требований — не ошибка. И над этой проблемой надо работать отдельно. Именно для этого придумали Agile планирование с приемочными тестами и критериями, вовлеченность заказчика, прототипы и прочие вещи.
Невозможно всё автоматизировать. Автоматизируйте проверку, что поля не поехали, что картинки не исказились, что TabOrder у элементов на форме правильный и т.д.
Это очень легко автоматизируется с помощью screnshot-based подходов и специализированных инструментов. Было бы желание. Вот видео моего доклада на эту тему.
Не помогает TDD. Если я, как разработчик неправильно понял задачу, то я сначала напишу неправильный тест, а потом — неправильный код.
Неправильное понимание требований — обычная ошибка. И работать надо над ней не отдельно, а в процессе разработки, как и с другими ошибками. С помощью тестирования.
Agile — не магическое заклинание. И вовлечение заказчика — тоже. Кто-то должен проверять правильность. И этот кто-то должен быть не тот, кто делает. Заказчика в процесс вовлекают не для тестирования.
Неправильное понимание требований — обычная ошибка. И работать надо над ней не отдельно, а в процессе разработки, как и с другими ошибками. С помощью тестирования.
Agile — не магическое заклинание. И вовлечение заказчика — тоже. Кто-то должен проверять правильность. И этот кто-то должен быть не тот, кто делает. Заказчика в процесс вовлекают не для тестирования.
Речь идет о TDD на уровне продукта. До того как все обсудили и поняли задачу, сформулировав свои знания в виде приемочных тестов, примеров поведения и просто примеров использования, браться за разработку бессмысленно. А TDD на уровне кода естественно решает те же задачи, но на низком уровне.
Речь идет о TDD на уровне продукта. До того как все обсудили и поняли задачу, сформулировав свои знания в виде приемочных тестов, примеров поведения и просто примеров использования, браться за разработку бессмысленно.
Сказка просто. Тут недавно был похожий топик, там сказочный программист рассказывал, что программы, вообще-то, надо писать без ошибок. Вот так.
По поводу Screenshot-based:
Кто-то сначала должен проверить вручную правильность первого скриншота.
Есть куча проверок, не автоматизируемых в принципе.
Вы, конечно, можете считать, что это возможно, но рассудит вас — заказчик. Будет ли он рад результату, или получит продукт, который проходит автотесты, но которым не может нормально пользоваться живой человек.
Кто-то сначала должен проверить вручную правильность первого скриншота.
Есть куча проверок, не автоматизируемых в принципе.
Вы, конечно, можете считать, что это возможно, но рассудит вас — заказчик. Будет ли он рад результату, или получит продукт, который проходит автотесты, но которым не может нормально пользоваться живой человек.
Текущий проект, над которым мы работаем, уже живет больше трех лет. Уверенно вышел в мир после нескольких месяцев разработки и зарабатывает деньги заказчикам. Релизы постоянные и частые (раз в 1-2 недели). В 2011 году вошел в топ 100 самых успешных стартапов года. У нас ни одного тестировщика и примеры из статьи во многом взяты из этого проекта. Все чисто на автоматизации и приемке заказчика, а также обратной связи от пользователей. Мы любим свою работу и делаем ее качественно.
И да, первый раз скриншоты надо будет просмотреть. Думаю разработчикам под силу с такой непростой задачей совладать…
И да, первый раз скриншоты надо будет просмотреть. Думаю разработчикам под силу с такой непростой задачей совладать…
Screenshot-based подходы круто, хотя и достаточно отстало на фоне крутых штук типа QF-Test, но очень плохо сочетается с TDD. Вот как раз для написания вских GUI тестов лучше использовать отдельного человека.
Re: «тестировщик нужен и полезен, но не в классическом его представлении, к которому многие из нас привыкли. Все простые и незамысловатые ответственности тестировщика могут быть распределены между членами команды.»
Т.е. вы предлагаете отказаться от узкой специализации, чтобы опять «все занимались всем». Зачем? Разве производительность труда от этого не упадет? Смотрите, чтоб у вас не вышло, как в анекдоте:
Т.е. вы предлагаете отказаться от узкой специализации, чтобы опять «все занимались всем». Зачем? Разве производительность труда от этого не упадет? Смотрите, чтоб у вас не вышло, как в анекдоте:
мне еще лампочку на лоб, чтобы я ночью косить мог
Сидят три лейтенанта на плацу.
— В отпуск хочется.
— Так иди к командиру, может отпустит.
Идет он к командиру и говорит:
— Товарищь командир, в отпуск типа хочу.
Командир:
— Рацпредложения есть?
Лейтенант:
— Есть. У нас все сейчас на покосе, а косят только в одну сторону, надо косу с двух сторон наточить и пусть косят в две стороны.
Командир:
— Молодец, иди в отпуск.
Приходит он к двум друзьям:
— Меня в отпуск отпустили, идите вы проситесь.
Пошел второй:
— Тов. командир, в отпуск охота.
Ком.:
— Рацпредложения есть?
Лейт.:
— Есть. У нас все на покосе ходят в две шеренги, одна косит, а второая с граблями собирает. Так надо впередиидущим к поясу привязать грабли, пусть и косят и собирают.
Ком.:
— Молодец, типа вали в отпуск.
Ну и приходит к командиру третий:
— Хочу в отпуск.
Ком.:
— Рацуха есть?
Лейт.:
— Нет.
Ком.:
— Ну и сиди здесь.
Выходит он на плац, а на встречу ему солдат, с заточенной с двух сторон косой, с граблями сзади, бьет себя ладонью в лоб и кричит лейтенанту:
— Мудила, мне еще лампочку на лоб, чтобы я ночью косить мог.
— В отпуск хочется.
— Так иди к командиру, может отпустит.
Идет он к командиру и говорит:
— Товарищь командир, в отпуск типа хочу.
Командир:
— Рацпредложения есть?
Лейтенант:
— Есть. У нас все сейчас на покосе, а косят только в одну сторону, надо косу с двух сторон наточить и пусть косят в две стороны.
Командир:
— Молодец, иди в отпуск.
Приходит он к двум друзьям:
— Меня в отпуск отпустили, идите вы проситесь.
Пошел второй:
— Тов. командир, в отпуск охота.
Ком.:
— Рацпредложения есть?
Лейт.:
— Есть. У нас все на покосе ходят в две шеренги, одна косит, а второая с граблями собирает. Так надо впередиидущим к поясу привязать грабли, пусть и косят и собирают.
Ком.:
— Молодец, типа вали в отпуск.
Ну и приходит к командиру третий:
— Хочу в отпуск.
Ком.:
— Рацуха есть?
Лейт.:
— Нет.
Ком.:
— Ну и сиди здесь.
Выходит он на плац, а на встречу ему солдат, с заточенной с двух сторон косой, с граблями сзади, бьет себя ладонью в лоб и кричит лейтенанту:
— Мудила, мне еще лампочку на лоб, чтобы я ночью косить мог.
А вы предлагаете как милиция ходить по трое, потому что один умеет говорить, второй писать, а третий носит наручники и дубинку? ;)
А вы согласились бы на операцию, где хирург, анастезиолог и медсестры по очереди бы резали, зашивали, кололи препараты и подавали инструмент?
Да и полы потом пусть помоют.
Да и полы потом пусть помоют.
Вы утрируете. Даже в вашем примере укол пациенту могут сделать все из них. Просто у каждого есть область, в которой он разбирается лучше других. В моей статье ручное тестирование выступает в роли укола — его могут сделать и тестировщики и разработчики и заказчик. Я не предлагаю заказчику разрабатывать код, а разработчику продавать продукт.
Вы первый начали утрировать про милиционеров.
Есть понятие специализации. Укол могут сделать все. В ж ягодицу. Дома.
А на операции медсестра должна вскрывать шприц и набирать препарат, а врач — колоть.
Есть понятие специализации. Укол могут сделать все. В ж ягодицу. Дома.
А на операции медсестра должна вскрывать шприц и набирать препарат, а врач — колоть.
Вы неправы. Колет именно медсестра. Врач делает это только в исключительных случаях. А строгая специализация — это большое зло в IT. Есть DBA. Если он заболел или уволился, то проекту труба, потому что только он работал с базой. То же самое для тестировщика, дизайнера и прочих. Если все делят обязанности, то за результат отвечают вместе и риски сильно уменьшаются.
IT не так сильно отличается от других инженерных областей как кажется. И там есть свои аналоги того же эджайла. И от отдельного ОТК они не откажутся никогда, потому что такая структура введена «кровью». Имхо, стоит расширять кругозор.
оффтоп, конечно, но медсестра колет в мышцу в процедурном кабинете.
На операции она может уколоть в катетер, в операционном поле работает всё-таки врач.
А про DBA — да, все верно. Чудес не бывает. У вас будет либо крутой DBA, который досконально знает особенности сервера, либо куча кодеров, которые считают, что они могут написать написать всё сами. Опросите их, что они знают о статистике исполнения запросов, когда она собирается, когда сбрасывается и как влияет на исполнение одного и того же запроса. И вы поймете разницу между DBA и программистом, который знает как написать Select, хранимую процедуру или построить индекс.
На операции она может уколоть в катетер, в операционном поле работает всё-таки врач.
А про DBA — да, все верно. Чудес не бывает. У вас будет либо крутой DBA, который досконально знает особенности сервера, либо куча кодеров, которые считают, что они могут написать написать всё сами. Опросите их, что они знают о статистике исполнения запросов, когда она собирается, когда сбрасывается и как влияет на исполнение одного и того же запроса. И вы поймете разницу между DBA и программистом, который знает как написать Select, хранимую процедуру или построить индекс.
Узкая специализация — не прихоть, а эволюция рынка разработки (и не только разработки, в продажах те же тенденции). Мы к этому пришли за 15-20 лет, когда были только «веб-мастера». Сейчас на одних «веб-мастерах» далеко не уедешь. Требуются специализированные знания и навыки, которые в одном человеке не эффективно объединять.
Архитектор получает гораздо больше гастарбайтера, но он тоже может забивать гвозди. Пусть забивает гвозди, он ведь может, да и зря ему что-ли столько платят. А то, что в это время он вместо забивания гвоздей может найти фундаментальную проблему в проекте, или делать для заказчика проект уже следующего дома почему-то опускается.
Архитектор получает гораздо больше гастарбайтера, но он тоже может забивать гвозди. Пусть забивает гвозди, он ведь может, да и зря ему что-ли столько платят. А то, что в это время он вместо забивания гвоздей может найти фундаментальную проблему в проекте, или делать для заказчика проект уже следующего дома почему-то опускается.
Я написал по поводу узкой специализации и ее проблем чуть выше. С таким подходом разработка должна быть далеко не интеллектуальным трудом. Один придумывает все, описывает детально на достаточном уровне, чтобы другие сели и банально закодили. Ничего не напоминает? Процессы конца прошлого — начала этого века. Современная разработка от этого уходит и семимильными шагами.
Тут вопрос совсем не в узкой квалификации.
Ваша ошибка в том, что вы считаете контроль качества частью разработки. А это не так.
Это абсолютно отдельный процесс.
Ваша ошибка в том, что вы считаете контроль качества частью разработки. А это не так.
Это абсолютно отдельный процесс.
Качество надо не контролировать, а внедрять. Нельзя исправить некачественный продукт без дополнительных затрат. На заводе сначала много тестируют, а потом запускают в разработку.
А на выходе с завода сидят тетеньки-метрологи и в зависимости от объема производства и требований к качеству проверяют вплоть до каждого изделия. И если некачественных изделий много, то технологам делают «атата».
У вас техническое образование?
У вас техническое образование?
Если вы так хотите перейти на личности, то у меня два технических образования. Одно отечественное, второе немецкое. Как это повлияло на наш диалог о качестве?
Ну в моем техническом вузике была и метрология, и теория надежности, и даже ТАУ, с четкими определениями качества, контроля, и контроля качества и пониманием чем внедрение методик повышения качества отличается от его контроля. Поэтому фраза «внедрение качества» для меня выглядит откровенно бредовой. А «вкладывание качества» из нижнего комментария еще более бредово. Это какой-то маркетинговый тренерский буллшит, а не разговор двух инженеров.
Поэтому, загляните, пожалуйста, хотя бы в википедию, чтобы мы с вами говорили все-таки на одном языке.
Если вы полностью автоматизировали процесс КОНТРОЛЯ (хотя я не сильно в это верю), то это не значит, что ваши разработчики им занимаются. Это значит, что они разрабатывают эти средства контроля (а кто, кстати, отвечает за качество этих средств?). И в некоторых компаниях даже есть специальные позиции типа QA Automation Engineer.
Когда-то давно ОТК отделили от прочих инженерных подразделений по одной очень простой причине — когда сверху давят (типичнейшая заказная разработка), то инженеры склонны «не замечать» и недооценивать дефекты. Поэтому перенос на них ответственности по контролю (еще раз — именно контролю) — очень плохая идея.
Поэтому, загляните, пожалуйста, хотя бы в википедию, чтобы мы с вами говорили все-таки на одном языке.
Если вы полностью автоматизировали процесс КОНТРОЛЯ (хотя я не сильно в это верю), то это не значит, что ваши разработчики им занимаются. Это значит, что они разрабатывают эти средства контроля (а кто, кстати, отвечает за качество этих средств?). И в некоторых компаниях даже есть специальные позиции типа QA Automation Engineer.
Когда-то давно ОТК отделили от прочих инженерных подразделений по одной очень простой причине — когда сверху давят (типичнейшая заказная разработка), то инженеры склонны «не замечать» и недооценивать дефекты. Поэтому перенос на них ответственности по контролю (еще раз — именно контролю) — очень плохая идея.
Вы как призрак из прошлого века. И вдобавок все время норовите подчеркнуть весомость своего мнения за счет грубостей: бред, бредовой, буллшит. Но ладно, вернемся к вопросу.
Смотрите, все очень просто. Я постараюсь объяснить как бабушке. Есть человек А, который делает основную работу. Есть человек Б, которого наняли с целью контроля качества работы А. Конечной задачей Б является недопущение некачественной работы со стороны А. У человека Б есть два варианта:
— Дождаться пока А сделает работу. Проверить, описать проблемы и отослать обратно к А. Потом принять исправления, проверить и повторить операцию. При этом на само качество работы А и причины его деградации Б не влияет. В итоге такой же цикл будет повторяться постоянно и на нем будут тратить время и А и Б.
— Сделать все возможное на самых ранних этапах, чтобы А сделал работу заведомо качественно. Для этого он может прояснять требования, помогать А готовить тестовые примеры, проверять ранние незавершенные результаты его работы, искать причины проблем в работе А и помогать устранять их. В этом случае процесс разработки постоянно улучшается и качество вместе с ним.
Оно и видно, что вы в нее пересмотрели.
Мы автоматизировали процесс контроля регрессии собственной работы. Это помогает нам разрабатывать быстрее, потому что нет необходимости кучу усилий тратить на поддержание работоспособности старого функционала. Мы спокойно делаем рефакторинг, развиваем архитектуру и дизайн, пишем новый код и т.д.
Что-то недооценить или не заметить помешают вам заказчик и конечные пользователи продукта. Ваша задача искать причины пропуска и их устранять на будущее. Вот и все.
Смотрите, все очень просто. Я постараюсь объяснить как бабушке. Есть человек А, который делает основную работу. Есть человек Б, которого наняли с целью контроля качества работы А. Конечной задачей Б является недопущение некачественной работы со стороны А. У человека Б есть два варианта:
— Дождаться пока А сделает работу. Проверить, описать проблемы и отослать обратно к А. Потом принять исправления, проверить и повторить операцию. При этом на само качество работы А и причины его деградации Б не влияет. В итоге такой же цикл будет повторяться постоянно и на нем будут тратить время и А и Б.
— Сделать все возможное на самых ранних этапах, чтобы А сделал работу заведомо качественно. Для этого он может прояснять требования, помогать А готовить тестовые примеры, проверять ранние незавершенные результаты его работы, искать причины проблем в работе А и помогать устранять их. В этом случае процесс разработки постоянно улучшается и качество вместе с ним.
Поэтому, загляните, пожалуйста, хотя бы в википедию, чтобы мы с вами говорили все-таки на одном языке.
Оно и видно, что вы в нее пересмотрели.
Если вы полностью автоматизировали процесс КОНТРОЛЯ (хотя я не сильно в это верю), то это не значит, что ваши разработчики им занимаются.
Мы автоматизировали процесс контроля регрессии собственной работы. Это помогает нам разрабатывать быстрее, потому что нет необходимости кучу усилий тратить на поддержание работоспособности старого функционала. Мы спокойно делаем рефакторинг, развиваем архитектуру и дизайн, пишем новый код и т.д.
Когда-то давно ОТК отделили от прочих инженерных подразделений по одной очень простой причине — когда сверху давят (типичнейшая заказная разработка), то инженеры склонны «не замечать» и недооценивать дефекты. Поэтому перенос на них ответственности по контролю (еще раз — именно контролю) — очень плохая идея.
Что-то недооценить или не заметить помешают вам заказчик и конечные пользователи продукта. Ваша задача искать причины пропуска и их устранять на будущее. Вот и все.
Ну смотрите. Объясняю, как студенту-второкурснику.
Контроль — это процесс измерения и получения информации о объекте управления. Если вы объект не контролируете, то вы не можете им управлять. В принципе.
Контроль качества — это оценка качества выпускаемого продукта. Не проверка работы, а оценка качества. Измерение.
Это прекрасно, что вы разбираетесь в средствах повышения качества. И они у вас есть. Только без контроля говорить о управлении качеством нельзя. Вообще.
Это, блин, базовые понятия что инженерии, что менеджмента.
Представьте себе, что завод «Цельнометаллические болванки» (ООО «СуперПуперИнформационныеСистемыЛимитед») получил заказ на изготовление тысячи болванок.
Соответственно, есть цех с главным технологом Петровичем (техлидом Васей) и отдел технического контроля, где сидит метролог тетя Маня с штангенциркулем (тестировщица Маша с селениумом).
Цех делает болванки, Маня их меряет.
Если бракованных болванок найдет много, то Петрович будет делать их заново, и если завод получит штраф за срыв поставки — Петровича как ответственного за качество продукции будут иметь анально, после чего он будет это качество повышать. Например выбьет из отдела закупок более точный станок для рабочего Иваныча (решарпер для разработчика Пети).
Если Маня отрапортует, что бракованных болванок нет, а они на самом деле будут, то завод уже точно получит штраф и к нему еще и серьезный подрыв репутации. Заказчик не будет работать с заводом с которого льется говнокод с багами. И в этом случае виновата будет Маня, потому что КОНТРОЛЬ не произведен.
Вы же предлагаете слать болванки заказчику ДАЖЕ НЕ ЗНАЯ БРАКОВАННЫЕ ОНИ ИЛИ НЕТ. Перевешивая затраты по контролю на заказчика.
На самом деле, конечно же, у вас есть метрики — как минимум количество упавших тестов. Вот только, что это и есть контроль и он тоже может производиться по разному и что стоимость этого контроля тоже часть стоимости продукта (за качество платят знаете ли) вы кажется не понимаете.
А отсюда отношение к вашей статье как к буллшиту и вопросы про ваше образование.
Контроль — это процесс измерения и получения информации о объекте управления. Если вы объект не контролируете, то вы не можете им управлять. В принципе.
Контроль качества — это оценка качества выпускаемого продукта. Не проверка работы, а оценка качества. Измерение.
Это прекрасно, что вы разбираетесь в средствах повышения качества. И они у вас есть. Только без контроля говорить о управлении качеством нельзя. Вообще.
Это, блин, базовые понятия что инженерии, что менеджмента.
Представьте себе, что завод «Цельнометаллические болванки» (ООО «СуперПуперИнформационныеСистемыЛимитед») получил заказ на изготовление тысячи болванок.
Соответственно, есть цех с главным технологом Петровичем (техлидом Васей) и отдел технического контроля, где сидит метролог тетя Маня с штангенциркулем (тестировщица Маша с селениумом).
Цех делает болванки, Маня их меряет.
Если бракованных болванок найдет много, то Петрович будет делать их заново, и если завод получит штраф за срыв поставки — Петровича как ответственного за качество продукции будут иметь анально, после чего он будет это качество повышать. Например выбьет из отдела закупок более точный станок для рабочего Иваныча (решарпер для разработчика Пети).
Если Маня отрапортует, что бракованных болванок нет, а они на самом деле будут, то завод уже точно получит штраф и к нему еще и серьезный подрыв репутации. Заказчик не будет работать с заводом с которого льется говнокод с багами. И в этом случае виновата будет Маня, потому что КОНТРОЛЬ не произведен.
Вы же предлагаете слать болванки заказчику ДАЖЕ НЕ ЗНАЯ БРАКОВАННЫЕ ОНИ ИЛИ НЕТ. Перевешивая затраты по контролю на заказчика.
На самом деле, конечно же, у вас есть метрики — как минимум количество упавших тестов. Вот только, что это и есть контроль и он тоже может производиться по разному и что стоимость этого контроля тоже часть стоимости продукта (за качество платят знаете ли) вы кажется не понимаете.
А отсюда отношение к вашей статье как к буллшиту и вопросы про ваше образование.
Контроль качества — это оценка качества выпускаемого продукта. Не проверка работы, а оценка качества. Измерение.
Этой фразы я совсем не понял. Допустим, завод выпускает штангенциркули. (или фотоаппараты, или программы). В ОТК сидит Маня с набором эталонных мерных болванок и измеряет каждую из них проверяемым штангенциркулем. Если результат не совпадёт с заданным — штангенциркуль отправляется на переградуировку (или как это называется). Не совпадёт второй раз — значит, штангенциркуль кривой и пойдёт на переплавку.
Что же Маня делает? Проверяет работу или оценивает качество?
И, кстати, допускается ли в реальном производстве использование результатов маниных измерений для градуировки (при условии, что она потом всё равно будет проверять то, что получилось)?
Основная цель существования Мани — не проверять работу (для этого есть менеджер, Code review и прочее), а верифицировать работу на то, что она соответствует заказу — что, например, произведено 1000 болванок с 3-мя процентами брака, при допустимом уровне в 5%. А задача менеджера уже решить, что если в договоре написано 5%, то можно отгружать. А если написано 1% — то идти к Петровичу и выяснять кто виноват и что нужно сделать, чтобы процент брака уменьшился.
Если бы задачей тестировщика было блокировать выпуск продукта с багами — то ни у кого релизов не было бы вообще. Продукты выпускаются с багами, просто они имеют приоритет. И если баг незначительный, то вполне возможно что исправлять его никто никогда не будет. Потому что продукт должен выпускаться в заданные сроки и за заданные деньги, а поток задач и багов есть всегда.
Для градуировки применяется эталон (в случае разработки ПО — это спецификация в любой форме, возможно даже в виде тестов).
Если бы задачей тестировщика было блокировать выпуск продукта с багами — то ни у кого релизов не было бы вообще. Продукты выпускаются с багами, просто они имеют приоритет. И если баг незначительный, то вполне возможно что исправлять его никто никогда не будет. Потому что продукт должен выпускаться в заданные сроки и за заданные деньги, а поток задач и багов есть всегда.
Для градуировки применяется эталон (в случае разработки ПО — это спецификация в любой форме, возможно даже в виде тестов).
Термин «работа» оказался двусмысленным — работа по производству изделия и работа (работоспособность) самого изделия. Маня проверяет второе и, теоретически, при достаточной осведомлённости о процессе, может по результатам своей проверки дать рекомендации по первому (например, уволить главного распайщика плат, а уборщице выдать новую тряпку — а то болванки все какие-то пыльные). Но это только рекомендации. Как и по каждой конкретной болванке — она по инструкции делит их на 1, 2, 3 сорт и некондицию, а уже менеджер по этим рекомендациям решает, что с болванкой делать.
Так что формально она ничего не блокирует, а только проверяет… В общем, я со всем согласен.
А вопрос про градуировку в этих терминах звучит так: может ли для градуировки и для проверки использоваться один и тот же набор эталонов? Боюсь, что для ПО аналог такого вопроса придумать трудно. Разве что случайно генерирующиеся тесты — на нескольких случайных тестах настраиваем параметры эвристик, на остальных проверяем.
Так что формально она ничего не блокирует, а только проверяет… В общем, я со всем согласен.
А вопрос про градуировку в этих терминах звучит так: может ли для градуировки и для проверки использоваться один и тот же набор эталонов? Боюсь, что для ПО аналог такого вопроса придумать трудно. Разве что случайно генерирующиеся тесты — на нескольких случайных тестах настраиваем параметры эвристик, на остальных проверяем.
Интересный вопрос на самом деле.
Попробую перефразировать так:
При постановке задачи используются данные выдуманные аналитиком. Можно ли их использовать при тестировании или лучше использовать данные из продакшна.
Если я правильно понял вопрос, то мой не очень большой опыт, тем не менее включает ряд случаев, когда тщательно оттестированный функционал радостно падал после выкладки на продакшн. Соответственно, чем ближе тестовые данные к продакшну — тем лучше. С другой стороны, если брать данные из продакшна, то возникает куча других проблем, начиная от возможного неполного покрытия и заканчивая проблемами ИБ.
Попробую перефразировать так:
При постановке задачи используются данные выдуманные аналитиком. Можно ли их использовать при тестировании или лучше использовать данные из продакшна.
Если я правильно понял вопрос, то мой не очень большой опыт, тем не менее включает ряд случаев, когда тщательно оттестированный функционал радостно падал после выкладки на продакшн. Соответственно, чем ближе тестовые данные к продакшну — тем лучше. С другой стороны, если брать данные из продакшна, то возникает куча других проблем, начиная от возможного неполного покрытия и заканчивая проблемами ИБ.
Применяя подход из статьи, сначала стоит обсудить все детали болванки, потом выпустить одну и показать заказчику. Если это то, что ему нравится, то закрепить ее в качестве стандарта (приемочного теста) и автоматизировать проверку. Маню уволить. После этого выпускать точно такие же, показывая каждую сотую, чтобы вдруг не оказалось, что рынок поменялся.
А в вашем подходе с кучей метрик и отделов качества вся эта братия, «имеемая анально» под главенством Мани, будет по прежнему производить никому не нужный хлам. Да оставайтесь же вы в прошлом, в которое не хочется возвращаться!
А в вашем подходе с кучей метрик и отделов качества вся эта братия, «имеемая анально» под главенством Мани, будет по прежнему производить никому не нужный хлам. Да оставайтесь же вы в прошлом, в которое не хочется возвращаться!
… и автоматизировать проверку. Маню уволить.
Тем, кто сможет автоматизировать проверку болванки, в нашем времени делать нечего. Пусть возвращаются к себе, в 22-й век… Потому что на любую хитрую автоматическую проверку слесарь Вася наверняка сделает (совершенно случайно, естественно) болванку «с винтом», которая эту проверку легко пройдёт. Потому что «стандарт» и «приёмочный тест» это разные вещи — первое — объект, а второе — функция сравнения двух объектов. И наличие эталонного объекта совсем не гарантирует возможности реализовать автоматическую функцию сравнения.
Если это то, что ему нравится, то закрепить ее в качестве стандарта (приемочного теста) и автоматизировать проверку. Маню уволить. После этого выпускать точно такие же, показывая каждую сотую, чтобы вдруг не оказалось, что рынок поменялся.
Два вопроса:
1. Ну и как по вашему называется процесс проверки каждой сотой болванки и подсчет брака? Независимо от того кто это делает — тетя Маня или робот?
2. Кто дешевле для внедрения — автоматизированная система или тетя Маня?
А если завод старый и у него тупо нет денег на реорганизацию и внедрение автоматизированной системы? Или болванки такой специальной спагетти-образной формы (ну старые инженеры проектировали, 50 лет назад, поэтому такой гост получился), что для их автоматизированной проверки еще ничего не придумали?
Вот поэтому я вам не зря про прошлое написал. А подсчет брака никто не делает. Останавливают, исправляют проблему и дальше поехали. Почитайте про Тойота систему производства хотя бы пару книг. «Цель» Голдратта тоже прочтите для расширения кругозора, там много про качество и заботу о нем. После этого вернемся к разговору. А википедию завязывайте читать и учебники универские выкиньте с начала века.
Контроль за качеством на всех этапах. В традиционных производственных системах качество выполненной работы проверяют только по ее завершении. Технология стройного производства Toyota предусматривает контроль за качеством на каждом этапе процесса. В отдельных случаях рабочие имеют право остановить конвейер2, при этом они руководствуются жесткими инструкциями, основная цель которых — обеспечить единый стандарт выполнения работ и обслуживания техники, чтобы минимизировать поломки и прочие сбои в работе оборудования. В идеале любой дефект должен быть устранен до того, как продукция перейдет на следующий этап обработки. Это уменьшает количество дорогостоящих доделок и повышает ответственность работников. Система стройного производства рассматривает остановку оборудования как потерю, поэтому на производственных предприятиях действует так называемая система общего превентивного обслуживания. Ее цель — за счет постоянного контроля со стороны работников не допустить поломок оборудования и простоя.
Отсюда — toyota-russia.ru/about_toyota/secrets/lean_manufacturing/lean_manufacturing.htm
Не гоните, пожалуйста. Считают, и считают на каждом этапе, и записывают в потери.
Епрст, так я и предлагаю на каждом этапе в статье делать, а не только на завершающем. В этом и смысл. Модульные тесты, правильное планирование, TDD, прототипы и другие практики направлены на то, чтобы устранить ошибку на ранних этапах, а не ждать пока отдадут на тестирование. И теперь вы пришли к тому же…
Если бы было так просто. Чтобы обнаружить ошибку на ранних этапах может не хватить точности контрольных приборов, и проявится она только после финальной сборки изделия (и то не сразу — а после термоциклов и вибротестов). И выяснять её причину придётся по косвенным признакам, поскольку прямых тестов по-прежнему нет…
Так все-таки есть у вас контроль качества? Так что ж вы нам рассказываете?
Я вам и пытаюсь с самого начала рассказать, что TDD, автоматизированные функциональные тесты и прочее — это и есть средства контроля качества, которые разрабатывают ваши же разработчики.
А теперь давайте посмотрим с других сторон:
1. Я никогда в жизни не поверю, что где-то есть проект покрытый автоматизированными тестами на 100%. Или что есть проект, который ручным тестированием тестируется на 100%.
2. Есть такая штука как объективная реальность. А в нее включены такие вещи, как бюджет проекта, сложность проекта, наличие специалистов на рынке труда и прочее-прочее-прочее. Из чего в итоге складывается:
а) ресурсная стоимость проекта;
б) временная стоимость проекта;
в) и в итоге — качество, выраженное как способность продукта решать возложенные на него заказчиком задачи.
Так вот, решение о том, что дешевле и лучше — покрывать его автоматизированными тестами или посадить несколько обезьянок, можно принять только посчитав и осознав все эти факторы и оценив стоимость внедрения и его влияние на качество и business value продукта.
Пример — типичная унаследованная монолитная банковская система с 30-летней историей кусками на Java, кусками на каком-нибудь Коболе, без DI, бизнес-логикой на хранимых процедурах и несколькими терабайтами данных в БД. Которая, тем не менее на 100% выполняет свои бизнес-задачи. Как вы будете обеспечивать контроль качества?
Предложите заказчику взять и все переписать, чтобы можно было покрыть юнит-тестами? А сколько на это надо квалифицированных программистов? Сколько они стоят? Куда вам предложат засунуть эту идею?
Я вам и пытаюсь с самого начала рассказать, что TDD, автоматизированные функциональные тесты и прочее — это и есть средства контроля качества, которые разрабатывают ваши же разработчики.
А теперь давайте посмотрим с других сторон:
1. Я никогда в жизни не поверю, что где-то есть проект покрытый автоматизированными тестами на 100%. Или что есть проект, который ручным тестированием тестируется на 100%.
2. Есть такая штука как объективная реальность. А в нее включены такие вещи, как бюджет проекта, сложность проекта, наличие специалистов на рынке труда и прочее-прочее-прочее. Из чего в итоге складывается:
а) ресурсная стоимость проекта;
б) временная стоимость проекта;
в) и в итоге — качество, выраженное как способность продукта решать возложенные на него заказчиком задачи.
Так вот, решение о том, что дешевле и лучше — покрывать его автоматизированными тестами или посадить несколько обезьянок, можно принять только посчитав и осознав все эти факторы и оценив стоимость внедрения и его влияние на качество и business value продукта.
Пример — типичная унаследованная монолитная банковская система с 30-летней историей кусками на Java, кусками на каком-нибудь Коболе, без DI, бизнес-логикой на хранимых процедурах и несколькими терабайтами данных в БД. Которая, тем не менее на 100% выполняет свои бизнес-задачи. Как вы будете обеспечивать контроль качества?
Предложите заказчику взять и все переписать, чтобы можно было покрыть юнит-тестами? А сколько на это надо квалифицированных программистов? Сколько они стоят? Куда вам предложат засунуть эту идею?
Мы с вами разговариваем на разных языках. Представьте, что я бы пытался вас научить бегать, а вы бы постоянно задавали мне вопрос: «хорошо, но как ваши советы заработают, если у меня не будет одной ноги? а двух?».
TDD не может в принципе являться инструментом контроля качества, потому что это стиль разработки (если вы конечно знаете о чем я, а не просто читали пару статей на эту тему). Про покрытие 100% в комментариях по соседству вы тоже можете найти мое мнение. А вот по поводу бюджета и оценки факторов я с вами соглашусь. Об этом писал в комментариях к вот этой статье.
TDD не может в принципе являться инструментом контроля качества, потому что это стиль разработки (если вы конечно знаете о чем я, а не просто читали пару статей на эту тему). Про покрытие 100% в комментариях по соседству вы тоже можете найти мое мнение. А вот по поводу бюджета и оценки факторов я с вами соглашусь. Об этом писал в комментариях к вот этой статье.
Тогда может стоило начинать разговор с «чтобы бегать у вас должны быть ноги, здоровое сердце и непрокуренные легкие», а не с «если вы не бегаете — вы обманываете заказчика»?
TDD не является, а вот юнит-тесты написанные по TDD — очень даже средство контроля качества. Я где-то в комментариях уже писал, кол-во упавших тестов — вполне метрика.
TDD не является, а вот юнит-тесты написанные по TDD — очень даже средство контроля качества. Я где-то в комментариях уже писал, кол-во упавших тестов — вполне метрика.
2. Зависит от необходимой квалификации Мани. Возможно, ей в помощь надо дать робота, который выполняет чёрную работу по проверке. Но подписывать протокол всё равно будет она.
Еще один пример:
Представьте себе контору «Op-op-oppan Govnosite», которая существует за счет того, что берет заказы на сайты-визитки и выполняет их за счет экплуатации труда одногруппника гендиректора Пети, который на 3-ем курсе прочитал книжку про PHP и поставил себе джумлу, найденного на просторах фриланс.ру дизайнера Эдуарда и гендиректорской сестры Юли, которой поставили на компьютер пиратский MS Project.
Чтобы гендиректор купил себе дэуматиз, Петя — новый айфон, а Эдуард не валялся в офисе на диване с очередной ломкой, им нужно сделать, скажем 5 визиток и 1 интернет-магазин в месяц.
Она им нужна, эта автоматизация? Или проще попросить Юлю перед отправкой результата заказчику просматривать его на предмет явных косяков?
Представьте себе контору «Op-op-oppan Govnosite», которая существует за счет того, что берет заказы на сайты-визитки и выполняет их за счет экплуатации труда одногруппника гендиректора Пети, который на 3-ем курсе прочитал книжку про PHP и поставил себе джумлу, найденного на просторах фриланс.ру дизайнера Эдуарда и гендиректорской сестры Юли, которой поставили на компьютер пиратский MS Project.
Чтобы гендиректор купил себе дэуматиз, Петя — новый айфон, а Эдуард не валялся в офисе на диване с очередной ломкой, им нужно сделать, скажем 5 визиток и 1 интернет-магазин в месяц.
Она им нужна, эта автоматизация? Или проще попросить Юлю перед отправкой результата заказчику просматривать его на предмет явных косяков?
На этом этапе, наверное, нет. Но когда они выйдут на уровень 5000 сайтов в месяц и гендиректор начнёт думать о Бентли, то придётся решать, что выгоднее — нанимать 50 юль или подумать над автоматизацией.
Этот вопрос должен будет решаться для каждого из 5000 сайтов в зависимости от того, что это за сайты. Автоматизировать тестирование типового сайта на джумле дольше и дороже, чем его разрабатывать (имхо, конечно).
Организовывать полное тестирование конечно дольше. Но зачем тестировать код Джумлы? Только то, что пишем сами.
Кроме того, если есть отлаженная инфраструктура способная за разумные сроки оттестировать 5000 сайтов, есть специалисты, набившие на этом руку, то может оказаться, что автоматические тестирование быстрее и дешевле ручного, особенно если не тратить время на оценку стоит ли автотестировать конкретный сайт, а лелать это по по умолчанию.
Одна из основных причин неиспользования автотестов — трудность внедрения. Инфраструктура, инструменты, обучение или найм специалистов, выработка паттернов и т. п. Если продукт унаследованный, то хоть минимальное покрытие его тестами (зачастую с архитектурой слабо пригодной к тестированию). Но вот когда уже внедрено, поставлено на поток, как-то процесс упрошается.
Кроме того, если есть отлаженная инфраструктура способная за разумные сроки оттестировать 5000 сайтов, есть специалисты, набившие на этом руку, то может оказаться, что автоматические тестирование быстрее и дешевле ручного, особенно если не тратить время на оценку стоит ли автотестировать конкретный сайт, а лелать это по по умолчанию.
Одна из основных причин неиспользования автотестов — трудность внедрения. Инфраструктура, инструменты, обучение или найм специалистов, выработка паттернов и т. п. Если продукт унаследованный, то хоть минимальное покрытие его тестами (зачастую с архитектурой слабо пригодной к тестированию). Но вот когда уже внедрено, поставлено на поток, как-то процесс упрошается.
Конечной задачей Б является недопущение некачественной работы со стороны А.
Вот она, ошибка в рассуждениях. Недопущение некачественной работы — это не задача Б, это задача кого угодно кроме Б и всех понемножку.
Задача Б — это только оценить качественно или некачественно и почему.
В современной промышленной разработке контроль качества — составная часть общего процесса ALM. Поздно контролировать качество, когда продукт уже разработан. Не путайте с контролем качества в серийном производстве, когда нужно проверить каждый выходящий экземпляр. Там это действительно отдельный процесс
это все равно что нанять по одной медсестре на каждую операцию, только для того, чтобы она проверяла, а не забыл ли кто-то инструмент в пациенте
Почему на каждую-то? А Вас не удивляет, что там стоит медсестра просто для того, чтобы подавать инструменты хирургу? Казалось бы, возьми сам со столика, не выпендривайся. Нет же:
— Зажим!
— Тампон!
— Спирт!
— Огурец!
— Зажим!
— Тампон!
— Спирт!
— Огурец!
Хорошая же идея, только не помогает. Во мне лично один раз забыли тампон, сколько еще таких.
За качество отвечает тот, кто производит товар или услугу, то есть исполнитель. В нашем случае это и есть сам разработчик.
ОТК
Но в других сферах жизни так не делают. За качество отвечает тот, кто производит товар или услугу, то есть исполнитель. В нашем случае это и есть сам разработчик.
В любой технологически сложной отрасли есть понятие «контроль качества». Это значит, что помимо отделов по производству, существует отдел по проверке качества продукции, в том числе соответствия продукции нормативам предприятия.
Сразу хочу заметить, что проводить прямую аналогию между процессом проектирования и реализации автоматизированных систем и производством материальных товаров — не очень корректно.
Кстати говоря, у вас в статье нет определения «качества», которое по-вашему должны обеспечивать разработчики вместо тестировщиков. Что вы понимаете под качеством? Что вы понимаете под дефектом? Вы уверны, что разработчики могут успешно тестировать документацию, например? Есть немало исследований, подтверждающих факт о том, что контроль должен производится внешней системой (могу попозже написать несколько ссылок на такие, если интересно).
Поддержу. Довелось работать в проектном институте(мосты проектировали и др. строительство). Так вот на каждом чертеже ставил подпись не только исполнитель, но и проверяющий, и решающая ответсвенность была не нём.
Я больше вел речь не о производстве, а просто о заказных услугах по осуществлению каких-то работ. Вот заказали вы ремонт в квартире, пояснили как хотите чтобы он выглядел, нарисовали на бумажке, команду наняли толковую и дорогую. Смотрите в смету, а там графа «специалисты по контролю качества». А можете ли вы тем же людям доверить проверять качество и почему это отдельные люди? Что изначально есть риск получить некачественную работу, если этим специалистам не заплатить денег. Да и в чем им интерес своих же работников «подставлять»? Для вас качество будет соответствовать вашему пониманию + мнению независимых специалистов. Но вот независимые специалисты помогут вам с КОНТРОЛЕМ КАЧЕСТВА, а ваша вовлеченность в ремонт (просмотр ранних результатов, подстраивание и корректировка планов, общение с бригадой) поможет с ОБЕСПЕЧЕНИЕМ КАЧЕСТВА.
По поводу дефекта у меня есть определенное разделение, я о нем уже писал не раз. Про документацию речи в статье не шло, потому что разработчики ее и не пишут. Это не их труд.
По поводу дефекта у меня есть определенное разделение, я о нем уже писал не раз. Про документацию речи в статье не шло, потому что разработчики ее и не пишут. Это не их труд.
Вы шутите? Если я увижу бригаду делающую ремонт с привлечением специалистов контроля качества, то я закричу shut up and take my money!!!
Заплатить денег и через месяц вернуться в квартиру с идеальным ремонтом, это ли не мечта?
Другой вопрос если там весь персонал нифига не умеет делать и сделает косые стены что с тестировщиками что без. Ну так это не вопрос подхода.
Это дома вы ходите каждый день смотреть как вам пол красят. В большом строительстве уверен заказчик находит каждый вечер смотреть как там дом строят. Проект подписал, бабло заплатил, результат получил.
Пока писал длинный ответ, выкристаллизовалась короткая мысль:
заказчик хочет за деньги получить готовый продукт, а не геморрой с его вечным контролем и доработками.
Заплатить денег и через месяц вернуться в квартиру с идеальным ремонтом, это ли не мечта?
Другой вопрос если там весь персонал нифига не умеет делать и сделает косые стены что с тестировщиками что без. Ну так это не вопрос подхода.
Это дома вы ходите каждый день смотреть как вам пол красят. В большом строительстве уверен заказчик находит каждый вечер смотреть как там дом строят. Проект подписал, бабло заплатил, результат получил.
Пока писал длинный ответ, выкристаллизовалась короткая мысль:
заказчик хочет за деньги получить готовый продукт, а не геморрой с его вечным контролем и доработками.
Интерес специалистов по контролю качества в этом случае — не допустить, чтобы вам сдали некачественную работу, чтобы фирма/команда не несла материальных и(или) репутационных потерь. Если просто гарантия на работу, то интереса у них действительно маловато, а вот если штрафы-неустойки…
контроль качества не может улучшить качество, он может только контролировать
абсолютно верно
Непонятно. Контроль качества выдаёт протокол контрольной процедуры, в котором указано, какие тесты не пройдены и какие параметры находятся за пределами допуска. Те, кто будет дорабатывать изделие, вероятно, воспользуются этой информацией — как для конкретного изделия, так и для улучшения технологического процесса. И для внедрения контроля на более ранние стадии (если это возможно). Так что в улучшении качества участвуют все, в том числе и контроль.
расскажите поподробнее что же вы делаете для того, чтобы баги не переоткрывались снова и снова
с и спримерами не с потолка взятыми
от того что в жире(или еще где-то) висит сотня другая багов качество не улучшается само собой, и даже более того из-за того что они там висят, а не правятся, качество только ухудшается со временем
с и спримерами не с потолка взятыми
от того что в жире(или еще где-то) висит сотня другая багов качество не улучшается само собой, и даже более того из-за того что они там висят, а не правятся, качество только ухудшается со временем
Пытаемся понять их причину. И устранить.
В сканере несколько узлов, соединённых между собой. Есть прочность и упругость каждого узла, есть качество соединения. Промерить геометрические параметры деталей с точностью до угловой секунды мы не можем, единственный способ контроля сейчас — это сканировать известный объект, и по результатам пытаться определить какие физические параметры (или параметры из каких групп) изменяются. Собственно, эта процедура и является финишным контролем качества: если изменения в пределах допуска, изделие считается пригодным к эксплуатации.
Ошибки действительно повторяются снова и снова, это даёт статистику. Видно, как различные параметры меняются за время тестирования (а в некоторых случаях — и эксплуатации) изделия. И иногда видны корреляции ошибок с изменениями этапов технологического процесса.
После выявления подозрительного места конструкции оно изучается подробнее. Иногда при этом удаётся выявить дефекты и придумать, как их устранить. Иногда не удаётся — и приходится идти по пути «взять железку потолще и прожарить получше». Последним дефектом, обнаруженным таким образом, оказалось то, что винты в одном месте были из стали не той марки.
В сканере несколько узлов, соединённых между собой. Есть прочность и упругость каждого узла, есть качество соединения. Промерить геометрические параметры деталей с точностью до угловой секунды мы не можем, единственный способ контроля сейчас — это сканировать известный объект, и по результатам пытаться определить какие физические параметры (или параметры из каких групп) изменяются. Собственно, эта процедура и является финишным контролем качества: если изменения в пределах допуска, изделие считается пригодным к эксплуатации.
Ошибки действительно повторяются снова и снова, это даёт статистику. Видно, как различные параметры меняются за время тестирования (а в некоторых случаях — и эксплуатации) изделия. И иногда видны корреляции ошибок с изменениями этапов технологического процесса.
После выявления подозрительного места конструкции оно изучается подробнее. Иногда при этом удаётся выявить дефекты и придумать, как их устранить. Иногда не удаётся — и приходится идти по пути «взять железку потолще и прожарить получше». Последним дефектом, обнаруженным таким образом, оказалось то, что винты в одном месте были из стали не той марки.
Эту же работу может выполнять разработчик.
Однако, это уже несколько другое ремесло, которое мало того, что требует других навыков, но ещё и требует некую отстранённость от самого продукта, чтобы не упустить из внимания какой-то момент, который для разработчика может казаться очевидным, но вполне подвержен ошибкам.
Объяснить заказчику необходимость тестирования и привлечения инженеров по тестированию — это задача руководителя проекта. Действительно, приведённый выше диалог почти невероятен, но к нему надо быть готовым.
Зато гораздо более вероятен следующий диалог:
— Наш план управления проектом включает план непрерывного совершенствования процесса разработки и квалификации сотрудников в целом…
— Э-э… но разве не вы говорили, что у вас совершенная команда суперпрофессионалов? Почему я должен тратить свои ресурсы на то, что выгодно, кажется, исключительно вам?
Вот это объяснить гораздо сложнее, особенно, если заказчик не совсем лояльный.
Однако, это уже несколько другое ремесло, которое мало того, что требует других навыков, но ещё и требует некую отстранённость от самого продукта, чтобы не упустить из внимания какой-то момент, который для разработчика может казаться очевидным, но вполне подвержен ошибкам.
Объяснить заказчику необходимость тестирования и привлечения инженеров по тестированию — это задача руководителя проекта. Действительно, приведённый выше диалог почти невероятен, но к нему надо быть готовым.
Зато гораздо более вероятен следующий диалог:
— Наш план управления проектом включает план непрерывного совершенствования процесса разработки и квалификации сотрудников в целом…
— Э-э… но разве не вы говорили, что у вас совершенная команда суперпрофессионалов? Почему я должен тратить свои ресурсы на то, что выгодно, кажется, исключительно вам?
Вот это объяснить гораздо сложнее, особенно, если заказчик не совсем лояльный.
Из своей практики, предположим разрабатываете вы систему управления для загрузчика ядерного топлива в АЭС. И вот решили вы отказаться от тестировщиков, программист запрограммировал всё на основе входных параметров, данных итп, в штатном режиме все работает так как и должно, но как оно будет работать в нештатном режиме?
Так, разработчик садится и думает, гадает что такое нештатный режим, хорошо что это было во входных данных, но у нас не всегда всё так. А заточенные тестеры уже в курсе всех возможных нештатных ситуациях, так как сдали уже 3 проекта, а разработчик наш пришел с института 3 месяца назад. Штатный режим описал он всё четко и без ошибок, а вот кое, что пропустил, и даже не догадывался, что такое может быть. Пример возможно не совсем понятен, но основная моя мысль в следующем.
Всё зависит от системы, какие результаты могут нанести те или иные ошибки.
Или это хабр, где упадет поиск, пнут Васю, он багу зафиксит и вроде ничего не произошло.
А взять АЭС, так там помимо штатных тестировщиков еще и внешняя экспертиза подключится, всё на 10 раз перепроверят, так как минимальный сбой может такого наделать.
Или взять страховую компанию, ну подумаешь премию вместо 10 насчитала 10.00001, ошибка то ерундовая в расчете премий, ладно увидят это сотрудники страховщика, а если это дойдет до клиента, он подаст в суд, а таким клиентом был газовым гигантом который застраховал буровую установку, и там премии в млрдах исчисляется.
Так же вы описали коня в вакууме, НЕ БЫВАЕТ команды на 100% из супер профессионалов, невозможно им сразу родится, и конкуренция на рынке всегда есть, сегодня у вас их 10 а завтра уже 8, и вы берете 2 мидлов, которые могут допустить ошибки.
И действительно тут правильно указали, время разработчика дороже, нежели тестера. И это так же нужно учитывать.
Автоматизация никогда не покроет 100% возможных кейсов.
Так же добавлю, любой профи человек, с девушкой поссорился, вчера перепил на свадьбе, гриппует, сидит с температурой +40. И тут хоть какой вы супер менеджер, но человек может допустить ошибку, и уйти на больничный. И что вы предлагаете? Взять второго ( у которого загрузка 100%) и попросить его проверить, что вчера Вася налабал с жутким похмельем? И на завтра у вас -1 профессионал.
Надеюсь мои мысли будут понятны.
Так, разработчик садится и думает, гадает что такое нештатный режим, хорошо что это было во входных данных, но у нас не всегда всё так. А заточенные тестеры уже в курсе всех возможных нештатных ситуациях, так как сдали уже 3 проекта, а разработчик наш пришел с института 3 месяца назад. Штатный режим описал он всё четко и без ошибок, а вот кое, что пропустил, и даже не догадывался, что такое может быть. Пример возможно не совсем понятен, но основная моя мысль в следующем.
Всё зависит от системы, какие результаты могут нанести те или иные ошибки.
Или это хабр, где упадет поиск, пнут Васю, он багу зафиксит и вроде ничего не произошло.
А взять АЭС, так там помимо штатных тестировщиков еще и внешняя экспертиза подключится, всё на 10 раз перепроверят, так как минимальный сбой может такого наделать.
Или взять страховую компанию, ну подумаешь премию вместо 10 насчитала 10.00001, ошибка то ерундовая в расчете премий, ладно увидят это сотрудники страховщика, а если это дойдет до клиента, он подаст в суд, а таким клиентом был газовым гигантом который застраховал буровую установку, и там премии в млрдах исчисляется.
Так же вы описали коня в вакууме, НЕ БЫВАЕТ команды на 100% из супер профессионалов, невозможно им сразу родится, и конкуренция на рынке всегда есть, сегодня у вас их 10 а завтра уже 8, и вы берете 2 мидлов, которые могут допустить ошибки.
И действительно тут правильно указали, время разработчика дороже, нежели тестера. И это так же нужно учитывать.
Автоматизация никогда не покроет 100% возможных кейсов.
Так же добавлю, любой профи человек, с девушкой поссорился, вчера перепил на свадьбе, гриппует, сидит с температурой +40. И тут хоть какой вы супер менеджер, но человек может допустить ошибку, и уйти на больничный. И что вы предлагаете? Взять второго ( у которого загрузка 100%) и попросить его проверить, что вчера Вася налабал с жутким похмельем? И на завтра у вас -1 профессионал.
Надеюсь мои мысли будут понятны.
Давайте по порядку.
Я с вами на 100% согласен, что в таких критических проектах надо на порядок больше внимания уделить процессу тестирования, даже стоит отдельную стороннюю команду тестирования нанять, а может и больше. Ведь цена ошибки колоссальна. Мы все такие проекты пишем? У всех такой риск ошибки?
Многие компании предпочитают делать небольшие команды, чтобы поддерживать культуру качества. Если набрать одних студентов, то понятное дело так работать не будет. А команд, в которых вся команда отвечает за качество и прилагает максимум усилий, чтобы не допускать понижения его уровня, я знаю много.
Это обезьяньего тестера. Хороший специалист по тестированию стоит немало, а за границей даже больше в некоторых случаях разработчика.
100% — абсолют. Он недостижим. Но приблизится к нему на безопасное расстояние с приемлемыми затратами можно.
Ваши мысли непонятны. У нас, к примеру, весь код обязательно проходит ревью и на него будут смотреть другие разработчики. Так что ваш плохой код по личностным проблемам не пролезет. А 100% загрузка и стремление к ней — еще одно большое зло в IT.
Из своей практики, предположим разрабатываете вы систему управления для загрузчика ядерного топлива в АЭС.
Я с вами на 100% согласен, что в таких критических проектах надо на порядок больше внимания уделить процессу тестирования, даже стоит отдельную стороннюю команду тестирования нанять, а может и больше. Ведь цена ошибки колоссальна. Мы все такие проекты пишем? У всех такой риск ошибки?
Так же вы описали коня в вакууме, НЕ БЫВАЕТ команды на 100% из супер профессионалов, невозможно им сразу родится, и конкуренция на рынке всегда есть, сегодня у вас их 10 а завтра уже 8, и вы берете 2 мидлов, которые могут допустить ошибки.
Многие компании предпочитают делать небольшие команды, чтобы поддерживать культуру качества. Если набрать одних студентов, то понятное дело так работать не будет. А команд, в которых вся команда отвечает за качество и прилагает максимум усилий, чтобы не допускать понижения его уровня, я знаю много.
И действительно тут правильно указали, время разработчика дороже, нежели тестера. И это так же нужно учитывать.
Это обезьяньего тестера. Хороший специалист по тестированию стоит немало, а за границей даже больше в некоторых случаях разработчика.
Автоматизация никогда не покроет 100% возможных кейсов.
100% — абсолют. Он недостижим. Но приблизится к нему на безопасное расстояние с приемлемыми затратами можно.
Так же добавлю, любой профи человек, с девушкой поссорился, вчера перепил на свадьбе, гриппует, сидит с температурой +40. И тут хоть какой вы супер менеджер, но человек может допустить ошибку, и уйти на больничный. И что вы предлагаете? Взять второго ( у которого загрузка 100%) и попросить его проверить, что вчера Вася налабал с жутким похмельем? И на завтра у вас -1 профессионал.
Ваши мысли непонятны. У нас, к примеру, весь код обязательно проходит ревью и на него будут смотреть другие разработчики. Так что ваш плохой код по личностным проблемам не пролезет. А 100% загрузка и стремление к ней — еще одно большое зло в IT.
Но в других сферах жизни так не делают. За качество отвечает тот, кто производит товар или услугу, то есть исполнитель. В нашем случае это и есть сам разработчик. Поэтому отвечать за обеспечение качества своей работы он должен самостоятельно.
Чушь полная.
Любая серьезная инжерная разработка или прозводство всегда предполагает наличие отдела контроля качества неподотчетного инженерам. ЛЮБАЯ. И независимо от того как он называется — ОТК, QA, тестировщики. За качество действительно отвечает исполнитель. Но проверять это качество и заставлять переделывать должен кто-то кто исполнителю не подчиняется и имеет соответсвующие KPI. И так как у них есть такой KPI, именно тестировщики будут отвечать за то, что они пропустили баг.
UPD А вот если из-за того что тестировщику не будут пропускать баги будет продолбан дедлайн, то отвечать будет разработка. Все правильно.
В принципе, если эти отделы спрятаны от заказчика и вы просто не способны по-другому делать ПО, то это допустимо. Благодаря этому стоимость ваших услуг возрастет и вы будете неконкурентны на рынке. Пока это не так, но к этому идет. Знаю много компаний, в которых отделы тестирования расформировывают, а тестировщиков интегрируют в команды разработки. Чтобы ВКЛАДЫВАТЬ КАЧЕСТВО, а не контролировать, когда поделать уже ничего нельзя.
Множество раз приходилось ронять «идеальный продукт» своей команды. И дело не в компетентности или ее отсутствии, а именно в пресловутом мышлении. Разработчики мыслят более линейно и не объективны к своему проекту. Не говоря уже о Product Owner'е.
А касаемо автоматизации — полностью согласен.
А касаемо автоматизации — полностью согласен.
Еще вспомнилась ситуация с выпуском российских игр (Аллоды Онлайн, Корсары 3), когда спустя даже несколько этапов альфа- и бета-тестирования продукт выходил совершенно сырой, а целевая аудитория потребителей становилась отделом тестирования, что незамедлительно сказалось на продажах и имидже студии-разработчика.
Тестировщики это миф!
Если в проекте за качество отвечают тестировщики, то качества там не будет. В нормальных проектах за качество отвечают все до единого члены команды и даже заказчик, а тестировщики занимаются тем что качество измеряют и информируют о результатах руководителя и разработчиков.
Запомните! Тестировщики всего лишь измеряют качество продукта!
Запомните! Тестировщики всего лишь измеряют качество продукта!
Если качество продукта можно достоверно измерить без тестировщиков, то тестировщики на таком проекте не нужны.
знаете, если посчитать что все люди могут достоверно и точно без субъективных факторов оценить качество., то вы безусловно правы. В жизни все немного не так.
Для примера, приходит «эффективный» менеджер и внедряет свою технологию контроля качества, но, уже морально и технологически устаревшую и считает, что теперь они могут объективно измерять качество. И они могут, но эта оценка уже не так точна. как могла бы быть, если бы он знал другие технологии.
Или программист покрывают код на 99 процентов, проводят код ревью и уверены, что у них хорошее качество, а потом оказывается, что они пропустили важное требование, и тогда получается что они ошиблись.
Для примера, приходит «эффективный» менеджер и внедряет свою технологию контроля качества, но, уже морально и технологически устаревшую и считает, что теперь они могут объективно измерять качество. И они могут, но эта оценка уже не так точна. как могла бы быть, если бы он знал другие технологии.
Или программист покрывают код на 99 процентов, проводят код ревью и уверены, что у них хорошее качество, а потом оказывается, что они пропустили важное требование, и тогда получается что они ошиблись.
Жизнь без тестировщиков вполне возможна. Но имеет смысл она в маленьких командах, в которых разработчики не являются инженерами, а, скорее, универсальными специалистами. И эти универсальные специалисты точно так же вполне способны ставить себе задачи, локлизовывать текст (например, написав сервер, сканирующий опенсорс локализацию и по нему вставляя свои строки)
В случае большой задачи одновременное выполнение разработки/тестирования (и любой другой активности не относящейся напрямую к разрабтке) не так эффективно, так как разработчик точно так же как и тестировщик должен потратить на эту активность своё время. Переключение контекста в данном случае приводит к снижению качества и скорости разработки. Иллюстрацией тут может служить конвейерная разработка.
Программист обязан проверить корректное выполнение поставленной задачи. И даже (в случае отсутствия соответствующих ресурсов) написать автоматические тесты. Однако проверку регрессий, производительности, покрытия требований к программному продукту и ручное интеграционное тестирование стоит доверить инженеру контроля качества.
В случае большой задачи одновременное выполнение разработки/тестирования (и любой другой активности не относящейся напрямую к разрабтке) не так эффективно, так как разработчик точно так же как и тестировщик должен потратить на эту активность своё время. Переключение контекста в данном случае приводит к снижению качества и скорости разработки. Иллюстрацией тут может служить конвейерная разработка.
Программист обязан проверить корректное выполнение поставленной задачи. И даже (в случае отсутствия соответствующих ресурсов) написать автоматические тесты. Однако проверку регрессий, производительности, покрытия требований к программному продукту и ручное интеграционное тестирование стоит доверить инженеру контроля качества.
сам разработчик особо не переживает и может делать некачественное решение
Выходит есть такие конторы, в которых программистам позволено писать полную лажу с кучей багов, и им за это ничего не будет — и это не по недосмотру какому, а установленная практика. Что-то я сильно сомневаюсь в существовании подобных.
Из вашего текста можно подумать, что в компаниях, в которых есть тестировщики, разработчики именно так и работают. Но это же не серьёзно.
За качество отвечает тот, кто производит товар или услугу, то есть исполнитель. В нашем случае это и есть сам разработчик
Нет уж, уважаемый, в нашем случае это не какой-нибудь Василий-разработчик, а именно вся команда, включая проектного менеджера, всяческих тех райтеров, тим лидов, билд инженеров, дев опсов и т.п.
И не забывайте — не бывает программ без ошибок.
По поводу ваших сомнений в существовании таких компаний — поверьте, за мой опыт консультирования и проведения тренингов я таких видел и очень много.
А по поводу ответственности всей команды я с вами совершенно согласен. Вот только как билд инженер мог повлиять на качество кода, который писали другие? Орать на них или морально давить?
А по поводу ответственности всей команды я с вами совершенно согласен. Вот только как билд инженер мог повлиять на качество кода, который писали другие? Орать на них или морально давить?
Ну билд инженер то элементарно — поднимает continuous integration, который авто-билдами выявляет ошибки компиляции, прикручивает запуск после билдов авто-тестов (написанных не ним — но прикручивает к билдам именно он, со всеми нужными дополнениями вроде разворачивания в случае потребности базы с каноническими данными, VM и всего прочего необходимого для запуска тестов), которые выявляют прочие ошибки.
Но разработчики как писали хреновый код так и будут продолжать. Он тоже будет в ответе?
Но разработчики как писали хреновый код так и будут продолжать
Даже после того как поломанный билд однозначно указывает на виновного?
Но даже и для такого есть способ — последний поломавший билд в качестве наказания, например, назначается ответственным за билды, и помогает билд инженеру мейнтейнить их (а то и вовсе за билд инженера назначается). После такого ломать билды никто точно не захочет — проверено на практике.
Товарищ топикстартер продемонстрировал распространенную деформацию мышления: действительно многие люди не понимают, что когда мы отходим от кустарщины, человек, который делает продукт , человек, который оценивает качество и человек, который контролирует качество не могут быть одним и тем же человеком. Это как школьная учительница Мариванна, которая 10 лет учила Вовочку и на выпускном экзамене должна поставить ему (то есть себе) итоговую оценку, которая значительно повлияет на ее зарплату.
Хотел было спросить, где это автор понабрался таких идеек и как, может быть, он умудрился запустить реальный проект с таким подходом к качеству, но вот это снимает вопросы. 6 лет в аутсорсинге кому угодно крышу снесут и теперь как и гласит поговорка, кто не умеет тот учит (разработке без тестировщиков).
Отдельно повеселило предложение заказчику проводить приемное тестирование по окончании итерации. Представляю себе
— Алле, Иваниваныч, подъезжайте к нам, будете приемочное тестирование проводить.
— Нифигасе, закончили что ли уже? Вроде бы две недели назад только начали.
— Да, нет, что вы, только первую итерацию закончили. Так что сформулируйте критерии приемки для нашей пре-альфы и подъезжайте
Хотел было спросить, где это автор понабрался таких идеек и как, может быть, он умудрился запустить реальный проект с таким подходом к качеству, но вот это снимает вопросы. 6 лет в аутсорсинге кому угодно крышу снесут и теперь как и гласит поговорка, кто не умеет тот учит (разработке без тестировщиков).
Отдельно повеселило предложение заказчику проводить приемное тестирование по окончании итерации. Представляю себе
— Алле, Иваниваныч, подъезжайте к нам, будете приемочное тестирование проводить.
— Нифигасе, закончили что ли уже? Вроде бы две недели назад только начали.
— Да, нет, что вы, только первую итерацию закончили. Так что сформулируйте критерии приемки для нашей пре-альфы и подъезжайте
Отдельно повеселило предложение заказчику проводить приемное тестирование по окончании итерации. Представляю себе
У нас инженеры сами просят, чтобы разработчики тестирующего ПО как можно раньше показывали им пре-альфа версии. Чтобы увидеть, то ли программа тестирует, и смогут ли операторы ей потом пользоваться.
Если вы уже решили перейти на личности и светануть в качестве аргумента моим профилем в LinkedIn, то хочу вас уведомить о специфике своей работы в компании. Я занимаюсь запуском заказных продуктов с нуля. В большинстве своем это сложные распределенные системы: социальные сети, программы лояльности, интеллектуальные краулеры интернета. Два проекта в 2011 году вошли в топ 100 мировых успешных стартапов. Так что это не тот классический аутсорсинг, о котором вы по выходным читаете в уютном кресле за чашкой чая. И описанные в статье подходы отлично работали и работают по сей день.
Вы видимо мало что слышали о современных подходах к разработке и тестированию: Scrum, XP, Kanban. Я уже не говорю про Lean философию и Agile принципы в целом.
Отдельное спасибо за «деформацию мышления» и сомнения в моих обучающих способностях, в которых вы не имели возможности убедиться лично.
Вы видимо мало что слышали о современных подходах к разработке и тестированию: Scrum, XP, Kanban. Я уже не говорю про Lean философию и Agile принципы в целом.
Отдельное спасибо за «деформацию мышления» и сомнения в моих обучающих способностях, в которых вы не имели возможности убедиться лично.
Расскажите, пожалуйста, о численности команд на этих двух проектах 11 года.
Если вы уже решили перейти на личности и светануть в качестве аргумента моим профилем в LinkedIn, то хочу вас уведомить о специфике своей работы в компании. Я занимаюсь запуском заказных продуктов с нуля. В большинстве своем это сложные распределенные системы: социальные сети, программы лояльности, интеллектуальные краулеры интернета. Два проекта в 2011 году вошли в топ 100 мировых успешных стартапов. Так что это не тот классический аутсорсинг, о котором вы по выходным читаете в уютном кресле за чашкой чая. И описанные в статье подходы отлично работали и работают по сей день.
Давайте еще чем-нибудь померяемся. У вас сколько сантиметров?
Любая системная информация должна излагаться с учетом исходных данных, я вам об этом писал выше. У вас в статьях этого нет, есть обобщение на всех.
Вы видимо мало что слышали о современных подходах к разработке и тестированию: Scrum, XP, Kanban. Я уже не говорю про Lean философию и Agile принципы в целом.
У вас недостаточно информации, чтобы делать такие выводы. Не говоря уже о том, что этому вашему скраму, только под другими названиями уже лет 40 как минимум. Просто если его называть спиральной разработкой, а скрам-митинги — утренними «планерками» и «пятиминутками», как это делал мой папа, когда работал в КБ, то продать тренерские услуги гораздо сложнее.
Отдельное спасибо за «деформацию мышления» и сомнения в моих обучающих способностях, в которых вы не имели возможности убедиться лично.
Я не знаю ничего о ваших обучающих способностях, но меня, как преподавателя, напрягает некоторая несистемность и отсутствие четкой терминологии. «Внедрять качество», да.
Я ни с кем никогда не начинаю мериться. Тут просто некоторые товарищи, включая вас, любят переходить на личности. Вы многократно подчеркнули, что вы преподаватель, что в моей статье полно бреда, булшита, несистемности, отсутствия четкой терминологии… Очень напоминает вот это:
Ни в коей мере. Я вам привел множество конкретных примеров и конкретных определений. И попытался объяснить что именно я называю буллшитом и где у вас ошибки в терминологии.
А вы уже честно говоря, сами путаетесь в своих утверждениях (в тойоте нет контроля качества, да ;) ), и апеллируете к проектам о которых вы не можете рассказывать из-за NDA. Ну ок, ваше право.
На мою манеру речи не обращайте внимания, считаю, что такая неформальность вполне допустима на айтишном ресурсе.
За картинку спасибо, сохранил к себе ;)
А вы уже честно говоря, сами путаетесь в своих утверждениях (в тойоте нет контроля качества, да ;) ), и апеллируете к проектам о которых вы не можете рассказывать из-за NDA. Ну ок, ваше право.
На мою манеру речи не обращайте внимания, считаю, что такая неформальность вполне допустима на айтишном ресурсе.
За картинку спасибо, сохранил к себе ;)
По поводу Тойоты я вам ответил в следующем же комментарии с примером из разработки. Нарушать NDA из-за трололо не вижу никакого смысла. Таких проектов полно и можете посмотреть публичные доклады как там все делается (примеры я приводил в самых первых комментариях, видео есть на InfoQ).
У меня к вам небольшая просьба — перестаньте себя вести будто Agile, Scrum, XP-практики — это какое-то тайное знание, которое доступно только вам и вы героически пришли на хабр нас этому обучать. Тут весьма много людей, которые все это внедряли, испытывали в работе в разных ситуациях, модифицировали под себя, от чего отказывались потому что что-то не работало, а что-то другое работало лучше.
Еще раз повторю одну из своих простых мыслей — проектов много, они все разные, у каждоего есть своя конкретная специфика и для каждого работает что-то свое. Грести всех под одну гребенку выгодно только если вы срам-тренер, чтобы продавать свои услуги.
Еще раз повторю одну из своих простых мыслей — проектов много, они все разные, у каждоего есть своя конкретная специфика и для каждого работает что-то свое. Грести всех под одну гребенку выгодно только если вы срам-тренер, чтобы продавать свои услуги.
Ой. А вы ведь действительно скрам-тренер ;)))) Это многое объясняет.
К пример, разберем это многострадальное «внедрять качество».
Качество, как мы уже выяснили, это оценка того насколько хорошо продукт выполняет возложенные на него функции. В теории информационных систем оно рассматривается как сумма коэффициентов степени соответствия ее спецификациям (кол-во багов если по другому), степени эффективности работы операторов/пользователей, стоимости поддержки, экономии за счет улучшения процесса после ее внедрения и тому подобное с множителями.
Я вот не понимаю как и куда можно внедрять эту величину. Я знаю как внедрять методики ее оценки и как внедрять инженерные практики, которые могут ее поднять. А могут и опустить, все зависит от конкретного проекта.
Качество, как мы уже выяснили, это оценка того насколько хорошо продукт выполняет возложенные на него функции. В теории информационных систем оно рассматривается как сумма коэффициентов степени соответствия ее спецификациям (кол-во багов если по другому), степени эффективности работы операторов/пользователей, стоимости поддержки, экономии за счет улучшения процесса после ее внедрения и тому подобное с множителями.
Я вот не понимаю как и куда можно внедрять эту величину. Я знаю как внедрять методики ее оценки и как внедрять инженерные практики, которые могут ее поднять. А могут и опустить, все зависит от конкретного проекта.
Мы говорим не о «теории информационных систем», а о практической действительности. Вы намешали в единую кучу и бизнес метрики и метрики процесса разработки. Количество багов никак не меряет степень соответствия спецификациям, которых во многих проектах формально и нет. «Как же тогда контролировать качество?» — воскликните вы. «Ведь в теории информационных систем и втором томе описания RUP четко сказано...». Так вот в жизни все гораздо проще. Продукт разбивают на инкременты и делают их итеративно. Качество контролируется после сдачи каждой итерации. Также в виде автоматизированных тестов или примеров поведения (в BDD) фиксируется, что на тот момент считалось качественным. После этого качество контролируется самостоятельно запуском этих тестов.
Если бы вы знали базовую теорию, вы бы прекрасно видели откуда растут ноги и у эджайла вообще, и у конкретно скрама. Вы же прочтя несколько поверхностных книжек, объявляете все остальное устаревшим, даже не зная что там написано.
И это очень смешно выглядит, именно потому что все это было и раньше, только описывалось системно, с моделями и доказательствами. И только потом появились скрам-тренера, которые ввели новую терминологию и начали продавать это в более доступном виде, только очень и очень поверхностно и выдавая за что-то новое.
А вы из этого поверхностного взгляда начинаете делать выводы. Это и есть несистемность, одна из очень больших проблем современности.
Банальной неустаревающей ТАУ у инженеров или теории управления у менеджеров достаточно, чтобы понимать откуда взялся тот же скрам и как на самом деле влияют на метрики проекта и автоматизация, и скрам-митинги и планнинг покер.
И это очень смешно выглядит, именно потому что все это было и раньше, только описывалось системно, с моделями и доказательствами. И только потом появились скрам-тренера, которые ввели новую терминологию и начали продавать это в более доступном виде, только очень и очень поверхностно и выдавая за что-то новое.
А вы из этого поверхностного взгляда начинаете делать выводы. Это и есть несистемность, одна из очень больших проблем современности.
Банальной неустаревающей ТАУ у инженеров или теории управления у менеджеров достаточно, чтобы понимать откуда взялся тот же скрам и как на самом деле влияют на метрики проекта и автоматизация, и скрам-митинги и планнинг покер.
Ваше маленькое эго не дает вам покоя. Вы точно знаете какие книжки и сколько я прочитал, что я — один из никчемных скрам тренеришек, которые жизни то и не видели, зарабатывая на краюху хлеба обманом и мошенничеством, что системности во мне нет и не будет… Если очень хотите помериться, то можете отписаться мне в скайп или на почту. Обсудим и прочитанные книжки и опыт и образование.
Не выдумывайте, такого я вам не писал. Меряться я с вами не собирался и не собираюсь, рассказывать про свои крутые проекты начали вы, я про себя нигде ничего не писал, кроме того не считаю свой опыт сильно большим, хотя большая часть того о чем я пишу взята именно из него, и что преподаю в техническом вузике.
Вас я никем никогда не обзывал, обсуждал только вашу же статью и ваши же комментарии. Если вы что-то слишком сильно принимаете на свой счет — ну значит действительно что-то задело и я где-то наткнулся на больное место. Полностью случайно, поверьте.
А вот вы уже скатились до прямых оскорблений. Слив засчитан ;)
Вас я никем никогда не обзывал, обсуждал только вашу же статью и ваши же комментарии. Если вы что-то слишком сильно принимаете на свой счет — ну значит действительно что-то задело и я где-то наткнулся на больное место. Полностью случайно, поверьте.
А вот вы уже скатились до прямых оскорблений. Слив засчитан ;)
Я сейчас умру от смеха. То есть «если бы вы знали базовую теорию», «прочтя несколько поверхностных книжек», «очень смешно выглядит», «выгодно только если вы срам-тренер, чтобы продавать свои услуги», «выглядит откровенно бредовой», «еще более бредово», «маркетинговый тренерский буллшит» и прочие ваши реплики — это вовсе не прямые оскорбления??? А меня вы совершенно не задели, я таких как вы встречаю пачками и переходить на грубости для меня просто не имеет смысла, иначе бы я только ходил и ругался. Продолжить в личном общении я предложил, потому что ваши доводы ходят по кругу и мы просто тратим понапрасну время на написание комментариев, которые никому не интересны…
retran, опишите, скрам с точки зрения банальной неустаревающей ТАУ или теории управления у менеджеров, или поделитесь ссылкой, если все уже где-то описано.
(без всякого сарказма, реально интересно увидеть взгляд на вопрос с такой стороны).
(без всякого сарказма, реально интересно увидеть взгляд на вопрос с такой стороны).
Введите метрики типа кол-во «несгоревших» сторипоинтов, введите обратную связь типа «возникновение новых требований», и рассматривайте скрам как переходный процесс от «ничего не сделано» до «проект выполнен». Ну и получите упрощенную модель процесса в виде фазовой траектории — спиральки стремящейся к нулю (концу проекта).
Картинка из интернета, кое-как иллюстрирующая то что должно получится:
Понятно, что на самом деле, переменных больше и каждая из них «едет» по своей траектории, но смоделировать вполне реально.
Примерно та же идея описания процессов, только другими словами озвучена у ДеМарко в Deadline.
Картинка из интернета, кое-как иллюстрирующая то что должно получится:
Понятно, что на самом деле, переменных больше и каждая из них «едет» по своей траектории, но смоделировать вполне реально.
Примерно та же идея описания процессов, только другими словами озвучена у ДеМарко в Deadline.
возможно я вас не правильно понял, или вы говорите не теми картинками, но как-то не получается представить скрам в виде переходного процесса, т.е. — реакции ОУ на воздействие. да и адепты его называют, не процессом, а методологией.
попробуйте начать с базовых определений банальной неустаревающей ТАУ: что есть объект управления, каковы его характеристики и особенности, и каковы цели процесса управления? какую роль играет скрам — расскажите, каково назначение, принципы управления, критерии, требования, ограничения и т.п.
попробуйте начать с базовых определений банальной неустаревающей ТАУ: что есть объект управления, каковы его характеристики и особенности, и каковы цели процесса управления? какую роль играет скрам — расскажите, каково назначение, принципы управления, критерии, требования, ограничения и т.п.
человек, который делает продукт, человек, который оценивает качество и человек, который контролирует качество не могут быть одним и тем же человеком.
Всё зависит от мотивации, по-моему. Если человек искренне хочет, чтобы продукт был качественным, то вполне может оценивать и контролировать качество сам, абстрагируясь от своего участия в других ролях. И как раз автоматические или автоматизированные средства оценки и контроля очень помогают абстрагироваться. Настроил, скажем, автоматическую проверку стиля кода и прогон автотестов на прекоммит- или премерж-хук (оценка), задал условие, не позволяющие закоомитить код, не соответствующий стилю и со сбойными тестами (контроль) и всё. Сам сделал продукт, сам оценил его качество, сам его проконтролировал.
Другое дело, насколько его метрики и методики оценки совпадают с таковыми у заказчика и пользователей. Но это уже чисто вопрос компетенции.
Ну, ведь Мариванна очень болеет за дело. И у нее сердце кровью обливается, когда она видит, что Вовочке надо ставить двойку и все-таки натягивает тройку (он же хороший мальчик, а сопьется без троечки).
Конфликт интересов производителя и контролера он объективно существует и он нормален. Получающиеся компромиссы двигают производство и совершенно не надо их убирать
Конфликт интересов производителя и контролера он объективно существует и он нормален. Получающиеся компромиссы двигают производство и совершенно не надо их убирать
Другое дело, насколько его метрики и методики оценки совпадают с таковыми у заказчика и пользователей
это очень даже важное дело — появление доморощенных критериев и локальные оптимизации, которые не согласованны с метриками проекта, нужно всячески пресекать.
дополнительный самоконтроль потребует дополнительное время и ресурсы, а значит такая самодеятельность чревата увеличением стоимости разработки и срывами сроков. я не в смысле «хорошо» это или «плохо», но такие решения должны согласовываться на уровне проекта, а не приниматься локально.
Боже, какая чушь. Становится страшно от количества «скрама в голове».
«Testing is dead» было основным трололо англоязычных конференций в позапрошлом году, а надо же, до сих пор срабатывает.
>Вся их работа упирается в то, что изначальная работа разработчиков сделана некачественно.
Вот это очень важная для всего следующего ниже посылка, но она в корне неверная. Качество работы программиста не определяется наличием или отсутствием в его коде дефектов. Более слабый программист чаще будет делать глупые ошибки в простых вещах, но расширять эту корреляцию дальше нельзя. Это было сказано, кажется, ещё до того, как вообще придумали отдельного человека — тестировщика ПО, и что-то я не слышал, чтобы это опровергли. Вы же сами говорите, что в действительности того гипотетического диалога с заказчиком не бывает.
Вот это очень важная для всего следующего ниже посылка, но она в корне неверная. Качество работы программиста не определяется наличием или отсутствием в его коде дефектов. Более слабый программист чаще будет делать глупые ошибки в простых вещах, но расширять эту корреляцию дальше нельзя. Это было сказано, кажется, ещё до того, как вообще придумали отдельного человека — тестировщика ПО, и что-то я не слышал, чтобы это опровергли. Вы же сами говорите, что в действительности того гипотетического диалога с заказчиком не бывает.
Поясните на примере: «Качество работы программиста не определяется наличием или отсутствием в его коде дефектов.» Для меня ваша фраза означает, что хоть программист и делает кучу дефектов и тут и там, его работа по-прежнему может считаться качественной. Может дадите ссылку на то, где это было сказано?
Диалога с заказчиком не бывает по причине того, что тогда ни один заказчик бы не работал с вашей компанией.
Диалога с заказчиком не бывает по причине того, что тогда ни один заказчик бы не работал с вашей компанией.
>Для меня ваша фраза означает, что хоть программист и делает кучу дефектов и тут и там, его работа по-прежнему может считаться качественной.
Я так понимаю, вы считаете это абсурдным? Почему?
Критерием качества продукта(причем, если над проектом работает команда, то качество продукта напрямую так просто не транслировать в качество работы каждого конкретного её члена) является наличие дефектов в финальном билде. В промежуточном их может быть сколько угодно, с качеством финального продукта это никак не коррелирует. Вопрос с метриками качества работы программиста сложный, мне неизвестен «правильный» ответ на него, но хорошо известно, что измерять его дефектами такая же ерунда, как и измерять строками написанного кода производительность.
Это настолько общее место, что я теряюсь, какие тут можно дать ссылки. Вторая глава классической книги Канера, Фолка и Нгуена? Она скорее о невозможности полного тестирования. И Art of Software Testing из далекого 1979 года туда же. Цитата Дийкстры «If debugging is the process of removing bugs, then programming must be the process of putting them in?» Так это про дебаггинг. Вот тут, например, этот вопрос обсуждали — так закрыли тему за неконструктивность: programmers.stackexchange.com/questions/41248/how-to-be-a-zero-bug-programmer Здесь рядом тоже люди об этом говорят: habrahabr.ru/post/149240/
В общем, много можно копать. Доказывать общие места дело неблагодарное А вот какая методология советует измерять качество работы числом багов? Такие есть? Они эффективны?
Можно также привести примеры и придумать аналогии для иллюстрации. Программист написал код строго по спецификации, но с железом (его делала 3rd party) код работает неправильно — в спецификации не указано, Little Endian или Big Endian должен быть использован и используются разные. Программист виноват? Программа с целью экономии памяти/реюза компонентов/ещё чего-то позволяет имена файлов не более 11 символов. Программист непрофессионален из-за того, что не реализовал современную фичу? А из-за того, что забыл посчитать точку в MS-DOS формате? Отвечает ли писатель за то, правильно ли расставлены переносы в его книге? А за орфографические ошибки? Ну, вы знаете, хорошие писатели — они же, по идее, весьма образованные люди, должны писать без ошибок?
Я так понимаю, вы считаете это абсурдным? Почему?
Критерием качества продукта(причем, если над проектом работает команда, то качество продукта напрямую так просто не транслировать в качество работы каждого конкретного её члена) является наличие дефектов в финальном билде. В промежуточном их может быть сколько угодно, с качеством финального продукта это никак не коррелирует. Вопрос с метриками качества работы программиста сложный, мне неизвестен «правильный» ответ на него, но хорошо известно, что измерять его дефектами такая же ерунда, как и измерять строками написанного кода производительность.
Это настолько общее место, что я теряюсь, какие тут можно дать ссылки. Вторая глава классической книги Канера, Фолка и Нгуена? Она скорее о невозможности полного тестирования. И Art of Software Testing из далекого 1979 года туда же. Цитата Дийкстры «If debugging is the process of removing bugs, then programming must be the process of putting them in?» Так это про дебаггинг. Вот тут, например, этот вопрос обсуждали — так закрыли тему за неконструктивность: programmers.stackexchange.com/questions/41248/how-to-be-a-zero-bug-programmer Здесь рядом тоже люди об этом говорят: habrahabr.ru/post/149240/
В общем, много можно копать. Доказывать общие места дело неблагодарное А вот какая методология советует измерять качество работы числом багов? Такие есть? Они эффективны?
Можно также привести примеры и придумать аналогии для иллюстрации. Программист написал код строго по спецификации, но с железом (его делала 3rd party) код работает неправильно — в спецификации не указано, Little Endian или Big Endian должен быть использован и используются разные. Программист виноват? Программа с целью экономии памяти/реюза компонентов/ещё чего-то позволяет имена файлов не более 11 символов. Программист непрофессионален из-за того, что не реализовал современную фичу? А из-за того, что забыл посчитать точку в MS-DOS формате? Отвечает ли писатель за то, правильно ли расставлены переносы в его книге? А за орфографические ошибки? Ну, вы знаете, хорошие писатели — они же, по идее, весьма образованные люди, должны писать без ошибок?
Да я считаю это абсурдным. В современном мире все реже и реже есть понятие конечного продукта. Большая часть на современном рынке — сервисы, которые постоянно обновляются новыми фичами. Поэтому одна из метрик качества продукта в данном случае — количество дефектов, которые дошли до конечных пользователей. Да, вы правы, что эта метрика характеризует работу всей команды, а не только программистов. По неверным требованиям очень тяжело разработать правильное решение. Но NullPointerException и иже с ним я думаю вы не станете относить к проблеме с требованиями. :)
Классические книги, которые вы привели, писались для IT того времени. Я ни в коем случае не говорю, что они неверны в корне. Все что касается людей осталось практически без изменений. А вот процессы, практики и подходы шагнули далеко вперед, так же как и требования к IT проектам. Поэтому приводить доводы из этих книг немного некорректно.
А в вашем примере про Little Endian или Big Endian программист виноват в том, что не задал вопрос, а реализовал как ему показалось правильным. Если бы все на своих рабочих местах делали так как им лично кажется, то был бы полный беспредел везде. В примере с количеством символов программист снова неправ, потому что возможно об этой оптимизации никто не просил и уж тем более не догадывался. А если просил, то программист должен был донести ограничения, которые накладываются его реализацией.
А теперь о писателях. Неверно утверждение о том, что все писатели — образованные люди. И чем ближе к современности, тем более неверно это утверждение. Раньше так было, во времена Пушкина и Лермонтова. Никто не подрабатывал у них редактором. А теперь пишут домохозяйки, лифтеры, полицейские, так что кто во что горазд… :)
Классические книги, которые вы привели, писались для IT того времени. Я ни в коем случае не говорю, что они неверны в корне. Все что касается людей осталось практически без изменений. А вот процессы, практики и подходы шагнули далеко вперед, так же как и требования к IT проектам. Поэтому приводить доводы из этих книг немного некорректно.
А в вашем примере про Little Endian или Big Endian программист виноват в том, что не задал вопрос, а реализовал как ему показалось правильным. Если бы все на своих рабочих местах делали так как им лично кажется, то был бы полный беспредел везде. В примере с количеством символов программист снова неправ, потому что возможно об этой оптимизации никто не просил и уж тем более не догадывался. А если просил, то программист должен был донести ограничения, которые накладываются его реализацией.
А теперь о писателях. Неверно утверждение о том, что все писатели — образованные люди. И чем ближе к современности, тем более неверно это утверждение. Раньше так было, во времена Пушкина и Лермонтова. Никто не подрабатывал у них редактором. А теперь пишут домохозяйки, лифтеры, полицейские, так что кто во что горазд… :)
А теперь пишут домохозяйки, лифтеры, полицейские, так что кто во что горазд… :)
… про скрам, аджайл, *DD и т.п. «инновации», отвергая фундаментальные знания. В этом я с вами соглашусь полностью! :)
программист виноват в том, что не задал вопрос, а реализовал как ему показалось правильным. Если бы все на своих рабочих местах делали так как им лично кажется, то был бы полный беспредел вездепо-вашему, получается, что программист виноват в том, что он программирует. нет, в самом деле, если бы все на своих рабочих местах задавали вопросы, то ни кто бы не программировал, а все бы задавали вопросы.
Ага, лучше программировать что в голову взбредет. Вы же гораздо лучше понимаете пользователей, бизнес и нужны заказчика. Никаких вопросов, только код!
Если программисту приходится задавать слишком много вопросов по бизнесу — значит это ошибка аналитика-продактоунера. Если технических — значит тимлида/ведущего раработчика/архитектора. Или кто там берет на себя эту ответственность в «чистом скраме». Только не говорите, что в скраме «все равны», на более менее сложном проекте все равно выделиться разработчик с наиболее высоким авторитетом.
Вопрос авторитета относится к лидерству, а не к техническим вопросам. У вас может быть в команде лидером совсем не самый опытный и технически подкованный. А за архитектуру и дизайн отвечает вся команда, все решения принимаются сообща. Тогда всем комфортно жить с такой архитектурой, а также учтен опыт каждого члена команды. А в скраме на эту тему ничего не говорится — учите матчасть.
Команда в Scrum кроссфункциональна. В нее входят люди с дополняющими навыками разработчики, аналитики, тестировщики. Нет заранее определенных и поделенных ролей в команде, ограничивающих область действий членов команды. Команда состоит из инженеров, которые вносят свой вклад в общий успех проекта в соответствии со своими способностями и проектной необходимостью.
Отсюда — scrumtrek.ru/scrum/Scrum-team/
А за архитектуру и дизайн отвечает вся команда, все решения принимаются сообща.
А теперь смотрим, например сюда:
ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0_%D0%BA%D0%BE%D0%BC%D0%B8%D1%82%D0%B5%D1%82%D0%BE%D0%BC
Учите матчасть.
Лидерство тут ни причем, это чисто техническая компетенция. В отсутствии назначенного человека, выделяется сам — в силу обыкновенной человеческой психологии.
С вами очень сложно общаться: сначала вы говорите «Если технических — значит тимлида/ведущего раработчика/архитектора. Или кто там берет на себя эту ответственность в «чистом скраме».», а потом приводите мне в качестве «чистого скрама» ссылку на ScrumTrek, в которой также говорится о общей ответственности команды как в моем вам ответе. По вашему они придумали и описали Scrum? Прочитайте первые книги по скраму от Швабера и Сазерленда. Там ни слова о технической части вообще! Вы понахватались знаний по крупице ото всюду и мните себя экспертом.
А про вторую ссылку я вообще молчу. Я больше не буду с вами спорить — живите в мире Википедии и считайте себя экспертом и дальше. Жаль что вы учите кого-то в университете…
А про вторую ссылку я вообще молчу. Я больше не буду с вами спорить — живите в мире Википедии и считайте себя экспертом и дальше. Жаль что вы учите кого-то в университете…
Под «чистым скрамом» здесь понимается представление о скраме у россиянских скрам-мастеров. Именно то самое, которое вы декларируете. Именно поэтому «чистый скрам» написан в кавычках.
С результатом «Design by committee» я борюсь прям сейчас в большом и сложном проекте, и почитать про это вы можете очень много где.
Да, лучше не спорьте ;)
С результатом «Design by committee» я борюсь прям сейчас в большом и сложном проекте, и почитать про это вы можете очень много где.
Да, лучше не спорьте ;)
хоть программист и делает кучу дефектов и тут и там, его работа по-прежнему может считаться качественной.
в этом нет ничего удивительного, просто работа это процесс, а продукт это результат — и в каждом случае будут разные оценочные критерии, и соответственно свои «хорошо» или «плохо».
качество работы разработчика вы можете оценивать по степени вовлеченности, напряженности, безопасности, устойчивости, времени (не путать со сроками), наконец — т.е. по тому, _как_ он работает. оценивать качество результата — по соответствию техническим спецификациям, нормам и т.д.
но все это фигня, если вам нужно не оценивать, а контролировать и управлять — потому, что тут требуются количественные характеристики, которые можно измерять и сравнивать.
При чем тут активности, которые вы привели? Ими тяжело оценивать качество работы программиста. Я вам предложил реальную метрику — количество дефектов, которые дошли до конечных пользователей. Причем именно дефектов, то есть те задачи, которые описаны в требованиях и были обсуждены, в итоге реализовали неверно. Вторая метрика — количество value, которое разработчик может приносить проекту при зафиксированной метрике качества. Может измеряться в количестве стори поинтов, функциональных единиц, денег, реализованных фичей и т.д. Тогда получается все просто — если вы можете делать быстрее задачи на том же уровне качества, то для этого проекта вы более крутой программист. Дальше вступают командные метрики (вы можете писать код, который решает задачу, но тормозит всех остальных), но это отдельная история…
тяжело, говорите? мифический ПМ тупо переложил ответственность за качество продукта с себя на разработчиков — ура, тестировщики нам больше не нужны (развивайте мысль дальше — аналитики, проектировщики, маркетологи, ...). при таком раскладе уже ни какие метрики не принципиальны — можно делать стори поинты, функциональные единицы, фичи, деньги или в чем там еще из меряется value, не доводить дефекты до конечных пользователей — легко. :P
так в чем подвох? думаю, и сами знаете: мифический ПМ, который ни за что не отвечает — не нужен. волшебный пендель от начальства / заказчика за продуктовый деффект, быстро вернет ПМа из мифа в реальность, где контролировать качество ему так-и приходится. а тестирование это один из инструментов, дающий ПМу метрики, необходимые для быстрой обратной связи. очень удобная штука — с ним КК дается гораздо легче. мм… все имхо, разумеется.
зы: может через пару лет напишите опровержение, типа «жизнь без тестировщиков: как нажить геморрой на свою голову». :)
так в чем подвох? думаю, и сами знаете: мифический ПМ, который ни за что не отвечает — не нужен. волшебный пендель от начальства / заказчика за продуктовый деффект, быстро вернет ПМа из мифа в реальность, где контролировать качество ему так-и приходится. а тестирование это один из инструментов, дающий ПМу метрики, необходимые для быстрой обратной связи. очень удобная штука — с ним КК дается гораздо легче. мм… все имхо, разумеется.
зы: может через пару лет напишите опровержение, типа «жизнь без тестировщиков: как нажить геморрой на свою голову». :)
Открою вам страшную тайну: если у вас адекватная команда и есть опытный техлид, то вам не нужен ПМ в принципе. В Agile подходах такая роль не выделяется и совершенно правильно. ПМ может быть хоть один на 5 проектов решать задачи из разряда работы с людьми, железом, зарплатами и т.д. За качество и выпуск самого продукта отвечает команда! Опровержение я не напишу, потому что уже 3 года работаю по такой схеме и знаю еще много команд, которые работают так же. А если у вас на проекте ПМ с плетью и метриками от тестировщиков ходит давать волшебного пендаля программистам, чтобы качество продукта ну хоть как-то соответствовало ожиданиям заказчика, то мне вам остается только посочувствовать…
В вашем случае роли ПМа и техлида просто объединены. Ну не ПМу дают пендели, а техлиду, смысла комментария funca это не меняет.
мм… кажется начинаю вас понимать. с десятого раза, но спасибо за терпение и настойчивость.
За качество и выпуск самого продукта отвечает команда!в смысле — юридически (кто является исполнителем, с которым заказчик заключает договор, и что, в общих чертах, представляет собой предмет такого договора)?
Мы не говорим о юридической ответственности. Ее несет компания подрядчик и договор заключается от ее имени. А вот уровень доверия и официальной ответственности внутри компании — это уже дело самой компании. Кто-то пытается формализовать эти отношения, кто-то надеется на сознательность и мотивацию членов команды.
я так понял, команда несет внутреннюю ответственность за качество. а кто определяет сроки и бюджет проекта, и кто потом отвечает за них?
решение об не-использовании тестировщиков все-таки было принято ПМ (который отвечает за людей и зарплату), а не командой?
решение об не-использовании тестировщиков все-таки было принято ПМ (который отвечает за людей и зарплату), а не командой?
Сроки и бюджеты определяет заказчик, исходя из оценок предстоящей работы командой. Если команды еще нет, то тогда менеджмент компании-подрядчика магическими формулами пытается сэмулировать ее наличие. А отвечать за глобальные сроки и бюджет почти нереально — по предсказаниям «пальцем в небо» даны оценки и потом куча всего меняется. Поэтому и работают короткими итерациями, чтобы риски снизить. И вот тогда на каждой итерации команда отвечает за свои обещения по выполнению работ.
Решение было принято командой. Просто начали без тестировщиков и не увидели в них сильной необходимости в процессе работы. Все довольны, зачем что-то менять…
Решение было принято командой. Просто начали без тестировщиков и не увидели в них сильной необходимости в процессе работы. Все довольны, зачем что-то менять…
Sign up to leave a comment.
Жизнь без тестировщиков: миф или реальность?