(я сейчас очень плохо скажу, потому что иначе пока не дорос.)
И, кстати, проблема «надо писать фичи, а не баги чинить» — совсем не проблема автоматизации.
Это проблема менеджмента, планирования буфферов времени, оценки рисков.
Думаю, фимоз головного мозга — это самая большая проблема менеджмента вообще, а в IT она цветёт очень ярко.
Особенно это заметно в гос-секторе, в котором вбухиваются немереные средства в посредственные работы, с кучей фееричнейших блокеров в основых сценариях использования.
Да, такое есть. Но! Когда разработчик будет писать тесты сам — он не будет говорить, что это «ваши» тесты — он будет их чинить. Потому что это его правка поломала его же тесты.
Программист — такой же наемный рабочий, получают ЗП за результат — работающий проект. О каком «не хотят заниматься» может вообще идти речь? :) И если ручные тестировщики не успевают писать баги, если серверное ПО падает от каждого чиха — это надо решать, вплоть до кадрового вопроса.
(но, таки да, есть такая проблема: у нас программисты зачастую воротят нос от тестов, часто пишут один-два самых базовых)
Что есть «парное программирование с тестировщиком»? Тестировщик читает код, который пишет программист? Без квалификации — бесполезно в принципе. Парное программирование — вообще не панацея. Очень сильно зависит от контингента и воспитания.
Работа тестера — озвучить проблемы, с которыми столкнется конечный пользователь если получит текущий продукт.
Задачей же всей команды (и в первую очередь ПМа) — сделать так, чтоб в любой момент разработки продуктом можно было нормально пользоваться: а это всего лишь значит, что пользователя не должно тошнить от пары недель работы с корпоративной системой учета времени, которая падает каждый три минуты (уже приоритет — мажор), да еще и данные теряет (а вот сейчас приоритет подымается до блокера и виновата в этом вся команда).
Про модульные тесты. Надо контролировать, что покрывают тесты, надо знать наиболее частые сценарии использования продукта. Надо знать, какие сценарии блокированы баглом. И надо отдавать себе отчет, что автотесты — никогда не отловят все ошибки. Так же как и ручные тестировщики не смогут этого сделать.
Ответ есть тут. В кратце: тесты — это часть продукта. Кто сломал — тот и чинит (желательно сразу).
Версии не с нуля пишутся; обычно между версиями нет революционных изменений. Продукт до них эволюционирует. Так же и тесты — как часть функционала (который чем меньше — тем лучше) — тоже должны эволюционировать вместе(!) с генерирующими бизнес-ценности частами, являться их неотъемлемой частью.
Если пункт 1) говорит тестировщик — он должен указать кто и когда сломал (вплоть до строк с поломкой, на diff-е коммита видно :) ).
Если говорит менеджер — тестировщик выполняет команду «Найти негодяя».
Если часто так говорит менеджер — тестировщика оставляем без премии или баним менеджера по IP на билдере (нечего людям работать мешать).
Если программист так говорит — пусть сам разбирается.
Ситуация 2) сложнее и, опять же, смотря кто ее поднимает. Если менеджер:
надо выяснить северити — импакт по функциональности конечного продукта;
баги в баг трекере (расписать импакт, в терминах бизнес-процессов описать проблему и путь воспроизведения);
довести до руководителя баг, дать ссылку на трекер
следовать обычным процессам QA
Если даже после этого не подействует — ни о каком вменяемом руководстве и вообще качестве продукта речи быть не может.
Пункт 3) не самый интересный. Разработчик автотестов (он же SDT/SET: software developer in test, software engineer in test) — это, фактически одновременно QA и разработчик в одном лице. Ни один тестировщик (даже «ручной») не сможет в одиночку (или командой QA) обеспечить «качество».
Качество дают программисты и тестировщики, и аналитики, и художники-дизайнеры. Это всё — разработчики продукта. Они все до единого ответственны за конечный продукт, за свою работу.
Вот как это объяснить руководитству (и надо ли объяснять, если сразу не понятно) — вопрос. Потому что если руководитель проекта не понимает, что качество обеспечивает вся команда — это как минимум некомпетентный руководтель проекта.
Я тут напишу свое мнение с точки зрения автотестера :)
Соответственно, архитектура тестов должна
совершенствоваться аналогично и «успевать» за совершенствованием архитектуры
кода, чего сделано не было из-за недостаточной квалификации тестировщика.
Не-а, неверный посыл. Вы заставили тестировщика догонять команду. Тестировщик-автоматизатор в принципе не может успеть за всей командой, если команда не слоу-поки. Он один — их много, и они в тельняшках.
Правильнее было бы:
обязать разработчиков самим писать юнит-тесты на свою новую функциональность, простейшие интеграционные тесты;
считать минимальный набор тестов одним из критериев завершенности фичи;
добиться прохождения юнит-тестов и базового набора интеграционных (обзовем его Smoke) в один-два часа максимум (если Selenium — постараться использовать Selenium 2.0 и HtmlUnit);
ввести принцип «кто сломал — тот чинит». Тестировщик следит за состоянием билдера и цветом тестов. Как только имеем сломанный тест, отыскиваем (с помощью того же TeamCity) коммит-источник проблемы и пинаем разработчика-ломатора или чиним сами — если умеем :);
по приоритетам программистов: починку тестов считаем блокером или как минимум мажором;
Задачами, собственно, тестировщика-автоматизатора становятся контроль за покрытием функциональности тестами, написание сложных сценариев. Если квалификация тестировщика позволяет — доверяем поддержку инфраструктуры тестирования: фреймворки, обвязки, помощники и т. д.
Собственно желательно, чтоб в интеграционных сценарных тестах использовались настолько высокоуровневые команды, чтоб это напоминало DSL.
Автоматизированное тестирование — не панацея. Как минимум эксплорационное тестирование нетривиально автоматизируется.
Одним предложением: «не одни тестеры, но вся команда в полном составе ответственна за качество».
Думается, что можно оформлять такие патенты на благонадежную и добронастроенную организацию типа OSI. Ведь то, что предлагает Фогель — это именно что закрытие своеобразных исходников.
Я вот сейчас на i3 уже полгода как основное рабочее окружение (2 разных монитора, firefox, thunderbird, IntelliJ IDEA, thunar, .xinitrc). Какие у Ion3 есть вкусности?
Полазал по своей же ссылке. Вот как приблизительно выглядит процесс построения модели в Т-Флекс.
Надо обратить внимание, что линии на первом скриншоте можно «таскать», что приведет к автоматическому пересчету модели и перерисовке чертежа в «чистовом варианте». В кратце процесс:
— наносим основные линии (они не будут отображены, например при печати)
— обводим нужные участки «чернилами» — именно они попадут на печать, расставляем размеры
— можем «потрогать» модель — размеры, «чернила» автоматически поменяются.
Я, в принципе, понимаю, что нельзя обозреть необозримое. Но мне все ж кажется, что обзор не полон как минимум потому, что в него не включена отечественная система T Flex.
В бытность свою студентом-робототехником пришлось немного поработать с тремя продуктами САПР: AutoCAD, Компас и T-Flex.
Конечно, учебный опыт не может сравниться с промышленной эксплуатацией, но мне показалось, что АвтоКАД — это унылый привет из 80х, со световыми перьями и черно-белыми CGA мониторами в 13 дюймов.
В отличие от АвтоКАДа, отечественные продукты Компас и Т-Флекс обладают намного более дружественным и современным интерфейсом.
Не знаю, как сейчас обстоят дела с Компасом, но года так 4 назад, Т-Флекс (при некотором опыте работы) давал бонус +100 к скорости разработки и (!)изменения чертежа.
(далее неинтересное мнение, можно пропустить) На мой взгляд, основным достоинством Т-Флекса по сравнению с Компасом является «параметризация» чертежей и геометрические опорные точки и построения. Правильное построение модели и чертежа в Т-Флексе позволяет легко унифицировать модель числовыми параметрами, и, изменяя их, получать широкий спектр готовых чертежей специфических размеров/параметров.
И, кстати, проблема «надо писать фичи, а не баги чинить» — совсем не проблема автоматизации.
Это проблема менеджмента, планирования буфферов времени, оценки рисков.
Думаю, фимоз головного мозга — это самая большая проблема менеджмента вообще, а в IT она цветёт очень ярко.
Особенно это заметно в гос-секторе, в котором вбухиваются немереные средства в посредственные работы, с кучей фееричнейших блокеров в основых сценариях использования.
Программист — такой же наемный рабочий, получают ЗП за результат — работающий проект. О каком «не хотят заниматься» может вообще идти речь? :) И если ручные тестировщики не успевают писать баги, если серверное ПО падает от каждого чиха — это надо решать, вплоть до кадрового вопроса.
(но, таки да, есть такая проблема: у нас программисты зачастую воротят нос от тестов, часто пишут один-два самых базовых)
Что есть «парное программирование с тестировщиком»? Тестировщик читает код, который пишет программист? Без квалификации — бесполезно в принципе. Парное программирование — вообще не панацея. Очень сильно зависит от контингента и воспитания.
Работа тестера — озвучить проблемы, с которыми столкнется конечный пользователь если получит текущий продукт.
Задачей же всей команды (и в первую очередь ПМа) — сделать так, чтоб в любой момент разработки продуктом можно было нормально пользоваться: а это всего лишь значит, что пользователя не должно тошнить от пары недель работы с корпоративной системой учета времени, которая падает каждый три минуты (уже приоритет — мажор), да еще и данные теряет (а вот сейчас приоритет подымается до блокера и виновата в этом вся команда).
Про модульные тесты. Надо контролировать, что покрывают тесты, надо знать наиболее частые сценарии использования продукта. Надо знать, какие сценарии блокированы баглом. И надо отдавать себе отчет, что автотесты — никогда не отловят все ошибки. Так же как и ручные тестировщики не смогут этого сделать.
Версии не с нуля пишутся; обычно между версиями нет революционных изменений. Продукт до них эволюционирует. Так же и тесты — как часть функционала (который чем меньше — тем лучше) — тоже должны эволюционировать вместе(!) с генерирующими бизнес-ценности частами, являться их неотъемлемой частью.
Если говорит менеджер — тестировщик выполняет команду «Найти негодяя».
Если часто так говорит менеджер — тестировщика оставляем без премии или баним менеджера по IP на билдере (нечего людям работать мешать).
Если программист так говорит — пусть сам разбирается.
Ситуация 2) сложнее и, опять же, смотря кто ее поднимает. Если менеджер:
баги в баг трекере (расписать импакт, в терминах бизнес-процессов описать проблему и путь воспроизведения);
довести до руководителя баг, дать ссылку на трекер
следовать обычным процессам QA
Если даже после этого не подействует — ни о каком вменяемом руководстве и вообще качестве продукта речи быть не может.
Пункт 3) не самый интересный. Разработчик автотестов (он же SDT/SET: software developer in test, software engineer in test) — это, фактически одновременно QA и разработчик в одном лице. Ни один тестировщик (даже «ручной») не сможет в одиночку (или командой QA) обеспечить «качество».
Качество дают программисты и тестировщики, и аналитики, и художники-дизайнеры. Это всё — разработчики продукта. Они все до единого ответственны за конечный продукт, за свою работу.
Вот как это объяснить руководитству (и надо ли объяснять, если сразу не понятно) — вопрос. Потому что если руководитель проекта не понимает, что качество обеспечивает вся команда — это как минимум некомпетентный руководтель проекта.
Не-а, неверный посыл. Вы заставили тестировщика догонять команду. Тестировщик-автоматизатор в принципе не может успеть за всей командой, если команда не слоу-поки. Он один — их много, и они в тельняшках.
Правильнее было бы:
Задачами, собственно, тестировщика-автоматизатора становятся контроль за покрытием функциональности тестами, написание сложных сценариев. Если квалификация тестировщика позволяет — доверяем поддержку инфраструктуры тестирования: фреймворки, обвязки, помощники и т. д.
Собственно желательно, чтоб в интеграционных сценарных тестах использовались настолько высокоуровневые команды, чтоб это напоминало DSL.
Автоматизированное тестирование — не панацея. Как минимум эксплорационное тестирование нетривиально автоматизируется.
Одним предложением: «не одни тестеры, но вся команда в полном составе ответственна за качество».
А так сама патентная система будет препятствовать бредовщине.
И самое главное — никому не давать лицензию на использование этих патентов, ни за какие коврижки!!!
Теперь на Виндовс ломает жать Ctrl-Shift… :(
Надо обратить внимание, что линии на первом скриншоте можно «таскать», что приведет к автоматическому пересчету модели и перерисовке чертежа в «чистовом варианте». В кратце процесс:
— наносим основные линии (они не будут отображены, например при печати)
— обводим нужные участки «чернилами» — именно они попадут на печать, расставляем размеры
— можем «потрогать» модель — размеры, «чернила» автоматически поменяются.
В бытность свою студентом-робототехником пришлось немного поработать с тремя продуктами САПР: AutoCAD, Компас и T-Flex.
Конечно, учебный опыт не может сравниться с промышленной эксплуатацией, но мне показалось, что АвтоКАД — это унылый привет из 80х, со световыми перьями и черно-белыми CGA мониторами в 13 дюймов.
В отличие от АвтоКАДа, отечественные продукты Компас и Т-Флекс обладают намного более дружественным и современным интерфейсом.
Не знаю, как сейчас обстоят дела с Компасом, но года так 4 назад, Т-Флекс (при некотором опыте работы) давал бонус +100 к скорости разработки и (!)изменения чертежа.
(далее неинтересное мнение, можно пропустить) На мой взгляд, основным достоинством Т-Флекса по сравнению с Компасом является «параметризация» чертежей и геометрические опорные точки и построения. Правильное построение модели и чертежа в Т-Флексе позволяет легко унифицировать модель числовыми параметрами, и, изменяя их, получать широкий спектр готовых чертежей специфических размеров/параметров.
Предлагаю в будущем добавлять сравнение нескольких продуктов. Или краткий обзор, какие еще бывают утилиты под те же задачи.