Спецвыпуск 9 3/4: День программиста

Итак, историческая битва встреча тестировщиков с программистами состоялась! Мы впервые встретились в прямом эфире, чтобы померяться инсайтами на тему роли тестирования в разработке ПО.

При записи выпуска тестировщики и программисты не пострадали, а только приобрели!

 

В выпуске мы обсудили следующие вопросы:

  • знакомство и являются ли тестировщики разработчиками?
  • как у вас на работе организованы QA  — нет совсем / отдельный отдел / работают все вместе в одной комнате ?
  • почему программисты ненавидят QA? Что их раздражает в QA? Антагонизм QA и программистов.
  • каких QA любят программисты? Хорошие черты тестировщиков и программистов
  • каких QA боятся? А чего боятся QA?

Уважаемые слушатели, ответьте пожалуйста на 2 простых вопроса к этому выпуску:

Вы кто?
Являются ли тестировщики разработчиками?

С нами были:

Разбор Полетов — Барух Садогурский (@jbaruch, Купертино, Израиль/США)
RadioJS и SDCast — Константин Буркалёв (@KSDaemon, Москва, Россия)
DevZen — Светлана Божко (@SBozhko, Минск, Беларусь)
DevOps Дефлопе — Никита Борзых (@ex_sample, Москва, Россия)

Ведущий выпуска, представляющий сторону тестировщиков:
Radio QA  — Алексей Виноградов (@vinogradoff, Дормаген,Германия)

Программисты и тестировщики всех стран — мир, труд, continious integration!

  • Andrei Solntsev

    Привет!
    Не могу молчать! Барух и Света озвучили мысль о том, что юнит-тесты надо давать писать другим людям, да ещё и начинающим. Бесспорно, для этих начинающих это полезное упражнение. Но это очень вредно для кода! Весь смысл TDD в том, что разработка ведётся ЧЕРЕЗ тестирование. TDD — это способ разработки. Когда пишешь код ДО теста, продумываешь дизайн, удобство использования, заранее примечаешь вероятные ошибки и всё такое. Код делается легко тестируемым.

    А если сначала написать код и потом отдать его для написания юнит-тестов третьим людям, все эти минусы мгновенно пропадают.

    Мой совет — пусть юнит-тесты пишут сами разработчики (ДО кода), а начинающим давайте писать UI тесты. Вот это действительно классное упражнения для ознакомления с системой.

    • maksya

      С юнит-тестами можно жить и без TDD. Полагаю, мысль Баруха и Светы звучала именно в этом контексте. Всякие xDD были вынесены за рамки данного подкаста.

      • Andrei Solntsev

        Можно. На MacBook можно тоже Windows установить.
        Только это плохая, ужасная, крайне неэффективная идея.

        P.S. Кстати, с Windows тоже идея не очень.

        • maksya

          До появления TDD юнит-тесты писали ёжики? плакали, кололись, но продолжали писать?.. плохо, ужасно и крайне неэффективно?
          Кроме того, что же делать проектам, которые ведут разработку без TDD и сейчас? Запретить писать юнит-тесты?

          • Andrei Solntsev

            Ну, в мире есть ещё миллиарды людей, которые делают вещи неэффективно. Что теперь им всем делать? Это, знаете, филисофский вопрос.

        • Я не соглашусь тоже 🙂

          В некотором, даже не абстрактном контексте установить на MacBook Windows может быть замечательной, и главное эффективной идеей.

          Например у тебя есть свободный MacBook, у тебя есть опытный Windows разработчик. И времени на проект столько, что переучивать разработчика неэффективно. Тогда установить Windows и начать работать — вполне себе отличная идея.

          В переводе на язык программистов — использовать Subversion (хотя GIT в целом эффективнее), Ant (вместо Maven & Co.)

          TDD — доступен некоторым, (как Maven, Git, Mac OS X) — которые становятся необычайно эффективными с ним. Но есть много очень эффективных значительно выше среднестатистического уровня программистов, которым не нравится TDD, и тем не менее они справляются со своими задачами на 5!

          Во главу я ставлю, не технологию, а человека и его способности.

          • Andrei Solntsev

            Алексей, конечно, иногда можно и Windows на MacBook поставить.

            Иногда.

            ИНОГДА, Карл!

          • Andrei Solntsev

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

            Оно, конечно, верно, что во главе человек. Но это не отменяет того факта, что некоторые инструменты лучше, а некоторые хуже. Бухгалтеры, которые продолжали сидеть на счётах и не хотели переходить на компьютеры — тоже сплошь хорошие и способные люди были.

          • maksya

            Несколько фанатично. Не находишь? Ты только что поделил всё человечество на две группы: те кто использует TDD в разработке ПО и те кто на самом деле его не знают. С таким подходом тебе так и не удастся встретиться с теми кто понимает TDD, но не использует.
            Всё равно что пихать невпихуемый Scrum в каждый процесс разработки, touchscreen в каждый телефон и т.п.

          • Andrei Solntsev

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

            Ну нет, при чём Scrum. Если я знаю, что Kanban эффективнее Scrum, что плохого в том, что я всем расскажу и подробно расскажу, почему и засчёт чего он эффективнее.

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

          • maksya

            Да нет же. Эффективность того или иного инструмента не может оцениваться в отрыве от контекста. Демократия — хорошо, но попытка внедрить ее в современном Ливане или детсадовкой группе обречена на провал. То же справедливо и для Kanban’а и для TDD и вообще для любой системы. Не бывает лучших решений! Любая система имеет сильные и слабые стороны, в разной степени проявляющиеся в разных контекстах.

            Хотите встретиться с теми, кто знает суть TDD, но способен при определенных обстоятельствах отказаться от внедрения это технологии? Нет ничего проще. Посмотрите в зеркало =) Сформулируйте минусы TDD, тем самым только усилите свои позиции. Hint — загляните в историю становления TDD, когда и для решения каких задач и проблем оно появилось?

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

            Например, бытует утверждение, что разработка через тестирование идёт в общем случае медленнее. Она, конечно, оправданно медленнее — есть основания полагать, что лучше сейчас немного потерять в скорости, но зато потом обрести в качестве. Но минус «медленнее» от этого не становится положительней. Давайте относиться к нему объективно. Вполне допустим контекст когда потеря в скорости разработки здесь и сейчас будет роковой для продукта.

            Другой минус, который я как тестировщик воспринимаю особенно болезненно =) — это иллюзия того, что тестирования, лежащего в основе разработки TDD, достаточно. Следовательно тратиться на другое тестирование нет нужды.

            К плюсам я бы отнес фокус на тестируемости (testability) кода. Хотя, мне сложно оценить действительно ли эта сторона TDD преобладает над тестируемостью при обычной разработке. И отдельный вопрос — есть ли технологии, ведущие к бОльшей тестируемости кода?

            И, наконец, главное — то, что уже Лёша обозначил до меня — люди, склад ума. По этой причине из настоящего тестировщика не получается сделать настоящего программиста и наоборот. Осведомленность людей в технологии, к сожалению или к счастью, не является определяющей для эффективности применения. По этому поводу на QA Help недавно попадался репост статьи с хабра = «Healthcare IT: или как выкинуть $34 млн». И вроде инструменты хорошие сделали и тренинги провели, а врачи всё= работают медленнее чем раньше. Конечно и тут можно сказать что либо инструменты — говно, либо врачи тупые или без желания учиться новому.. Но кого мы обманываем при этом?

          • Andrei Solntsev

            Вот! Об этом я и говорю: люди рассуждают о TDD, не имея опыта. Само по себе совсем не плохо думать, узнавать, рассуждать, обсуждать. Плохо, когда таким образом принимаются решения. «Мы не будем использовать TDD, потому что это оно медленнее» — без всякого опыта в TDD. Вот это плохо.

            Пару слов об упомянутых минусах TDD:

            1. Нет, разработка через тесты НЕ медленнее. Если рассматривать весь процесс разработки целиком (т.е. разработка+деплой+тестирование+багфикс), то в сумме этот процесс будет быстрее через TDD. Здесь была об этом речь: https://www.youtube.com/watch?v=8u6_hctdhqI

            2. «это иллюзия того, что тестирования, лежащего в основе разработки TDD, достаточно» — ни у кого нет такой иллюзии. Ну где вы видели, чтобы руководство какой-то фирмы так считало?

            3. Безусловно, фокус при TDD ещё какой. Только не совсем на тестируемости, а на удобности использования и простоте (минимулизме) кода. А тестирумость скорее получается как неизбежный эффект.

            4. Да, конечно, есть технологии, ведущие к бОльшей тестируемости кода — например, Dependency Injection. Но как обычно, их надо применять с умом и через TDD, иначе эти технологии могут и убить.

          • maksya

            Я и не сомневался в том, что у опытного программиста найдется обоснованная аргументация в пользу TDD. С интересом ознакомлюсь с ними. Вместе с тем я надеялся, что у опытного программиста найдутся и аргументы против. Еще раз — это базовое правило всех открытых систем. На что ни плюнь — у всего есть достатки и недостоинства.

            Возьмем пресловутый Scrum. Мне искрене импонирует теория этого фрэймворка. Без сарказма. Могу долго высказываться по поводу его сильных сторон. Но факт остается фактом — на практике он почти не работает, везде сплошные скрамбаты. Не потому что люди тупые и не потому что Scrum плохой. А потому что есть человеческий фактор. И как опытный участник этого процесса я назову и top-10 слабых сторон Scrum’а. И знаю что есть контексты, в которых Scrum будет во вред. Поэтому если меня как скрам мастера пригласят в новый проект настраивать процесс, я буду первым кто скажет «нет» если станет понятно что лучше задействовать другую организацию труда.

            По поводу комментариев к минусам TDD. Кстати, там в первом слайде видео ошибка — «встреча 05.10.2015» (для истории — сегодня 18.09), ожидаемо 05.02.2015.. или месяц двоичным кодом? =) Ну это ладно. На это, — «ни у кого нет такой иллюзии. Ну где вы видели, чтобы руководство какой-то фирмы так считало?» у меня, благодаря видео, есть досрочный ответ — это фирма Codeborne. Цитирую дословно: «мы фанаты extreme programming’а.. т.е. мы пишем и код и тесты и всякое такое.. в коротких итерациях, все знаете вот этот вот agile. Одним словом — в нашей фирме нет тестировщиков, у нас есть только разработчики, которые делают всё»

            Предлагаю на этом поставить паузу и продолжить в выпуске, посвященном TDD, BDD и прочим способам помыкания разработкой. Хорошо бы к тому времени иметь результаты опроса на тему сколько проектов используют в своей работе TDD и динамику за последние 5 лет.

          • Andrei Solntsev

            Разумно.

            Одно маленькое замечание: в Codeborne нет иллюзии, что юнит-тестов достаточно. Во фразе «в нашей фирме нет тестировщиков, у нас есть только разработчики, которые делают всё» слова «делаю всё» означают буквально всё. То есть все необходимые виды тестирования.

    • jbaruch

      Согласен, UI тесты это лучший выбор, чем юнит.

  • Andrei Solntsev

    Ну и насчёт того, что примеры, на которых демонстрируется TDD, слишком простые (типа калькулятора). А у тебя доменная область и акторы.

    Вот тут доклад на эту тему «Real-life unit-tests». Там, надеюсь, станет понятнее. 🙂
    http://www.devclub.eu/2011/06/06/asolntsev-real-life-unit-tests/

    • Andrei Solntsev

      Кстати, будете в Питере 16-17 октября — заходите на конференцию Joker.

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

      http://jokerconf.com/talks/solncev_keks/

  • Pingback: Канадский геймдев — Episode 0059 « DevZen Podcast()

  • ajooluz

    Спасибо, получился интересный выпуск.
    Не хватало Ксюши из Радио-Т. Она вроде бы во времена студенчества имела опыт работы в саппорте/девопсе/тестировании. Возможно у нее нашлись бы интересные истории из практики тестирования и разработки.

  • Анонимус

    Спасибо за замечательный подкаст, но! можно что-нибудь сделать с нормализацией громкости участников? У ведущего ужасный микрофон (если он вообще был) и шум, так что звучит он тихо, в то время как всех гостей хорошая громкость и отчетливый звук. Для комфортного прослушивании в закрытых мониторных наушниках в общественном транспорте, нужно то повышать громкость, чтобы слушать ведущего, а потом понижать, чтобы не глохнуть от гостей. В итоге, надоело — остановился только на прослушивании гостей, ведущему нужен нормальный микрофон.

    • Sergey Atroschenkov

      Добрый день, спасибо за обратную связь.
      Мы работаем над качеством звука.

    • maksya

      И если есть лишний нормальный микрофон, с удовольствием примем в дар ведущему

  • Тата

    Как только тестировщих оформляет Improvement в bug-tracker он переходит в разряд разработчиков 🙂

    • Тестировщик является разработчиком изначально, так как выполняет важную функцию в процессе разработки ПО.