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

Можно ли обойтись без тестировщиков? 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 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.

(Яндекс/Гугл, перестаньте выдавать ее в выдаче) План "Б" или как прикольно провести субботний день

Отступление: название заметки так зашло в ожидания SEO, что люди уже 11 лет сюда по результатам поиска заходят 😂. Простите, но тут не про то как тусануть и было уже давно. Всем привет. Вчера состоялась конференция " План Б ". Организаторами выступили ребята из Яндекса, за что им большое спасибо. Судя по приблизительным подсчетам в мероприятии участвовало около 200 человек. Основной темой конференции было планирование, планирование всего: проектов, разработки, тестирования, дизайнеров и даже организации музыкального фестиваля. Сначала думал написать отчет в обычном своем стиле: кто и что говорил, но почитав твиттер по #pbconf понял, что просто потеряю время :) Поэтому кому оооочень интересно узнать подробности следуйте за птичкой и вы все узнаете (тэг #pbconf попал в top-30 твиттера) Здесь приведу лишь те вещи, которые мне запали в мозг Роман Чернин о продуктовой разработке: "нет заказчика, нет требований, нет сроков -> как принимать решения? отве