К основному контенту

Можно ли обойтись без тестировщиков? DataArt IT talk SPb - 2

Update: slideshare глючит, podfm со слайдкастом умер, запись в mp3 (качество не айс). Вот мое из свеженького на эту тему, чуть короче и буквами.

Слайды этого доклада можно посмотреть тут.

Состоялась вторая встреча DataArt IT talk SPb. 

Как получилось судить не мне, надеюсь, что участникам было интересно. Аудитория была процентов на 90 - как раз тестировщики :), говорить им о том, что они возможно не нужны было "забавно".

PS Это выступление было первым, надо еще тренироваться :) Мое "а-а-а-а-а" и "э-э-э-э" напрягает :( Ну и вопросы надо повторять, тороплюсь ответить.

Комментарии

  1. Спасибо Вам за выступление. Кажется, оно вдохновило меня и моего коллегу на подвиги :)
    Хотела задать вопрос: для проектов какого масштаба Вы считаете возможным обходиться без выделенных специалистов по тестированию и какие требования к организации процесса разработки считаете в данном случае обязательными.

    ОтветитьУдалить
  2. Спасибо за отзыв. Очень надеялся, что кого-нибудь зацепит :) По масштабам - если Ваш проект делает команда от 1 до 10 человек, то это Вам подойдет. Но это не значит, что 11-й должен быть уже тестировщик(и) :). Вообще сложно говорить о масштабах. Ваша команда может работать над компонентом большой системы, и этот компонент и есть Ваш проект. Думаю там Вы вольны сами выбирать, как Вы будете его реализовывать. Хотя конечно Фобосы запускать без тестировщиков не нужно :)
    По организации процесса: во-первых должны быть автотесты, без них это все теряет смысл. Применение Agile практик (без фанатизма) тоже если необязательно, то крайне желательно. Отлично если есть возможность описать user stories, супер если Ваш заказчик помогает Вам в этом. Описанные истории - это половина успеха. Вообще думаю это тема отдельного поста, спасибо за идею - обязательно подумаю, сформулирую и напишу.

    ОтветитьУдалить
  3. Спасибо за ответ :) Было бы очень интересно почитать.

    ОтветитьУдалить
  4. Максим, большое вам спасибо за доклад. Я был в числе тех 10% программистов, и я как раз коллега Алены, которого вы действительно вдохновили. Собственно на что вдохновили? На деятельность по повышению качества собственного кода через использование всякого рода тестирования, ну и на попытки помочь тестировщикам, чтобы не увольнять их :). Уж не знаю на сколько хватит энтузиазма, так как это будет инициатива снизу а не управленческая.

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

    Еще хотелось бы предложить вам тему "Можно ли обойтись без документации" :)
    Речь идет о различной документации в части разработки (проектирования архитектуры, отдельных модулей, классов и их взаимодействия etc).

    Спасибо еще раз, ждем новых докладов :)

    ОтветитьУдалить
  5. Спасибо за отзыв. Про книжки понял - сделаем. Насчет "документации" - можно обойтись без такого рода документации, хорошо написанные тесты и будут Вашей документацией. У нас кроме историй ничего и не было, и нет. Если такую документацию вести, ее постоянно надо поддерживать up-to-date, иначе время потраченное изначально вы можете заложить себе в убыток (=потраченное зря). Подробнее в отдельном посте (спасибо за наводку).
    TDD - отличный вопрос. У нас сейчас его нет и это ПЛОХО (см. мой пост про "10 причин..."). На прошлом проекте частично было. Будем и здесь стараться его внедрять. Коротко насчет времени: времени сначала тратиться чуть больше (поглощение теории, поиск инструментов, внедрение, просветление мозгов :), потом меньше - вы не тратите время на написание и тестирование того, что не нужно. Попытка писать тесты на уже написанный код плохо работает с модульным тестированием, так как код может быть написан "не для тестов". Кроме этого, такая практика (+ если это еще усугубляется ситуацией, когда тесты пишет другой разработчик, а не автор) это попытка догнать уходящий поезд - он постоянно уезжает.

    ОтветитьУдалить
    Ответы
    1. Я пытался практиковать TDD в своем проекте, заметил что на разработку фичи уходит сначала до 30% - 40% времени больше, с опытом это превращается в 10% - 20%. Но эффект от наличия тестов заметен - я просто более уверен в своем коде, его качество выше, ну и спать спокойнее стал :) Но все было хорошо до поры до времени: однажды произошли изменения и 80% тестов перестали компилиться а время на их рефакторинг потребовалось для новых фич. Ну и пожалуй главная проблема это их запуск - нет инфраструктуры для их автоматического запуска, грустно как-то перед любым чекином запускать их вручную.

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

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

      Удалить
    3. Проблемы при рефакторинге тестов чаще всего закладываются на этапе написания этих тестов. Требования к коду тестов должны быть не ниже, а в ряде случаев даже выше чем к коду самого продукта. Факторы которые ведут к долгому переписыванию тестов достаточно простые - 1. большие объекты с нечеткой ответственностью выполняющие множество задач приводят к тому, что в тестах приходится тратить огромное количество сил для приведения подопытной системы в нужное состояние (огромные mock'и). 2. дупликации в тестах – ведет к необходимости вносить одно изменение в десятки тестов 3. неверное использование или неиспользование принципов IoC ведущее к невозможности или чрезмерной сложности подмены зависимостей в тестируемой системе. 4. Тестирование через не public интерфейсы и тестирование через behavior тесты приводит к тому что мелкий рефакторинг внутренностей класса вызывает необходимости правки тестов.

      На счет же высказывания Дмитрия "грустно как-то перед любым чекином запускать их вручную" категорически не соглашусь, юниттесты ДОЛЖНЫ запускаться именно на машине разработчика и проходить ооочень быстро. Долгими могут быть функциональные\интеграционные и приемочные тесты, которые уже должны выполняться на выделенных машинах в приближенном к боевому окружении.

      Удалить

Отправить комментарий

Популярные сообщения из этого блога

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu

Полезные ресурсы для молодых (и не только) тестировщиков

сперто(с) Уже 3 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.