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

Размышлизмы про то, как часто пишется софт

Просто навеяло.
Вчера был в гостях на работе у своего товарища. Пересекся с ребятами, которые по заказу
компании друга (не IT-компания), делают им софт. Они в это время проверяли его на реальном железе (софт связан с радиосвязью).
По словам товарища, им часто приходится перепроверять и чинить то, что раньше работало.

Ребята-разработчики это с грустью подтвердили.

Спросил, есть ли у них автоматические тесты, хоть какие-нибудь. Порадовало то, что они про тесты знают, но дальше огорчение - они их не пишут. Про Continuous Integration тоже знают, но тоже не используют.

Знаете почему? Правильно - времени не хватает. А еще их начальник говорит, что тесты должны писать тестировщики. А тестировщиков у них тоже нет.

Занавес.

PS компания-разработчик, кстати, делает реально крутые ноу-хау вещи, но вот how это все делается, наводит на грустные мысли.
тут (с)

Комментарии

  1. И что интресно им за это платят. Значит бизнес голосует рублем за тот подход что им нужен. Да и слушать их всех надо с некой долей скепсиса. В моей прошлой конторе начальство было далеко от разработки. Самих разработчиков стало напрягать собирать 40 минут С++ проект на своей машине, в инете было даже не полазать так все тормозило и мы собрали из старого хлама "сервер компиляции" , написали пару скриптов и запускали их удаленно. Прообраз CI сервера. Тоже самое было с тестами, писались консольные эмуляторы, программы выдававшие портянку сообщении о разных проверках или же просто гуевые апликухи с кучей кнопок проверяющие какую то фичку.

    ОтветитьУдалить
  2. Платят, потому что ноу-хау (это факт).
    А насчет слушать их - не слушать. Да, понятно, что правильно писать - это не начальник должен за тебя делать. Это должно быть твое понимание профессии. Про это я им тоже сказал. Но согласись - проще и приятней работать, когда ты понимаешь, что начальник с тобой на одной волне :)

    ОтветитьУдалить
  3. Отчасти соглашусь. Но я часто вижу как это саботируется. Люди говорят "мы пишем тесты" и это занимает какое-то неразумное время и на выходе что то ужасное. Так же уверею тебя, когда начальство говорит "Весь код должен быть с тестами" выходит еще хуже, особенно в старых\уставших командах с легаси продуктами. Людям тяжело менять то к чему они привыкли...

    ОтветитьУдалить
  4. ты просто пессимист :) Но тоже отчасти соглашусь

    ОтветитьУдалить
  5. Опыт сын ошибок трудных... Сам же всё знаешь.

    ОтветитьУдалить
  6. Сдается мне что у "радистов" это клиническое. Про тесты они знают, но когда пытаешься у них узнать
    - а почему же их не пишете?
    - Ну ты понимаешь, это же так сложно. Как же мы проверим вот это блок АЦП и вот этот приемник ?

    Ты начинаешь им рассказывать , что тут ставишь стенд, тут пишется специальный ответный софт. а они возражают:
    - Не, это дофига времени нужно, у нас такого времени нет.

    - Хорошо, но вы же можете" проверить это до выхода в эфир? - спрашиваешь ты.
    - Конечно можем - отвечают они.
    - Так и в чем проблема? -
    - Ну у нас программа под это не заточена, это дофига времени нужно.

    И получается замкнутый круг, точнее сказка про белого бычка. Даже когда приносишь им готовое решение, как сделать полный цикл проверки, все равно найдут причину как не делать автотесты.

    То есть на самом деле они не пишут тесты, просто потому что им лень, но в этом никто и никогда не сознается. Гораздо интереснее фигачить новые фичи, потому что заказчик все-равно придет к ним из-за отсутствия альтернатив и поэтому не о чем беспокоиться.

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

    Это я называю "Haсker-driven development" - у меня есть мысль и я ее буду фигачить.

    ОтветитьУдалить
  7. Сдается мне что у "радистов" это клиническое. Про тесты они знают, но когда пытаешься у них узнать
    - а почему же их не пишете?
    - Ну ты понимаешь, это же так сложно. Как же мы проверим вот это блок АЦП и вот этот приемник ?

    Ты начинаешь им рассказывать , что тут ставишь стенд, тут пишется специальный ответный софт. а они возражают:
    - Не, это дофига времени нужно, у нас такого времени нет.

    - Хорошо, но вы же можете" проверить это до выхода в эфир? - спрашиваешь ты.
    - Конечно можем - отвечают они.
    - Так и в чем проблема? -
    - Ну у нас программа под это не заточена, это дофига времени нужно.

    И получается замкнутый круг, точнее сказка про белого бычка. Даже когда приносишь им готовое решение, как сделать полный цикл проверки, все равно найдут причину как не делать автотесты.

    То есть на самом деле они не пишут тесты, просто потому что им лень, но в этом никто и никогда не сознается. Гораздо интереснее фигачить новые фичи, потому что заказчик все-равно придет к ним из-за отсутствия альтернатив и поэтому не о чем беспокоиться.

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

    Это я называю "Haсker-driven development" - у меня есть мысль и я ее буду фигачить.

    ОтветитьУдалить

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

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

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub.

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

Проверять работоспособность тестируемого объекта (system uder test - SUT) можно двумя способами: оценивая состояние объекта или его поведение.

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

Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT.

Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы.

Теперь подробнее.

Gerard Meszaros использует термин Test Double (дублер), как обозначение для объекта, который зам…

План "Б" или как прикольно провести субботний день

Всем привет.
Вчера состоялась конференция "План Б". Организаторами выступили ребята из Яндекса, за что им большое спасибо. Судя по приблизительным подсчетам в мероприятии участвовало около 200 человек.

Основной темой конференции было планирование, планирование всего: проектов, разработки, тестирования, дизайнеров и даже организации музыкального фестиваля.
Сначала думал написать отчет в обычном своем стиле: кто и что говорил, но почитав твиттер по #pbconf понял, что просто потеряю время :) Поэтому кому оооочень интересно узнать подробности следуйте за птичкой и вы все узнаете (тэг #pbconf попал в top-30 твиттера)
Здесь приведу лишь те вещи, которые мне запали в мозг
Роман Чернин о продуктовой разработке: "нет заказчика, нет требований, нет сроков -> как принимать решения? ответ: заводим себе Product Manager-а"
Оля Павлова (@op): "бойтесь иллюзии точной формулировки" "заказчик - ребенок, выдаем ему игрушку как можно чаще" "не забываем, …

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

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

Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.